this adds a VM Generation ID device uses by Windows (Server) to determine
some specific actions that may have happened with the vm
such as rollback, restore, etc.
the OVF tests use `qemu-img`, which is provided by either our
pve-qemu(-kvm) or qemu-utils (upstream).
Use qemu-utils as it's provided by ours and upstreams package and
thus makes bootstrapping easier, e.g., if our qemu package is not yet
installed this can still be build.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
add ibpb, ssbd, virt-ssbd, amd-ssbd, amd-no-ssb, pdpe1gb cpu flags
> The following are important CPU features that should be used on
> Intel x86 hosts, when available in the host CPU. Some of them
> require explicit configuration to enable, as they are not included
> by default in some, or all, of the named CPU models listed above.
> In general all of these features are included if using “Host
> passthrough” or “Host model”.
>
> pcid: Recommended to mitigate the cost of the Meltdown
> (CVE-2017-5754) fix. Included by default in Haswell, Broadwell &
> Skylake Intel CPU models. Should be explicitly turned on for
> Westmere, SandyBridge, and IvyBridge Intel CPU models. Note that
> some desktop/mobile Westmere CPUs cannot support this feature.
>
> spec-ctrl: Required to enable the Spectre (CVE-2017-5753 and
> CVE-2017-5715) fix, in cases where retpolines are not sufficient.
> Included by default in Intel CPU models with -IBRS suffix. Must be
> explicitly turned on for Intel CPU models without -IBRS suffix.
> Requires the host CPU microcode to support this feature before it
> can be used for guest CPUs.
>
> ssbd: Required to enable the CVE-2018-3639 fix. Not included by
> default in any Intel CPU model. Must be explicitly turned on for
> all Intel CPU models. Requires the host CPU microcode to support
> this feature before it can be used for guest CPUs.
>
> pdpe1gbr: Recommended to allow guest OS to use 1GB size pages.Not
> included by default in any Intel CPU model. Should be explicitly
> turned on for all Intel CPU models. Note that not all CPU hardware
> will support this feature.
-- https://www.berrange.com/posts/2018/06/29/cpu-model-configuration-for-qemu-kvm-on-x86-hosts/
Fix #1717: delete snapshot when vm running and drive not attached
changelog v2:
- remove hash
- remove check if cdrom
if we try to delete a snapshot, and that is disk from the snapshot
is not attached anymore (unused), we can't delete the snapshot
with qemu snapshot delete command (for storage which use it (qcow2,rbd,...))
example:
...
unused0: rbd:vm-107-disk-3
[snap1]
...
scsi2: rbd:vm-107-disk-3,size=1G
-> die
qmp command 'delete-drive-snapshot' failed - Device 'drive-scsi2' not found
If drive is not attached, we need to use the storage snapshot delete command
Dominik Csapak [Tue, 26 Jun 2018 12:15:47 +0000 (14:15 +0200)]
add exec(-status) to qm
on the commandline the implementation for exec is a bit different
because there we want (by default) to wait for the result,
as opposed to the api, where it is enough to return the pid and
let the client handle the polling
this behaviour is optional and can be turned off, as well as the
timeout of 30 seconds
Unused disk(s) appeared after a rescan of storages. Especially shown
with ceph pools, where two storage entries are made, <storage>_ct and
<storage>_vm. The rescan method did include images from both storages.
This patch filters any storage not containing the content type 'images'.
Dominik Csapak [Wed, 13 Jun 2018 09:17:26 +0000 (11:17 +0200)]
use 'system_wakeup' to resume suspended vms
when a vm is suspended (e.g. autosuspend on windows)
we detect that it is not running, display the resume button,
but 'cont' does not wakeup the system from suspend
Move the locking inside worker, so that the process doing the actual
work (create or restore) holds the lock, and can call functions which
do locking without deadlocking.
This mirrors the behaviour we use for containers, and allows to add
an 'autostart' parameter which starts the VM after successful
creation. vm_start needs the lock and as not the worker but it's
parents held it, it couldn't know that it was actually save to
continue...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Mon, 14 May 2018 12:03:04 +0000 (14:03 +0200)]
fix logic of deleting balloon
Deleting the balloon config entry means resetting it to its
default. This means having a balloon device but not actually
doing any ballooning with it (iow. resetting the VM's
'balloon' value to its specified memory.).
Hotplugging a balloon device (coming from explicit '0' to
any other value (including deleting it)) is not possible.
To avoid potential cleanup & post-start actions to cause
unwanted processes (such as gpg-agent) to be started as part
of the scope, as the enter_systemd_scope() function causes
the current process to enter the scope.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Dominik Csapak [Wed, 2 May 2018 09:23:59 +0000 (11:23 +0200)]
fix #1749: do not copy pending changes when cloning a vm
cloning a vm means copying the current state, not the
state of 'some time in the future, when the vm is started again'
we should not copy the pending changes, which also fixes the
issue that we got a wrong pending change on the disks,net,smbios,etc.
Add pci.3 to pve-q35.cfg required by virtio-scsi-single
(commit message reworked from original[1])
As a temporary workaround add always a pci.3 bridge so that if
virtio-scsi-single is used, either directly or indirectly if SCSI and
iothread is selected, the respective bridge is available:
> The case where we do miss the pci.3 bridge is when using
> virtio-scsi-single, regardless of whether io threads are enabled,
> because we always put those controllers on pci bus 3 (see
> QemuServer/PCI.pm)
-- [2]
A long term solution would be to always add those bridges dynamically
and just filter out the ones which are already inside the pve-q35.cfg
file .
when using q35 as machine type, there are nested pci-bridges,
but we only checked the first layer
this resulted in not being able to hotplug scsi devices,
because scsihw0 was deeper in the pci-bridge construct, we did not see
it and tried to add it (which fails of course)
this patch checks all bridges, regardless how deeply nested they are
disk: serial no must now be passed to device not drive
With QEMU 2.10 the serial parameter of the -drive command line option
was deprecated [1], so move the logic which adds this parameter now
to the -drive analogue -device CLI option.
Features marked deprecated will continue to work for two releases[2],
so we need to switch over before 2.12, AFAICT.
Thomas Lamprecht [Tue, 20 Mar 2018 13:26:43 +0000 (14:26 +0100)]
stop passing default '-k' QEMU option from datacenter.cfg
Modern noVNC does not needs this anymore, actually things may get
worse if it's used. E.g., when one sets 'de' and the VM locale is
'de' you may get a 'ĸ' (unicode kra) if you want to send an ampersand
character through pressing SHIFT + 6.
Qemus manual pages confirms that this is most times not needed
anymore:
> -k language
> Use keyboard layout language (for example "fr" for
> French). This option is only needed where it is not
> easy to get raw PC keycodes (e.g. on Macs, with some
> X11 servers or with a VNC or curses display). You don't
> normally need to use it on PC/Linux or PC/Windows
> hosts.
-- man kvm
An user can always set it per VM, wew simply remove the implict
default derived from the cluster wide datacenter.cfg
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The git history of this is not immediately obvious due to
the date of the cloud init patches, but the removal of this
line was basically reverted by them later at merge-time.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
But reverted that to allow migration of VMs still using the old
montior to ones which already switched over to the new QMP one,
in commit dab36e1ee924be0efab3f85937c23910b456f4b9 (17.08.2012)
see bug #242 for reference
This was all done and released in PVE 2.2, as no migration through
nodes differing more than one major version is possible we can
finally remove this code for good.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>