First, the provider is asked about what restore mechanism to use.
Currently, only 'qemu-img' is possible. Then the configuration files
are restored, the provider gives information about volumes contained
in the backup and finally the volumes are restored via
'qemu-img convert'.
The code for the restore_external_archive() function was copied and
adapted from the restore_proxmox_backup_archive() function. Together
with restore_vma_archive() it seems sensible to extract the common
parts and use a dedicated module for restore code.
The parse_restore_archive() helper was renamed, because it's not just
parsing.
While currently, the format for the source can only be raw, do an
untrusted check for the source for future-proofing. Still serves as a
basic sanity check currently.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
[WB: fix 'bwlimit' typo]
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Tested-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Reviewed-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Link: https://lore.proxmox.com/20250404133204.239783-18-f.ebner@proxmox.com
In preparation for the restore API for backup providers that doesn't
want detection based on the file extension but always requires raw.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Tested-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Reviewed-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Link: https://lore.proxmox.com/20250404133204.239783-17-f.ebner@proxmox.com
In preparation to add another option and to improve style for the
callers.
One of the test cases that specified $is_zero_initialized is for a
non-existent storage, so the option was not added there.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Tested-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Reviewed-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Link: https://lore.proxmox.com/20250404133204.239783-16-f.ebner@proxmox.com
So new guests, or guests with the 'latest' machine type, have that
setting automatically disabled.
The previous default (enabling S3/S4), does not make too much sense in
a virtual environment, and sometimes makes problems, e.g. Windows
defaults to using 'hybrid shutdown' and 'fast startup' when S4 is
enabled, which leads to NVIDIA vGPU being broken on the boot after
that.
Since the tests don't pin the pve version themselves, we have to
update all the ones where the machine versions are derived from the
installed QEMU version.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Reviewed-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Tested-By: Stoiko Ivanov <s.ivanov@proxmox.com>
Link: https://lore.proxmox.com/20250404125345.3244659-7-d.csapak@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We only have one place where we use it, so add the global flag inline,
instead of collecting and doing it at the end. This makes it
consistent with our other places where we need '-global' flags.
Adapt the tests, since that global flag changes place, the resulting
qemu hardware should be identical, since qemu handles all global flags
at the same time.
Tested live migration of a VM with such a flag from a node running the
old code to a node node running this new one and it worked without
problems.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Tested-By: Stoiko Ivanov <s.ivanov@proxmox.com>
Link: https://lore.proxmox.com/20250404125345.3244659-3-d.csapak@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The `media` option defaults to `disk` if not present, which attaches
the drive read-write. This can be unexpected for ISO volumes. Hence,
when constructing the QEMU command line, require that drives with ISO
volumes explicitly set `media` and die if this is not the case.
This breaks VM start and live-migration if such a drive is present,
and hotplug for such drives. Users can fix this by editing the VM
config to set `media` explicitly.
Also add a cfg2cmd test for the error.
Suggested-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Allow users with the Mapping.Use privilege on the /mapping/hwrng path to
configure /dev/hwrng as an entropy source for VirtIO RNG devices.
Signed-off-by: Filip Schauer <f.schauer@proxmox.com>
Allow non-root users with the VM.Config.HWType privilege to configure
/dev/urandom & /dev/random as an entropy source for a VirtIO RNG device.
/dev/hwrng remains restricted to the root user.
Signed-off-by: Filip Schauer <f.schauer@proxmox.com>
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>
