Make it more noticeable if a efidisk will be ignored, as this means
one changed a existing VM that already had a efidisk entry to SEV-SNP,
as adding an efidisk for such VMs with SEV-SNP enabled is blocked.
While at it fix indentation and drop the duplicated $arch variable,
that's already declared as required here at the top of the method.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This patch is for enabling AMD SEV-SNP support.
Where applicable, it extends support for existing SEV(-ES) variables
to SEV-SNP. This means that it retains no-debug and kernel-hashes
options, but the no-key-sharing option is removed.
The default policy value is identical to QEMU’s, and the therefore
required option has been added to configure SMT support.
The code was tested by running a VM without SEV, with SEV, SEV-ES,
SEV-SNP. Each configuration was tested with and without an EFI disk
attached. For SEV-enabled configurations it was also verified that the
kernel actually used the respective feature.
Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu>
Tested-by: Markus Frank <m.frank@proxmox.com>
Reviewed-by: Markus Frank <m.frank@proxmox.com>
Set the 'enable-migration' QEMU command-line flag to on for
live-migration marked mapped devices, as the default is 'auto', but
for those which are marked as capable for live-migration, we want to
explicitly enable that, so that we get an early error on start if the
driver does not support live-migration.
With that we can drop such devices from being a migration blocker.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[TL: squash and re-order similar changes together]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Switch the underlying check_local_resource method to return a hash and
adapt call sites to that change. Return that new hash in the API as
new return property for the frontend to have more info to check.
This is in preparation for enabling live-migration for VMs with
mappings that declare being capable of them.
Originally-by: Dominik Csapak <d.csapak@proxmox.com>
[TL: split out from unrelated changes and fix return schema]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Do not mark mapped devices as local resources for the offline
migration case, there it's only relevant that they have a mapping
configured on the target node, which is a different check.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Christoph Heiss <c.heiss@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
and keep it the same for all current callers as before by setting the
additional 'noerr' parameter to '1'.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
When the VM is running, after deleting the tpmstate from the
configuration, the TPM drive will still be active, because it is used
by swtpm and QEMU will still have the TPM socket.
Also, a subsequent live migration will fail, because the
commandline for the target instance does not match the one for the
source:
> kvm: Unknown ramblock "tpm-ppi", cannot accept migration
For efidisk, hotunplug would already fail with
> can't unplug device 'efidisk0'
but it's better to catch this early and queue the change as pending
instead.
For modifying the 'tpmstate0' and 'efidisk0' options, there are
already checks to disallow live changes.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
instead of blessing a passed-in config and returning it, explicitly only bless
without returning to make it more obvious to callers that this affects the
argument.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Previously, the template's configuration was used as-is for the rest
of handling the VM start even if config_to_command() uses a minimized
configuration to build the command. This can lead to issues with a
network device with the 'link_down' flag set, because the network
device will not be present, but the start handling will still issue a
QMP command for it, leading to a failed backup operation.
Use the minimized configuration for the whole start-up handling to
avoid such issues.
Use the special QemuConfig::NoWrite class to safeguard against
accidentally writing out the temporarily modified config.
Suggested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Template-VMs might be started in 'prelaunch' state when creating a
backup, but they must never be actually started fully, to avoid
modifying their disks.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
While the path for changing a CD-ROM medium was already consistent
with the path for an already inserted CD-ROM at VM start, i.e. the one
from print_drive_commandline_full(), this makes that fact more
explicit. While at it, make sure the format is also consistent with
how it is determined in print_drive_commandline_full(). Do the same
for cloud-init drives, which often are in non-raw format.
Reported-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
To allow re-using it for CD-ROM hotplug.
No functional change intended.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
This was the only user of List::Util, so move that too.
No functional change intended.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
Like this, it can be used by modules that cannot depend on
QemuServer.pm without creating a cyclic dependency.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
There are already other places where 'aarch64' and 'x86_64' are
checked to be the only valid architectures, for example, the
get_command_for_arch() helper, so the new error scenario for an
unknown arch should not cause any regressions.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Add an export, since the function is rather commonly used (in
particular inlined in function calls, where prefixing with the module
name would hurt readability) and there won't be much potential for
confusion name-wise.
This was the only user of stat(), so remove the File::stat include.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Cannot use the is_native_arch() helper inside the function anymore,
to avoid a cyclic dependency between the 'CPUConfig' and 'Helpers'
modules, inline it.
While at it, improve the variable name for the mapping.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Fixes a small typo and uses the same wording as used in pve-container's
description of the `mem` property.
Signed-off-by: Daniel Kral <d.kral@proxmox.com>
Checking only vm configuration for choose the shutdown method causes it
to always fail, after reaching the timeout, if the qemu agent option in
the vm configuration is enabled but the agent is not installed and
active in the guest.
As I seen in the windows vm the agent also crashes in some cases, so
shutdown don't fail only if qemu guest agent is not installed or not
started.
Added check that agent is active when choosing agent shutdown method to
avoid certain shutdown failure in those cases.
Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
[FE: do not set flag to suppress warning when agent is not running]
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
since swtpm currently doesn't support anything else, and might overwrite a file
using qcow2 or vmdk format by accident..
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
All callers have been switched to get the format from the storage
layer using checked_volume_format() and friends.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Avoid using the extension based qemu_img_format() helper. Failure is
not critical, because this is just the hint for what format the
restored target image should be allocated with, so fallback to 'raw'.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
For a Proxmox VE managed volume, prefer the format from the storage
layer rather than the 'format' option set on the drive. Fail if there
is a mismatch between the detected and configured format, because this
is not expected for managed volumes. Having this early hard failure
protects against undesirable issues with live migration and reboot
where the format of a drive would suddenly be different.
For a not Proxmox VE managed volume, use the same logic as before,
i.e. use the 'format' option for the drive with 'raw' as a fallback:
Only root can configure such devices.
Both also apply to the case where the 'cdrom' flag is set to avoid
autodetection by QEMU.
Reported-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
FG: typo fix in comment
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
The minimum supported version for Proxmox VE 8 nodes is QEMU 8.0 and
the beginning of the config_to_command() function already has a check
for at least version 5.0. No other caller of get_vm_machine() passes
in the parameter, so it can be removed from there as well.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Daniel Kral <d.kral@proxmox.com>
Tested-by: Daniel Kral <d.kral@proxmox.com>
The minimum supported version for a Proxmox VE 8 node is QEMU 8.0.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Daniel Kral <d.kral@proxmox.com>
Tested-by: Daniel Kral <d.kral@proxmox.com>
The minimum supported version for a Proxmox VE 8 node is QEMU 8.0.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Daniel Kral <d.kral@proxmox.com>
Tested-by: Daniel Kral <d.kral@proxmox.com>
The parameter was added by ac0077cc ("Use 'QEMU version' ->
'+pve-version' mapping for machine types") but it doesn't seem like
there ever was a caller. In particular, none of the current callers
pass in a value and it's not clear when one would require passing a
different version than the KVM binary version.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Daniel Kral <d.kral@proxmox.com>
Tested-by: Daniel Kral <d.kral@proxmox.com>
