While no problem is known with having an empty machine string in the
configuration and it was already possible setting an empty machine
manually via 'qm set', the behavior changed because of commit 919e69d0
("machine: add check_and_pin_machine_string() helper") and there is
potential for problematic edge cases. Restore the previous behavior.
Pinning is also required when there is no given machine type, so the
call to check_and_pin_machine_string() should stay unconditional.
For update, pinning was recently added by commit 7a9570f3 ("api:
update vm config: pin machine version when switching to windows os
type"), so bring that in-line with the behavior for create too.
Another idea would've been to just return the default machine in
check_and_pin_machine_string(), but that would also be a change in
behavior. In particular, the default depends on the arch, so an empty
machine type will pick the default machine for the currently
configured arch even when the arch is later changed.
Reported-by: Daniel Herzig <d.herzig@proxmox.com>
Fixes: 919e69d0 ("machine: add check_and_pin_machine_string() helper")
Signed-off-by: Fiona Ebner <f.ebner@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>
During virtual machine creation, the machine version is pinned when
the guest OS is Windows. The same should be done when the guest OS
type is newly set to Windows for consistency.
NOTE RFC
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Extract the logic for guest OS-type dependent machine version pinning
into a dedicated helper, so it can be re-used.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Starting from QEMU creation version 9.1, pin to the creation version
instead. Support for machine version 5.1 is expected to drop with QEMU
11.1 and it would still be good to handle Windows VMs that do not have
explicit machine version for whatever reason. For example, explicitly
setting the machine without a version on the CLI/API after creation is
one way to end up with such a machine.
Signed-off-by: Fiona Ebner <f.ebner@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>
The commit 37a1f42a introduced a conversion step for newly allocated
volume disks to base volumes for VM templates. This wrongly excluded
efidisk and tmpstate volumes from this conversion, even though those
should be converted to base volumes too.
Therefore, include efidisks and tpmstate volumes to be converted to base
volumes when newly allocating them.
Suggested-by: Fiona Ebner <f.ebner@proxmox.com>
Fixes: 37a1f42a ("fix #5301: convert added volume disks to base images for templates")
Signed-off-by: Daniel Kral <d.kral@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>
when creating new ones, we already force raw as format, but adding existing
volumes as tpmstate0 had no such checks.
Suggested-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Fabian Grünbichler <f.gruenbichler@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>
since there is no reliable way to check whether a linked clone would end up
being something other than a raw file, and the volumes are tiny anyway.
otherwise on directory storages, the following sequence of events could happen:
- linked clone using raw file as base and qcow2 as overlay
- swtpm_setup interprets qcow2 file as raw
- swtpm_setup fails to find TPM state and overwrites it with a new one
- file is now no longer a linked clone, but a raw file with a qcow2 extension
- move disk and migration fail because of the format mismatch
the downside is that storages that actually support raw linked clones (ZFS,
RBD, LVM-thin) now use more space for fully cloned TPM state volumes...
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>
The file_size_info() will return the size of the image based on
guessing the format. When importing via API, the correct size is
already known, so it's better to pass it in. The root-only 'qm'
commands for disk import and OVF import will still use auto-detection
for backwards compatibility. It might make sense to be able to
explicitly specify the format there too to get the correct size in all
cases.
New callers should detect the size according to the appropriate format
first.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Keep format auto-detection for backwards compatibility. Only root is
allowed to use such images as source images and the untrusted checks
will be done here.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Use the same logic as the actual import later.
Has the nice side effect of getting rid of the unnecessary manual
dispatch to the plugin too.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
With auto-detection, there might be false positives for raw images
that contain data that looks like another image format, but are not
problematic, because they will always be treated as raw images.
Since commit "image convert: use volume format from storage layer",
actual importing will happen using the storage layer format, so use
that here too.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
