This caused a few hiccups with qemu 3.0...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Acked-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
instead of overwriting the 'machine' config in the snapshot,
use its own 'runningmachine' config only for the snapshot
this way, we do not lose the machine type if it was
explicitely set during the snapshot, but deleted afterwards
we also have to adapt the tests for this
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> 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/
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
tells an user what would get touched, so he has a chance to fix
unwanted things before changes are actually made.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Else an user has no idea what, or if something happened.
Gets printed to tty when using qm rescan or to tasklog for the case
where we do a rescan after restoring a backup.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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'.
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
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
with this we can wake up suspended vms
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
the not definedness check is unecessary here, since it does not
do anything then, and to check balloon twice is also not necessary
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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>
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
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
it is not necessary to check the romfile of the running vm
for .pxe machine types, since the machine type itself is not
hot-pluggable
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we accidentally moved nbd_stop to CloudInit.pm in
commit 0c9a7596f6
and removed it in
commit 3db6e4ab70
without realizing that live local storage migration still depends on it
readd it
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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.
[1]: https://wiki.qemu.org/ChangeLog/2.10#Deprecated_options
[2]: https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
since this requires O_DIRECT support by the underlying storage, which
might not be available.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
this fixes an issue with zvols, which require cache=none and eat up all
free memory as buffered pages otherwise
https://github.com/zfsonlinux/zfs/issues/7235
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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>
We introduced our QMP socket with commit
c971c4f221 (29.05.2012)
Already tried to remove this with commit
7b7c6d1b5d (13.07.2012)
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 dab36e1ee9 (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>
Checking for the cgroup directory is a kind of time-of-check
time-of-use race condition stop-mode backups seem to
occasionally run into on some systems.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
With configdrives we end up with the /etc/network/interfaces
file containing the interface names we use on the disk, ie.
eth0/eth1/..., which doesn't work on systems which do not
use this name.
With the 'nocloud' image type we can provide a
network-config in yaml which matches mac addresses. Ideally
we'd use version 2, but debian stretch ships with a too old
cloud-init for this, so for now we're writing version 1.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
move: don't error out with "you can't move a cdrom"
clone: always full-clone cloud-init images
They get completely replaced anyway at the next start, so
there's no point in keeping them.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
*) always replace old cloudinit images
*) apply pending cloudinit changes when generating a new
image
For cloudinit we now always use vdisk_free before
vdisk_alloc in order to always replace old images, this
allows us to hotplug a new drive by setting it to
`none,media=cdrom` first (to eject the disk), then setting
it back to 'storage:cloudinit' to have a new image generated
after applying the currently pending changes.
socat tunnel for nbd mirror was introduce here
https://pve.proxmox.com/pipermail/pve-devel/2017-January/024777.html
to workaround when nbd client was hanging on non responding nbd server.
We have added a 30s timeout on socat tunnel, but when we migrate
multiple disks, it can break migration if for example first disk
is already finished and don't send any new datas in the tunnel.
The connect timeout bug has been fixed in qemu 2.9,
so we can remove the socat tunnel now.
With shared=1, (live) migration ignores the disk and assumes it is
present on all target nodes. This works similar to shared=1 on LXC
mountpoints.
Signed-off-by: Chris Hofstaedtler <chris.hofstaedtler@deduktiva.com>
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
if the value was '0', we did not append the option to the drive,
resulting in wrong command line if the qemu default of an option is not
'0'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Skylake-Server is the Xeon variant of Skylake
max is "all features supported by the accelerator in the current host"
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
this have the 'spec-ctrl' flag by default to allow IBRS based Spectre
mitigation by the guest kernel.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Hugepages can take some time to be allocated by qemu at start (60s for 120G of 1G hugepages).
This patch increase start timeout to 5min when hugepages are enabled.
Currently this only allows specifying '+pcid' or '-pcid'
but might be extended in the future.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Fixes: 2bfbee039b ("include format for efidisk")
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This also fixes a bug where VMs with no memory defined in the config
where reported as using 0MB instead of 512.
Signed-off-by: Emmanuel Kasper <e.kasper@proxmox.com>
when having an unused disk on a storage for which there are multiple
definitions, we added it again on another storage when that storage
was alphabetically before the already existing one
this happens for example when using our automatically generated
ceph storages: 'pool_ct' and 'pool_vm' and having a vm with
an unused disk
with this patch, we also leave the unused disks in the hash
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this means that we do not include the '-k' parameter anymore by default
(which is deprecated by qemu)
with this, noVNC and spice always respect the guest keyboard
configuration and altgr keys work without problems
tested:
ubuntu with english intl and german with novnc and spice
windows 10 with english intl and german with novnc and spice
live migration
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
since the guest-fsfreeze-freeze command has a timeout of 1 hour,
we want to check if the guest-agent even runs before executing that,
or else we wait 1 hour and then continue
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
if the efidisk is in 'raw' format, qemu will prevent writes
on block zero if the format is not explicitely given
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
'These options take an integer value and control the "cpu.shares"
control group attribute. The allowed range is 2 to 262144. Defaults to
1024.' – man 5 systemd.resource-control
we only checked if a vm had in use base disks when deleting them,
at which point we do not stop to delete the vm even when a
disk deletion fails, which means we could successfully delete the config
and all not used (base) disks of a template, resulting in left over vm disks
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
perls 'local' must be either used in front of each $SIG{...}
assignments or they must be put in a list, else it affects only the
first variable and the rest are *not* in local context.
In all cases the global signal handlers we overwrote were in cli programs or
forked workers, not in daemons.
this was only kept for PVE 4.X where the switch to the newer OVMF
image with actual working persisten EFIVARS was made.
We do not ship this old image in PVE 5.0 anymore so remove this
legacy code as it can never trigger anyhow.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
factor out code in a new create_efidisk submethod, as else this code
is hardly readable as the efidisk0 case is a special case. Refer from
putting all this specialised handling directly to the much shorter
code for all other cases.
Also the disk was created with a specific format and then a format
detection on the newly created disk was done, which is pretty
useless, clear that up.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
perls 'local' must be either used in front of each $SIG{...}
assignments or they must be put in a list, else it affects only the
first variable and the rest are *not* in local context.
This may cause weird behaviour where daemons seemingly do not get
terminating signals delivered correctly and thus may not shutdown
gracefully anymore.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Moved the check to the beginning of the function.
VMs configured to use KVM won't start if KVM is not available.
VMs not configured to use KVM will start regardless.
Fixes a typo in the function name and removes the $nokvm parameter, as it's only
used to immideately exit the function. Instead calling the function
conditionally.
If we get an VM machine older than 2.9 we use the old selection
expression for the VGA type. This allows to live migrate VMs to PVE
5.0 from beta 1 and PVE 4.4 again.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the syntax was wrong, it was (e.g. for iops-write):
throttling.iops-write=-max100
instead of
throttling.iops-write-max=100
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
QemuServer::lspci() iterates over /sys/bus/pci/devices which
doesn't guarantee any order which means functions sometimes
ended up in the wrong order and it was never clear which
one would get the additional options such as x-vga passed
to them.
bps_max_length & friends were wrongly named and were only
passed to qemu when hot-applying changes. They can only
be passed via the command line with their new names. For
consistency let's rename them all, that way they're all in
one place.
Fixes#1195 (for real this time).
We cannot look for ports on "any" wildcard address while
letting qemu bind to "localhost", this may lead to a qemu
process occupying ::1 while the next search successfully
finds the same port available for IPv4's '*' address.
Instead, we now lookup the IP of the desired family for
'localhost'. Note that while we could simply be hardcoding
::1 or 127.0.0.1, with this code we are protocol agnostic.
For calculation of "current_core" the input variable id is decremented.
For calculation of "current_socket" this decrement was missing resulting
in a wrong value when "cores" is set to 1.
Signed-off-by: Tobias Böhm <tb@robhost.de>
This patch will include all necessary properties for the replication.
Also will it enable and disable a replication job
when appointed flags are set or deleted.
this (correctly!) errored out with Qemu 2.9 when live-migrating
local disks, because the NBD server blocks the VM from being
resumed. was probably missed when migrating via unix domains
was originally introduced..
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
This was checking for scsihw being set in both branches
whereas lsi is also the default. Added the missing 'not'.
Fixes a bug where a VM with a disk with a scsi index >= 7
refused to start due to an invalid scsi id.
Reported-by: Friedrich Ramberger <f.ramberger@proxmox.com>
since it can cause I/O errors and data corruption in low
memory or highly fragmented memory situations since Qemu 2.7
use scsi-hd by default instead
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
if qga is enabled, we try to freeze the fs before cancelling block job.
if not , we pause the vm.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This will create a new drive for each local drive found,
and start the vm with this new drives.
if targetstorage == 1, we use same sid than original vm disk
a nbd server is started in qemu and expose local volumes to network port
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
we can use multiple drive_mirror in parralel.
block-job-complete can be skipped, if we want to add more mirror job later.
also add support for nbd uri to qemu_drive_mirror
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
otherwise we end up with undeletable VM configs in case
vdisk_free fails (which could happen because of cluster-wide
lock contention, storage problems, ..).
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
When trying to migrate a VM from a node with qemu server <= 4.0-92 to
a node with qemu server >= 4.0-93 we failed as the remote qemu-server
got no explicit migration_type' from the older qemu server on the
source.
Check if migration_type is defined on a incoming migration start, if
not set it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
All special flags for Windows 8 and Windows 2012 (win8 type)
are kept the same , since we set flags based on checking if
/^win(\d+)$/ is greater than 6 or 7
like for snapshot, we need to check if krbd is enabled, to known
if we need to use qmp delete-drive-snapshot or storage command directly
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This cleanup windows guest os version handling,
with normalizing ostype with numbers in a new windows_version sub.
if($ostype eq 'wxp' || $ostype eq 'w2k3' || $ostype eq 'w2k') {
$winversion = 5;
} elsif($ostype eq 'w2k8' || $ostype eq 'wvista') {
$winversion = 6;
} elsif ($ostype =~ m/^win(\d+)$/) {
$winversion = $1;
}
so we can simply do test on windows version with lower or upper version
Hyperv enlightments configuration is centralized
in a new add_hyperv_enlighments sub.
Also disable hyperv with win < 8 + ovmf.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Without this patch we use the network were the cluster traffic runs
for sending migration traffic. This is not ideal as it may hinder
cluster traffic. Further some users have a powerful network which
would be perfect for migrations, with this patch they can run the
migration traffic over such a network without having the corosync
traffic on the same network.
The network is configurable through /etc/pve/datacenter.cfg which
got a new property, namely migration. migration has two
subproperties: type (replaces the old migration_unsecure property)
and network.
For the case of a network failure or that a VM has to be moved over
another network for arbitrary other reasons I added the
migration_type and migration_network parameters to qm migrate (and
respectively vm_start as this gets used on migration).
They allow overwriting the datacenter.cfg settings.
Fixes bug #1177
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Let 'cdrom' use the pve-qm-ide format, as it's supposed to
be an alias to ide2.
We're not using the 'alias' schema property since the qemu
configs still use a custom parser (due to the
pending-changes system and the filename-to-volume-id
conversion for legacy support) which does not deal with
schema aliases.
when restoring into an existing VM, we don't want to die
half-way through because we can't delete one of the existing
volumes. instead, warn about the deletion failure, but
continue anyway. the not deleted disk is then added as
unused automatically.
this adds a bootsplash image in /usr/share/qemu-server
and if this file exists, use it for seabios
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
if efidisk0 is defined, use it as a efivars disk,
to permanently store efivars (such as boot options)
we check if the files exist, and act accordingly
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
just a simple disk (only size, format and volid) for
efivars disk
also do not add it to command line in foreach_drive
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
drive-mirror is not working with qemu 2.6 when iothread is enabled.
with virtio-blk : mirror is working, but block-job-completed crash the vm
with virtio-scsi : mirror hang at start.
This should be fixed in qemu 2.7
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
we have a few problems with hotplug at the moment:
qemu may add usb hubs when adding usb devices but fails to remove them
when removing the usb device (this is a qemu bug)
also when starting a guest with a usb device we add ehci and uchi
controllers, which we cannot hot unplug
with those devices, it is impossible to live migrate the guest
to another host, meaning even if you remove all usb devices,
the migrate fails
so we deactivate usb hotplugging for now
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this patch introduces working usb hotplugging
you can now add a usb device while a vm is running
this does not work with spice at the moment, only
with usb passthrough
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
since usb devices do not have their own
"query" command in qmp, we have to use
qom-list /machines/peripheral
which essentially gets a list of peripheral devices of
the vm
there we only get the usb devices
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
vm configuration
----------------
hugepages: (any|2|1024)
any: we'll try to allocate 1GB hugepage if possible, if not we use 2MB hugepage
2: we want to use 2MB hugepage
1024: we want to use 1GB hugepage. (memory need to be multiple of 1GB in this case)
optionnal host configuration for 1GB hugepages
----------------------------------------------
1GB hugepages can be allocated at boot if user want it.
hugepages need to be contiguous, so sometime it's not possible to reserve them on the fly
/etc/default/grub : GRUB_CMDLINE_LINUX_DEFAULT="quiet hugepagesz=1G hugepages=x"
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Acked-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
add them by default for qemu 2.6
(support is already present in qemu 2.5, but we don't want to break live migration for current running vm)
vpindex && runtime need host kernel 4.4
Theses 3 enlightements are needed by windows to use vmbus
http://searchwindowsserver.techtarget.com/definition/Microsoft-Virtual-Machine-Bus-VMBus
details :
- When Hyper-V "vpindex" is on, guest can use MSR HV_X64_MSR_VP_INDEX
to get virtual processor ID.
- Hyper-V "runtime" enlightement feature allows to use MSR
HV_X64_MSR_VP_RUNTIME to get the time the virtual processor consumes
running guest code, as well as the time the hypervisor spends running
code on behalf of that guest.
- Hyper-V "reset" allows guest to reset VM.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
We cannot guarantee when the SSH forward Tunnel really becomes
ready. The check with the mtunnel API call did not help for this
prolem as it only checked that the SSH connection itself works and
that the destination node has quorum but the forwarded tunnel itself
was not checked.
The Forward tunnel is a different channel in the SSH connection,
independent of the SSH `qm mtunnel` channel, so only if that works
it does not guarantees that our migration tunnel is up and ready.
When the node(s) where under load, or when we did parallel
migrations (migrateall), the migrate command was often started
before a tunnel was open and ready to receive data. This led to
a direct abortion of the migration and is the main cause in why
parallel migrations often leave two thirds or more VMs on the
source node.
The issue was tracked down to SSH after debugging the QEMU
process and enabling debug logging showed that the tunnel became
often to late available and ready, or not at all.
Fixing the TCP forward tunnel is quirky and not straight ahead, the
only way SSH gives as a possibility is to use -N (no command)
-f (background) and -o "ExitOnForwardFailure=yes", then it would
wait in the foreground until the tunnel is ready and only then
background itself. This is not quite the nicest way for our special
use case and our code base.
Waiting for the local port to become open and ready (through
/proc/net/tcp[6]] as a proof of concept is not enough, even if the
port is in the listening state and should theoretically accept
connections this still failed often as the tunnel was not yet fully
ready.
Further another problem would still be open if we tried to patch the
SSH Forward method we currently use - which we solve for free with
the approach of this patch - namely the problem that the method
to get an available port (next_migration_port) has a serious race
condition which could lead to multiple use of the same port on a
parallel migration (I observed this on my many test, seldom but if
it happens its really bad).
So lets now use UNIX sockets, which ssh supports since version 5.7.
The end points are UNIX socket bound to the VMID - thus no port so
no race and also no limitation of available ports (we reserved 50 for
migration).
The endpoints get created in /run/qemu-server/VMID.migrate and as
KVM/QEMU in current versions is able to use UNIX socket just as well
as TCP we have not to change much on the interaction with QEMU.
QEMU is started with the migrate_incoming url at the local
destination endpoint and creates the socket file, we then create
a listening socket on the source side and connect over SSH to the
destination.
Now the migration can be started by issuing the migrate qmp command
with an updated uri.
This breaks live migration from new to old, but *not* from old to
new, so there is a upgrade path.
If a live migration from new to old must be made (for whatever
reason), use the unsecure_migration setting (man datacenter.conf)
to allow this, although that should only be done in trusted network.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
With systemd-run qemu's --daemonize forks often happen
before systemd finishes setting up the scopes, which means
the limits we apply often don't work.
We now use enter_systemd_scope() to create the scope before
running qemu directly without systemd-run.
Note that vm_start() runs in a forked-worker or qm cli
command, so entering the scope in such a process should not
affect the rest of the pve daemon.
if we got an option which was not valid, we still
wrote it to the config, and subsequently returned
it on every api call
instead, now we die instead of warn and do not accept
invalid options
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
otherwise, long kvm commands lead to systemd unit files with
very long lines, with confuses the systemd unit file parser.
apparently systemd has a length limit for unit file lines and
(line-)breaks the description string at that point. since
the rest of the description is probably not a valid key/value
pair, this leads to warnings. the default semantics of systemd-run
is to use the executed command as description unless a description
is specified explicitly.
note that this behaviour of systemd could allow an attacker
with access to the VM configuration to craft a kvm commandline
that starts or stops arbitrary systemd units.
previously, we did not check the file parameter of a disk,
allowing passthrough of a block device (by design)
with the change to the json parser for the disks, the format
became 'pve-volume-id' which is only valid for our volume ids
(and later we also allowed the value 'none')
this patch alternatively checks if the parameter is a path
or 'cdrom'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Otherwise some move operations will fail to delete the old
disk (eg. when moving from ceph to local storage).
Note that in order for the deactivation to succeed we need
to make sure qemu has closed its file descriptors, so we
need to wait for the job to disappear the same way we do in
$cancel_job().
Factored the waiting out into $finish_job().
Additionally since the cpu and host node list isn't
restricted to a single range one can now provide multipel
ranges separated by semicolons. (eg. cpus=0-3;5;7)
The urlencoded format currently cannot check the real
decoded length, so we limit to an upper bound and document
the real limits. Ideally we'd introduce a decodedLength
schema parameter at some point...
/cirrur/cirrus/
/devive/device/
/Numa/NUMA/
and a few grammar fixes, rewrites of sentences
Also if already touching those lines lets break them up from one
liners to a column limit of ~80.
When using OVS tap_plug() resets rate limiting so we need
to pass it along to reapply it.
The rate on its own can still be hot-plugged with the
regular tap_rate_limit() call.
Drop snapshot_create, snapshot_delete and snapshot_rollback
in favour of PVE::AbstractConfig. Qemu-specific parts are
implemented in __snapshot_XX methods in PVE::QemuConfig.
has_feature is made an implementation of the abstract
has_feature, and thus moves to PVE::QemuConfig.
Note: a new hook method needed to be introduced to be called
before creating a volume snapshot, after creating a volume
snapshot, and after unfreezing the guestfs after creating a
volume snapshot. The base method in PVE::AbstractConfig is a
noop, the implemention in PVE::QemuConfig runs the necessary
Qemu monitor commands.
Drop load_config, write_config, lock_config[_xx],
check_lock, check_protection, is_template and config_file
in favour of implementions in PVE::AbstractConfig.
Implement guest_type, __config_max_unused_disks,
config_file_lock and cfs_config_path from
PVE::AbstractConfig in PVE::QemuConfig.
Previously, foreach_drive iterated over all configuration
keys (in a random order) and checked whether the current key
is a valid drive name. Instead, we now iterate over a list
of valid drive names (with deterministic order) and check
whether a drive with such a name exists in the
configuration.
Also rename the two involved methods from valid_drive_name
to is_valid_drive_name (for the check) and from disknames
to valid_drive_names (for the list of valid keys), for
consistency. These two were only used in the qemu-server
code base.
We hold a lock from snapshot_prepare until snapshot_commit,
so there is no need to copy back the snapshot config to the
actual config. This allows to drop a workaround for not
copying the 'machine' type config option.
We don't have any storage types other than LVM which react
to scsi inquiry, and we don't want to treat LVM as a scsi
device, so now we only query devices added as actual /dev
path. This was originally intended to be a pass-through
feature anyway, so this makes sense.
As there the signleton function "kvm_user_version" may not have been
called and with the machine alias q35 the regex from the
qemu_machine_feature_enabled method does not match and thus we
need a valid kvm version here
instead of hardcoding the storagetypes for writing zeros on a
backup restore, we use volume_has_feature with 'sparseinit'
for determining if we can omit writing zeros
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Currently migration is broken, because qemu_machine_pxe return nothing if no pxe rom exist.
That mean that we don't pass -machine flag to migration, and migration is broken between qemu 2.4->2.5
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
qemu 2.5 support a new hyper-v feature: hv_vendor_id
This allow nvidia drivers to install on windows with hyper-v feature on.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
currently we leave orphaned vmstate files when we restore a
backup over a vm, which has snapshots with saved ram state.
this patch deletes those files on a restore.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Since write_config was always called with skiplock=1 except
once, it makes sense to drop this parameter like in
PVE::LXC::write_config . If needed in the future, the
caller can use check_lock before write_config anyway.
The method update_config wrapped update_config_nolock
using lock_config, but to prevent update races the whole
"read config", "do something", "write config" flow was
always protected by lock_config anyway, and update_config
was never called.
Thus, we can safely drop update_config and rename
update_config_nolock to write_config like in PVE::LXC .
since we want the usb3 option to be really boolean and not only
'usb3=yes', we have to change the usb json format a little
to not break existing configs for 'usbX: spice', we set the 'host'
option as non-optional and default_key and allow 'spice' as its
content (this also makes the option less ambiguous)
another side effect is that previously accepted multiple 'host='
entries are now forbidden
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
adding a flag for usb devices (usb3), if this is set to yes,
add a xhci controller and attach the specified devices to it
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The API passes $skiplock to vm_destroy() which performed a
check conditionally depending on the $skiplock parameter and
then simply calls destroy_vm() inside lock_config() which
did yet another check_lock() without any way to avoid that.
Added the $skiplock parameter to destroy_vm() and removed
the conditional check in vm_destroy() as both happened after
locking the config.
This add support for net trunks vlan filtering
for ovs and linux vlan-aware bridge
Can be mixed with current "tag" option
examples:
----------
allow only 802.1Q packets with vlanid 2,3,4 :
netx: .....,trunks=2,3,4
allow only 802.1Q packets with vlanid 2,3,4 and tag non-802.1Q packets to vlanid 5 :
netx: tag=5,trunks=2,3,4
tag non-802.1Q packets to vlanid 5
netx: tag=5
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
x-vga vfio-pci flag is to enable seabios quirks only.
This patch keep using x-vga=on from proxmox config, to disable hyperv,kvm=off,vga=none by default
but don't pass x-vga to vfio-pci when ovmf is enabled.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
On some storages BLKZEROOUT commands do not work properly
and return without error while having no effect whatsoever.
This can produce various filesystem errors and thus needs
to be made optional.
A drive can now have 'detect_zeroes=off' to disable this
behavior. By default the behavior is the same as before:
always-on (and set to 'unmap' if discard is enabled).
get_used_paths returned a hash of used paths for all the
volumes in a VM's config, which is not enough to figure out
whether there are snapshots, as snapshots often have
different paths. Eg. on ZFS it is not enough to check for
/dev/zvol/tank/vm-123-disk-1 because the snapshot's path is
/dev/zvol/tank/vm-123-disk-1@snap1 and thus we allowed
deleting the drive. Then when trying to delete the snapshot
later you get:
zfs error: cannot open 'tank/vm-751-disk-1': dataset does not exist
and it refuses to delete the snapshot.
Since its only use was to check whether or not a drive is
still in use it is now renamed to is_volume_in_use and
beside checking paths now also checks volume-ids as those
should stay the same.
use it for nic hotplug, because pve-bridge script will
not work after a live migration, because of the PVE_MIGRATED_FROM env var.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Users have reported resume bug when HA is used.
They seem to have a little race (bench show >0s < 1s) between the vm conf file move on source node and replication to,
and resume on target node.
I don't known why this is only with HA, maybe this occur will standard migration too.
Anyway, we don't need to read the vm config file to resume the vm on target host,
as we are sure that the vm is migrated, and config file move action is correct in the cluster.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
used to prevent an unintended virtual machine remove operation
v3 changes:
- changed man page message
- removed protection parameter (where not needed)
The -force flag didn't have any effect since the pending
changes didn't carry over the the flag.
Now forced deletes have an exclamation mark prepended to the
option name.
qemu 2.4 feature
changelog: rebase on last git
Note that currently linux guest don't support unplug of dimm when it'sused by kernel memory.
They are some tunning to do with memory zone movable.
http://events.linuxfoundation.org/sites/events/files/lcjp13_chen.pdf
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Changed from old, now missing, subroutine parse_startup() to new
pve_parse_startup_order() in qemu-server and pve-manager
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Currently enforce with cpumodel=host on amd cpus don't work,
because amd cpus have unsupported flags in qemu.
This is a protection, and this is good.
but cpumodel host should be never use by users for production (only for testing).
For production and stability, users need to choose a true cpu model which filter
the supported cpuflags by qemu.
So I think we can remove the enforce for host model as for testing it's ok.
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 0]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 1]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 2]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 3]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 4]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 5]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 6]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 7]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 8]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 9]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 12]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 13]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 14]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 15]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 16]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 17]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 23]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 24]
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
rdtscp is not supported by qemu and with enforce it's not starting
warning: host doesn't support requested feature: CPUID.80000001H:EDX.rdtscp [bit 27]
from to qemu wiki
http://wiki.qemu.org/Features/CPUModels#Disabling_features_that_were_always_disabled_on_KVM
"Fact: currently libvirt runs CPU models having rdtscp without the "enforce" flag, and rdtscp is silently disabled
Consequence: libvirt SHOULD use something like "-cpu Opteron_G5,-rdtscp",
especially when it starts using (or emulating) enforce mode
This will require a solution on libvirt side. QEMU will just provide the mechanisms to report CPU model information
and check what the host and QEMU supports, but the decision to disable rdtscp to be able
to run Opteron_G[2345] needs to be taken by libvirt."
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Only non-cdrom drives default to cache=none, so the check
for whether to default to aio=native needs to take the same
condition into account.
I combined them close together to make their relation more
visible.
