Commit c8ed1ac2 ("api: create disks: live import: use format from
storage layer") broke live import from an OVA containing a disk,
because a combined format like 'ova+vmdk' was used for the live-import
disk mapping, leading to failure:
> invalid format 'ova+vmdk' for 'scsi0' mapping
There was also an informational message about the confusion earlier:
> file_size_info: '/mnt/pve/dir/images/135/vm-135-disk-0.vmdk': \
> falling back to 'raw' from unknown format 'ova+vmdk
Fixes: c8ed1ac2 ("api: create disks: live import: use format from storage layer")
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
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>
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>
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>
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>
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>
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 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>
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>
Avoid that file_size_info() does auto-detection via qemu-img.
This also adapts to the new argument order.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Since commit "print drive commandline: improve format detection" such
mismatches will lead to being unable to start the VM, so catch the
issue early.
Suggested-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
as it may be the only cause of the clone incompatibility
Example:
# qm clone 101 102 --full --snapname foo
Before:
> Full clone feature is not supported for 'local-zfs:base-100-disk-2/vm-101-disk-2' (tpmstate0)
After:
> Full clone feature is not supported for a snapshot of 'local-zfs:base-100-disk-2/vm-101-disk-2' (tpmstate0)
Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
So far, the error message only contained the name of the disk
(tpmstate0, efidisk0, ...), which can also lead to the assumption that a
specific disk type is the problem. Now the volume ID is primarily
listed.
Example:
# qm clone 101 102 --full --snapname foo
Before:
> Full clone feature is not supported for drive 'tpmstate0'
After:
> Full clone feature is not supported for 'local-zfs:base-100-disk-2/vm-101-disk-2' (tpmstate0)
Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
When cloning was repeatedly attempted, the error message indicated a
different unsupported volume each time. The hash is now sorted to always
mention the same volume as long as it has not been fixed.
Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
[FE: replace old-style 'foreach' with 'for' while at it]
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
the ui and api talks about 'import working storage' but the error here
still said 'for extraction'. Improve the message by unifiying the
wording and adding the storage name to it too.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This reverts commit fca0ba5d77, quoting
Fiona in verbatim:
> Regarding the patch "schema: add fleecing-images config property",
> Fabian off-list suggested using a config section "special:fleecing"
> instead of a property, so that it is truly internal-only. If we go for
> that, the commit should be reverted. Which approach do you prefer?
-- https://lore.proxmox.com/pve-devel/5126c251-64fd-44fe-b1a6-fda9074eb9a1@proxmox.com/
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The function checks for resources that cannot be migrated, snapshoted,
or suspended.
To run this function while the snapshot lock is active, the
pve-guest-common patch 'AbstractConfig: add abstract method to check for
resources preventing a snapshot.' is required.
Signed-off-by: Markus Frank <m.frank@proxmox.com>
this is to override the target extraction storage for the option disk
extraction for 'import-from'. This way if the storage does not
supports the content type 'images', one can give an alternative one.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
when 'import-from' contains a disk image that needs extraction
(currently only from an 'ova' archive), do that in 'create_disks'
and overwrite the '$source' volid.
Collect the names into a 'delete_sources' list, that we use later
to clean it up again (either when we're finished with importing or in an
error case).
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
creating non-raw disk images with arbitrary content is only possible with raw
access to the storage, but checking for references to external files doesn't
hurt, in case for non pve-managed volumes.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
[ DC: removed problematic checks for pve-managed volumes ]
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This will automatically convert imported volume disks and newly
allocated VM volume disks (i.e. no efidisks, tpmstate disks, cloudinit
images, etc.) to a base volume, if the VM is a template.
Previously, this required a user to manually convert the
imported/allocated disk with `qm template --disk <disk>`.
Signed-off-by: Daniel Kral <d.kral@proxmox.com>
to be used internally to record volume IDs of fleecing images
allocated during backup.
Suggested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
This includes docs, and strings printed to stderr or stdout.
These were caught with:
typos --exclude test --exclude changelog
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Cloudbase-Init, a cloud-init reimplementation for Windows, supports only
a subset of the configuration options of cloud-init. Some features
depend on support by the Metadata Service (ConfigDrive2 here) and have
further limitations [0].
To support a basic setup the following changes were made:
- password is saved as plaintext for any Windows guests (ostype)
- DNS servers are added to each of the interfaces
- SSH public keys are passed via metadata
Network and metadata generation for Cloudbase-Init is separate from the
default ConfigDrive2 one so as to not interfere with any other OSes that
depend on the current ConfigDrive2 implementation.
DNS search domains were removed because Cloudbase-Init's ENI parser
doesn't handle it at all.
The password set via `cipassword` is used for the Admin user configured
in the cloudbase-init.conf in the guest while the `ciuser` parameter is
ignored. The Admin user has to be set in the cloudbase-init.conf file
instead.
Specifying a different user does not work.
For the password to work the `ostype` needs to be any Windows variant
before `cipassword` is set. Otherwise the password will be encrypted and
the encrypted password used as plaintext password in the guest.
The `citype` needs to be `configdrive2`, which is the default for
Windows guests, for the generated configs to be compatible with
Cloudbase-Init.
[0] https://cloudbase-init.readthedocs.io/en/latest/index.html
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
With the last change in the permission check, I accidentally broke the
check for 'spice' host value, since in the if/elsif/else this will fall
through to the else case which was only intended for when neither 'host'
nor 'mapping' was set.
This made 'spice' only settable by root@pam since there we return early.
To fix this, move the spice check into the 'host' branch, but only error
out in case it's not spice.
Fixes: e3971865 (enable cluster mapped USB devices for guests)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
After the TPM state has been created (to be precise, initialized by
swtpm) it is not possible to change the version anymore. Doing so will
lead to failure starting the associated VM. While documented in the
description, it's better to enforce this via API.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
The default timeout is 5 seconds, but some HMP commands (e.g.
disk-related ones) might take longer than that. The API call is
synchronous, so has to complete within 30 seconds, and since there is
no other costly operation, use 25 seconds.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
by wrapping the properties from the command definition to get an
actual schema definition.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
The previous wording made it sound like all "visible" tasks were
aborted, which is not the case: A user with Sys.Audit but without
Sys.Modify may see a task that was started by a different user, but
overrule-shutdown would not abort the task.
Change wording to better reflect that not all visible tasks may be
aborted.
Also, add a full-stop that was previously missing.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
The new `overrule-shutdown` parameter is boolean and defaults to 0. If
it is 1, all active `qmshutdown` tasks for the same VM (which are
visible to the user/token) are aborted before attempting to stop the
VM.
Passing `overrule-shutdown=1` is forbidden for HA resources.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
In the past, moving unused disks to another storage was prohibited due
to oversights in the handling of unused disks. This commit rectifies
this limitation by allowing the movement of unused disks.
Historical context:
* 16 Sep 2010 r5164 qemu-server/pve2: The disknames sub was removed.
* 17 Sep 2010 r5170 qemu-server/pve2: Unused disks were introduced.
* 28 Jan 2011 r5461 qemu-server/pve2: The same disknames sub that was
removed in r5164 was brought back. Since unused disks were not around
yet in r5164 the disknames sub did not consider unused disks.
* 6-8 Aug 2012 c1175c92..f91b2e45 qemu-server.git: Disk resize was
introduced. In commit c1175c92 in sub qemu_block_resize unused disks
were not taken into account and in commit 2f48a4f5 (8 Aug 2012) the
resize API call was changed to only allow disks matching the ones in
the disknames sub. Since sub disknames did not contain any unused
disks, those were not allowed at all in the resize API call.
* 27 May 2013 586bfa78 qemu-server.git: Disk move was introduced. The
API call implementation borrowed heavily from disk resize, including
the behaviour of not taking unused disks into account. Thus, unused
disk could not be moved, which persists to this day.
In summary, this behaviour was introduced because the handling of unused
disks was overlooked and it was never changed.
There is no inherent reason why unused disks should be restricted from
being moved to another storage. These disks cannot use the
qemu_drive_mirror, but they can still be moved with qemu_img_convert,
the same way as any other disk of a stopped VM.
Signed-off-by: Filip Schauer <f.schauer@proxmox.com>
