We allocate a temporary bitmap but never free it.
Introduced by <commit 1f8a1a9>:
qemu: Do not use qemuMonitorSetMigrationCapability
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Create a new vsock endpoint by opening /dev/vhost-vsock,
set the requested CID via ioctl (or assign a free one if auto='yes'),
pass the file descriptor to QEMU and build the command line.
https://bugzilla.redhat.com/show_bug.cgi?id=1291851
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Add a new 'vsock' element for the vsock device.
The 'model' attribute is optional.
A <source cid> subelement should be used to specify the guest cid,
or <source auto='yes'/> should be used.
https://bugzilla.redhat.com/show_bug.cgi?id=1291851
Signed-off-by: Ján Tomko <jtomko@redhat.com>
When status XML was parsed the post-parse callbacks could not access
qemu caps and potentially upgrade the definition according to the
present caps. Implement the callback to pass it in.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Trying to set any cache for <disk device='lun'/> makes no sense.
Such disk translates into -device scsi-block on the command line
and the device lacks any cache setting because it's merely a
middle man between qemu and real SCSI device.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The function creates a list of all (or migratable only) CPU features
supported by QEMU. It works by looking at the CPU model info returned by
query-cpu-model-expansion QMP command.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
When computing a baseline CPU for a specific hypervisor we have to make
sure to include only CPU features supported by the hypervisor. Otherwise
the computed CPU could not be used for starting a new domain.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
This is required for virCPUBaseline to accept a list of guest CPU
definitions since they do not have arch set.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
virConnectGetDomainCapabilities needs to lookup QEMU capabilities
matching a specified binary, architecture, virt type, and machine type
while using default values when any of the parameters are not provided
by the user. Let's extract the lookup code into
virQEMUCapsCacheLookupDefault to make it reusable.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainDetachDeviceAlias API is designed so that it only
sends detach request to qemu. It's user's responsibility to wait
for DEVICE_DELETED event, not libvirt's. Add @async flag to
qemuDomainDetach*Device() functions so that caller can chose if
detach is semi-synchronous (old virDomainDetachDeviceFlags()) or
fully asynchronous (new virDomainDetachDeviceFlags()).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The fact that we are overwriting @ret multiple times makes it
difficult to see what is actually happening here. Follow our
traditional pattern where @ret is initialized to -1, and set to 0
only in case we know we succeeded.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Funny, we obtain driver caps at the beginning of the function,
but then for unknown reason access driver->caps directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We are overwriting @ret a lot. It makes hard to see what is
actually going on. Use more gotos. Two functions are fixed here:
qemuDomainDetachShmemDevice() and qemuDomainDetachWatchdog().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
On watchdog unplug, when qemu doesn't support DEVICE_DELETED event
(or couple of other reasons) we do two things:
1) release watchdog device address,
2) call qemuDomainRemoveWatchdog() which does 1) again.
This is potentially dangerous.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
On shmem unplug, when qemu doesn't support DEVICE_DELETED event
(or couple of other reasons) we do two things:
1) release shmem device address,
2) call qemuDomainRemoveShmemDevice() which does 1) again.
This is potentially dangerous.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Instead of releasing address only sometimes in
qemuDomainDetachChrDevice() let's release it whenever the device
is actually removed from the domain definition.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Report domaincaps <features><genid supported='yes'/> if the guest
config accepts <genid/> or <genid>$GUID</genid>.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1149445
If the domain requests usage of the genid functionality,
then add the QEMU '-device vmgenid' to the command line
providing either the supplied or generated GUID value.
Add tests for both a generated and supplied GUID value.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Before we generate the command line for qemu, if the domain about to
be launched desires to utilize the VM Generation ID functionality, then
handle both the regenerating the GUID value for backup recovery (restore
operation) and the startup after snapshot as both require a new GUID to
be generated to allow the guest operating system to recognize the VM
is re-executing something that has already executed before.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Add the query of the device objects for the vmgenid device
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Rather than a lot of checks use a switch statement. This optimizes the
code as if one device is matched the rest will certainly not match.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Later on, more stuff will be added so prevent the main function growing
out of control.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
After the text monitor was deleted this event can't be triggered.
Remove it and all the unnecessary code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Drop all conditional calls which have JSON variants, now that we
guarantee JSON monitor.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu did not QAPIfy these and the design and name will most probably
change. The replacements will not be compatible. Drop the JSON stubs and
annotate that there won't be a replacement.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are no callers for these. Remove them and the monitor
implementations.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The QMP version was added in qemu commit e4c8f004c55d9da3eae3e14 which
is included in v1.3.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The QMP version was added in qemu commit ab49ab5c488237f3656689 which
is included in v1.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Implement the secure way to transport non-shared storage data across
migrations. The new approach uses blockdev-add to create the NBD client
so that the TLS secret object can be specified.
https://bugzilla.redhat.com/show_bug.cgi?id=1300772
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Separate the code relevant for this approach so that we can later add a
second implementation without making the function messy.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Drop the mention of 'drive mirror' from the function names and mention
NBD. This will help when adding the 'blockdev mirror' migration code
which will allow using TLS.
Additionally fix some of the function comments to make more sense
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Allow saving various aspects necessary to do NBD migration via blockdev
by storing a 'virStorageSource' in the disk private data meant to store
the NBD target of migration. Along with this add code to parse and
format it into the status XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Extract the NBD portion of the 'job' status XML element parser into a
separate function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We will be adding source data to it so extract it to a separate function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
These helpers add infrastructure which simplifies adding and rolling
back virStorageSources to a running qemu instance. Using of the helper
structure and separate functions allows for a much cleaner code in the
section dealing with the monitor.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
drive-mirror allows only file targets. Introduce support for
blockdev-mirror that is able to copy to any BDS described by a node name
in qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Move formatting of the qemu command out of qemuMonitorJSONMakeCommandRaw
to qemuMonitorJSONMakeCommandInternal to allow greater reusability and
document the function better.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The capability also represents that 'blockdev-add' is functional. It's
necessary to detect it via presence of 'blockdev-del' since blockdev-add
did not have the unsupported 'x-blockdev-add' version previously and
thus would be marked as present even if we could not use it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
