it works™, but yet unused, add nonetheless to make it easier to pick
up and complete this testing work.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
as a hack to avoid that we hit a code path where the current ones
from the hosts are checked, and the command line option is added
depending if it exists or not.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
try to increase variable declaration to use locality, reduce
duplication of same variable names used, and try to cleanup a bit in
general..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
For non pci express passthrough additional addresses are reserved.
For pcie passthrough pcie root ports are needed (unless guest is like
windows 7).
The first 4 pcie root ports are defined by default in the pve-q35*.cfg
files. If more than 4 pcie devices are passed through the needed root
ports are created on demand. This helps to keep live migration possible
without adding a new pve-q35*.cfg file.
For the windows 7 like guests additional addresses are reserved as well.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
This adds a new config option called `spice_enhancements` with two
optional settings:
* videostreaming
* foldersharing
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Live migration with a local cloudinit disk was never intended to work. It did
however work to an extent that the migration completed but the disk on the
source node could not be deleted. Now die if a live migration is started with
a local cloudinit disk.
With the GUI changes live migration is already disabled as it recognizes the
cloudinit disk as a local resource.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
for some reason not setting port results in a port of '65535' which
triggers an execption in http-server anyevent, so we set the port to 0
also, we have to read the ticket from stdin even for 'unix' type secure
migration
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we now also save the mtime of the binary and cache per binary (for each
arch; this is done so we have it already when we sometime decide
that we want to split the qemu package for each arch)
so that we get the real version if only pve-qemu-kvm was updated
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
A generated VM with default values does not set the memory key in the
configuration. Hence the size of the state file for a suspend had only
the default size of the state itself and not in addition twice the
configured memory.
The patch uses the static defaults from the JSON schema if the memory
key is not set.
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
The latest changes to our audio device implemenation [0] changed the
naming of the device id to "audio<id>" which in practice resulted in
"audio0".
This conflicts with the predefined audio device in the Q35 configs
that is also using "audio0". The result is that a VM with a
configured audio device and Q35 type will not start.
While we just would had removed the audio0 device if we had detected
this earlier in the new 4.0 q35 config, we cannot do so anymore due
to migration compatibility.
So rename the device from "audio$id" to audiodev$id".
Co-authored-by: Aaron Lauterer <a.lauterer@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Both flags were causing issues and have been made into optional flags to
be manually selected by the user if needed.
The supported flags have been merged into a single list for convenience.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
QEMU 4 adds the `-audiodev` parameter to explicitly specify the audio
backend. Setting it avoids occasional error messages when starting a
virtual machine with an audio device and qemu wants to connect it to the
physical audio device.
For now only SPICE is supported as it's also the biggest use case.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
die if we get some unknown value, which is either a bug (new dev type
added to enum but not here) or a user manual edit error, good to
ccatch both
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Until now audio devices had to be added manually with the `args` option
in the VMs config file. This adds a new config option to define an audio
device. It is called `audio0` with the extra `0` to be prepared should
we ever implement support for more than one audio device.
Supported devices are:
* ich9-intel-hda: Intel HD Audio Controller, emulates ICH9
* intel-hda: Intel HD Audio Controller, emulates ICH6
* AC97: useful for older OSs like Win XP
If any of the `intel-hda`s is selected two additional devices will be
created: hda-micro and hda-duplex. The `*intel-hda` controllers need at
least one of them as they emulate microphones and speakers (hda-micro)
or line in and out devices (hda-duplex).
Having both is deemed best practice to avoid problems if some software
needs one of the other kind of output/input ports.
I also cleaned up some old, commented out, code regarding audio devices.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
with qemu 4.0 we can make use of the new pcie-root-ports with settings
for the width/speed which can resolve issues with some hardware combinations
when negioating link speed
so we add a new q35 cfg that we include with machine types >= 4.0
to preserve live migration of machines without passthrough but q35
for details about the link speeds see:
pcie: Enhanced link speed and width support
https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02827.html
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
If 'now' is passed to the startdate option, the kvm start fails with
below failure.
kvm: invalid datetime format
valid formats: '2006-06-17T16:01:21' or '2006-06-17'
With this patch, 'now' is ignored and not passed to the rtcflags (-rtc).
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
e.g. local storage was considered not allowed for offline migration
even if it is available on all nodes, this should now be fixed as it
is now considered available on all nodes if a local storage isn't
restricted to a specific subset of the available nodes. The user is
responseable to make sure that the datacenter storage config reflects
the actual setup, so there is no additional check for local storages
which aren't available on all nodes if they are not explicitly marked
at datacenter level.
Signed-off-by: Tim Marx <t.marx@proxmox.com>
This is required for Windows to recognize the ISO and as a result the cloudinit
config. This is the minimum to get any config working at all for windows.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Regression from change allowing timeouts to be set, now shutting down
also works without timeouts again (previously qmp failed because of
the unknown "timeout" parameter passed to it).
We always delete the timeout value from the arguments, regardless of
truthiness. "delete" returns the deleted element, deleting a
non-existant hash entry returns undef, which is fine after this point:
"deleting non-existent elements returns the undefined value in their
corresponding positions."
- https://perldoc.perl.org/functions/delete.html
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
while it really should not pose an issue for live migrations lets be
on the safe side and also add this only with 3.1 or later machines
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Kernels 4.18+ (4.17+ for evmcs) support new Hyper-V enlightenments for
Windows KVM guests. QEMU supports these since 3.0 and 3.1 respectively.
tlbflush and ipi improve performance on overcommitted systems, evmcs
improves nested virtualization.
It's not entirely clear to me if Win7 already supports these, but since
it doesn't cause any performance penalties (and it works fine without
crashing, which makes sense either way, because Hyper-V enlightenments
are opt-in by the guest OS), enabling it regardless should be fine.
(As opposed to adding a new if branch for win8+)
Feature explanations to the best of my understanding:
hv_tlbflush allows the guest OS to trigger tlb shootdowns via a
hypercall. This allows CPUs to be identified via their vpindex (which
makes hv_vpindex a prerequisite to hv_tlbflush, but that is already
handled in our code). In overcommited configurations, where multiple
vCPUs reside on one pCPU, this increases performance of guest tlb
flushes, by only flushing each pCPU once. It also allows multiple tlb
flushes with only one vmexit.
hv_ipi allows sending inter-processor interrupts via vpindex, once again
making it a prerequisite. Benefits are pretty much as with tlbflush.
hv_evmcs is a VM control structure in L1 guest memory, allowing an L1 guest
to modify L2 VMCS and entering L2 without having the L0 host perform an
expensive VMCS update on trapping the nested vmenter.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
