A file for vsock-related helper functions.
virVsockSetGuestCid to set an already-known CID,
virVsockAcquireGuestCid that will use the first available CID
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>
A type to represent the new vsock device.
Also implement an allocation function to allow future addition
of private data.
https://bugzilla.redhat.com/show_bug.cgi?id=1291851
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Remove the locks since they are unnecessary and would cause
a hang for a driver reload/restart when a transient pool was
previously active as a result of the call:
virStoragePoolUpdateInactive:
...
if (!virStoragePoolObjGetConfigFile(obj)) {
virStoragePoolObjRemove(driver->pools, obj);
...
stack trace:
Thread 17 (Thread 0x7fffcc574700 (LWP 12465)):
...pthread_rwlock_wrlock
...virRWLockWrite
...virObjectRWLockWrite
...virStoragePoolObjRemove
...virStoragePoolUpdateInactive
...storagePoolUpdateStateCallback
...virStoragePoolObjListForEachCb
...virHashForEach
...virStoragePoolObjListForEach
...storagePoolUpdateAllState
...storageStateInitialize
...virStateInitialize
...daemonRunStateInit
...virThreadHelper
...start_thread
...clone
Introduced by commit id 4b2e0ed6e3.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@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>
The status XML parser function virDomainObjParseXML could not pass in
parseOpaque into the post parse callbacks. Add a callback which will
allow hypervisor drivers to fill it from the 'virDomainObj' data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
When parsing status XML the post-parse callbacks can't access any
private data present in the status XML as the private bits were parsed
after invoking post-parse callbacks.
Move the invocation so that everything is parsed first.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Its only use is now to check for duplicate boot order values,
which is now also done in virDomainDefPostParseCommon.
Remove it completely.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
As the function signature of virDomainDefPostParseInternal does not
differ from virDomainDefPostParse now, the wrapper can be dropped.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Move the check for boot elements into a separate function
and remove its dependency on the parser-supplied bootHash table.
Reconstructing the hash table from the domain definition
effectively duplicates the check for duplicate boot order
values, also present in virDomainDeviceBootParseXML.
Now it will also be run on domains created by other means than XML
parsing, since it will be run even for code paths that did not supply
the bootHash table before.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Further patches will introduce validation and a default setting
of def->os.bootDevs in postParse.
Introduce a feature flag to opt out of this and set it in the vmx
driver, otherwise we would be adding it <boot dev='hd'/> into every
vmx config despite having no way to change it.
Signed-off-by: Ján Tomko <jtomko@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>
To make it more consistent with the rest of the CPU driver code.
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>
Modern host CPU models from domain capabilities XMLs are reported as
guest CPU definitions with feature policies. This patch updates
virCPUx86Baseline to properly handle such CPU models.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The new API computes the most feature-rich CPU which is compatible with
all given CPUs and can be provided by the specified hypervisor. It is a
more useful version of virConnectBaselineCPU, which doesn't consider any
hypervisor capabilities when computing the best CPU.
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 new API compares the given CPU description with the CPU the
specified hypervisor is able to provide on the host. It is a more useful
version of virConnectCompareCPU, which compares the CPU definition with
the host CPU without considering any specific hypervisor and its
abilities.
https://bugzilla.redhat.com/show_bug.cgi?id=1559832https://bugzilla.redhat.com/show_bug.cgi?id=1559835
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>
When detaching a device it can be uniquely identified by its
alias. Instead of misusing virDomainDetachDeviceFlags which has
the same signature introduce new function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1400475
In order to avoid a possible error as a result of kernel interactions
with the partition helper, let's use virWaitForDevices to force things
to settle down before attempting to open and read the partition. This
is related to https://bugzilla.redhat.com/show_bug.cgi?id=1264719.
Although perhaps overkill to have too many places to settle, since
we know that the act of reading the partitions via libvirt_parthelper
will cause udev activity/events - we just need to ensure udev has
been settled before proceding with usage of the device.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@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>
The VM Generation ID is a mechanism to provide a unique 128-bit,
cryptographically random, and integer value identifier known as
the GUID (Globally Unique Identifier) to the guest OS. The value
is used to help notify the guest operating system when the virtual
machine is executed with a different configuration.
This patch adds support for a new "genid" XML element similar to
the "uuid" element. The "genid" element can have two forms "<genid/>"
or "<genid>$GUID</genid>". If the $GUID is not provided, libvirt
will generate one and save it in the XML.
Since adding support for a generated GUID (or UUID like) value to
be displayed modifying the xml2xml test to include virrandommock.so
is necessary since it will generate a "known" value.
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>
