and user calls `snapshot-delete snap1 --children-only` the current
snapshot is external but all the children snapshots are internal only
and we are able to delete it.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Previously the reparent happened before the actual snapshot deletion.
This change moves the code closer to the rest of the code handling
snapshot metadata when deletion happens. This makes the metadate
deletion happen after the data files are deleted.
Following patch will extract it into separate function
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Thu, 15 Dec 2022 14:40:45 +0000 (15:40 +0100)]
qemu_snapshot: rework snapshot children deletion
This simplifies the code a bit by reusing existing parts that deletes
a single snapshot.
The drawback of this change is that we will now call the re-parent bits
to keep the metadata in sync for every child even though it will get
deleted as well.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Wed, 22 Jun 2022 10:13:45 +0000 (12:13 +0200)]
qemu_blockjob: process QEMU_MONITOR_JOB_STATUS_PENDING signal
QEMU emits this signal when the job finished its work and is about to be
finalized. If the job is started with autofinalize disabled the job
waits for user input to finalize the job.
This will be used by snapshot delete code.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Tue, 13 Dec 2022 15:40:02 +0000 (16:40 +0100)]
qemu_monitor_json: allow configuring autofinalize for block commit
Deleting external snapshots will require configuring autofinalize to
synchronize the block jobs for disks withing single snapshot in order to
be able safely abort of one of the jobs fails.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Tue, 21 Jun 2022 13:22:15 +0000 (15:22 +0200)]
qemu_monitor: introduce qemuMonitorJobFinalize
Upcoming snapshot deletion code will require that multiple commit jobs
are finished in sync. To allow aborting then if one fails we will need
to use manual finalization of the jobs.
This commit implements the monitor code for `job-finalize`.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Mon, 5 Dec 2022 12:11:19 +0000 (13:11 +0100)]
qemu_block: add async domain job support to qemuBlockCommit
This will allow to use it while having async domain job active which we
will use when deleting external snapshots. At the same time we will need
to have the block job started as synchronous.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Up until commit 629282d88454, using mode=restrictive caused
virNumaSetupMemoryPolicy() to be called from qemuProcessHook(),
and that in turn resulted in virNumaNodesetIsAvailable() being
called and the nodeset being validated.
After that change, the only validation for the nodeset is the one
happening in qemuBuildMemoryBackendProps(), which is skipped when
using mode=restrictive.
Make sure virNumaNodesetIsAvailable() is called whenever a
nodeset has been provided by the user, regardless of the mode.
tests: Add cases for numatune with unavailable nodes
The one for mode=strict fails, as expected, while the one for
mode=restrictive currently doesn't even though it should. The
next commit will address the issue.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Thu, 15 Dec 2022 13:12:43 +0000 (14:12 +0100)]
qemu: Remember failed post-copy migration in job
When post-copy migration fails, the domain stays running on the
destination with a VIR_DOMAIN_RUNNING_POSTCOPY_FAILED reason. Both the
state and the reason can later be rewritten in case the domain gets
paused for other reasons (such as an I/O error). Thus we need a separate
place to remember the post-copy migration failed to be able to resume
the migration.
Jiri Denemark [Wed, 7 Dec 2022 13:46:25 +0000 (14:46 +0100)]
conf: Drop virDomainJobOperation parameter from virDomainObjIsPostcopy
The parameter was only used to select which states correspond to an
active or failed post-copy migration. But these states are either
applicable to both operations or the check would just paper over a code
bug in case of an impossible combination of state and operation. By
dropping the check we can make the code simpler and also reuse existing
virDomainObjIsFailedPostcopy function and only check for active
post-copy states.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 3 May 2022 13:10:37 +0000 (15:10 +0200)]
qemuxml2argvtest: Add seclabels in <backingStore> to disk-backing-chains-(no)index
Commit da9f3cd84b250088 added the seclabel example into the
'disk-backing-chains' case.
Since the only thing that 'disk-backing-chains' tests which
'disk-backing-chains-(no)index' don't test is the seclabel we'll be able
to remove the test case if we add the seclabel example.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Mon, 29 Aug 2022 15:08:57 +0000 (17:08 +0200)]
qemu: Use new connection close callbacks API
The qemu driver uses connection close callbacks in more places requiring
more changes than other drivers, but luckily the changes are very
straightforward. The migration code was written in a way ensuring that
there's just one callback present so this can be preserved directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Mon, 29 Aug 2022 14:13:58 +0000 (16:13 +0200)]
bhyve: Use new connection close callbacks API
The rewrite is straightforward as bhyve registers only the
'bhyveProcessAutoDestroy' callback which by design doesn't need any
special handling (there's just one caller which can start the VM thus
implicitly there's only one possible registration for that function).
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Mon, 29 Aug 2022 14:13:58 +0000 (16:13 +0200)]
lxc: Use new connection close callbacks API
The rewrite is straightforward as LXC registers only the
'lxcProcessAutoDestroy' callback which by design doesn't need any
special handling (there's just one caller which can start the VM thus
implicitly there's only one possible registration for that function).
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Thu, 6 Oct 2022 13:20:13 +0000 (15:20 +0200)]
virclosecallbacks: Add new close callbacks APIs
The new APIs store the list of callbacks for a VM inside the
virDomainObj and also allow registering multiple callbacks for a single
domain and also for multiple connections.
For now this code is dormant until each driver using the old APIs is not
refactored to use the new APIs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Wed, 13 Jul 2022 12:02:18 +0000 (14:02 +0200)]
conf: domain: Add helper infrastructure for new connection close callbacks
The new connect close callbacks for domains will be represented by a
virObject associated with the domain object itself.
To simplify handling the pointer to the close callback data will be done
by an immutable pointer allocated directly when allocating the
corresponding virDomainObj struct.
This patch adds the 'closecallbacks' field to virDomainObj and a
corresponding callback to allocate it into virDomainXMLOption.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Introduce a helper which will return a list of all domain objects inside
of the list without filtering and thus without the need to lock
individual members.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Shaleen Bathla [Wed, 28 Dec 2022 14:47:12 +0000 (20:17 +0530)]
nwfilter: use time_t for timeout for consistency
Coverity scan reports:
"A time_t value is stored in an integer with too few bits to accommodate
it. The expression timeout is cast to unsigned int"
We are already casting and storing time_t timeout variable into unsigned int.
We can use time_t for timeout and cast it to unsigned long (should be big enough)
instead of unsigned int in sscanf, g_strdup_printf as required.
Signed-off-by: Shaleen Bathla <shaleen.bathla@oracle.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
qemu_namespace: Move umount() call into #fdef __linux__
In a recent commit I've introduced an umount() call. But the
function where the call lives is compiled on all OSes, not just
Linux. But umount() is Linux specific. Other OSes have unmount
(FreeBSD), or maybe something else. But since namespaces are
Linux specific, we can wrap the call in #ifdef __linux__ and not
care about other OSes.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When calling virConnectGetDomainCapabilities() (exposed as virsh
domcapabilities) users have option to specify whatever sub-set of
{ emulatorbin, arch, machine, virttype } they want. Then we have
a logic (hidden in virQEMUCapsCacheLookupDefault()) that picks
qemuCaps that satisfy values passed by user. And whatever was not
specified is then set to the default value as specified by picked
qemuCaps. For instance: if no machine type was provided but
emulatorbin was, then the machine type is set to the default one
as defined by the emulatorbin.
Or, when just virttype was set then the remaining three values
are set to their respective defaults. Except, we have a crasher
in this case:
# virsh domcapabilities --virttype hvf
error: Disconnected from qemu:///system due to end of file
error: failed to get emulator capabilities
error: End of file while reading data: Input/output error
This is because for 'hvf' virttype (at least my) QEMU does not
have any machine type. Therefore, @machine is set to NULL and the
rest of the code does not expect that.
What we can do about this is to validate all arguments. Well,
except for the emulatorbin which is obtained from passed
qemuCaps. This also fixes the issue when domcapabilities for a
virttype of a different driver are requested, or a different
arch.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
qemu_namespace: Fix detection of nested mount points
When deciding whether to bind mount a path in domain's namespace,
we look at the QEMU mount table (/proc/$pid/mounts) and try to
match prefix of given path with one of mount points. Well, we
do that in a bit clumsy way. For instance, if there's
"/dev/hugepages" already mounted inside the namespace and we are
deciding whether to bind mount "/dev/hugepages1G/..." we decide
to skip over the path and NOT bind mount it. This is because
plain STRPREFIX() is used and yes, the former is prefix of the
latter. What we need to check also is whether the next character
after the prefix is slash.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Fri, 16 Dec 2022 13:58:25 +0000 (14:58 +0100)]
qemu_namespace: Umount the original /dev before replacing it with tmpfs
Our code relies on mount events propagating into the namespace we
create for a domain. However, there's one caveat. In v8.8.0-rc1~8
I've tried to make us detect differences in mount tables between
the namespace in which libvirtd runs and the domain namespace.
This is crucial for any mounts that happen after the domain was
started (for instance new hugetlbfs can be mounted on say
/dev/hugepages1G).
Therefore, we take a look into /proc/$(pgrep qemu)/mounts to see
what filesystems are mounted under /dev. Now, since we don't
umount the original /dev, just mount a tmpfs over it, we get all
the events (e.g. aforementioned hugetlbfs mount on
/dev/hugepages1G), but we are not really able to access it
because of the tmpfs that's placed on top. This then confuses our
algorithm for detecting which filesystems are mounted (the
algorithm is implemented in qemuDomainGetPreservedMounts()).
To break the link between host's and guest's /dev we just need to
umount() the original /dev in the namespace. Just before our
artificially created tmpfs is moved into its place.
Fixes: 46b03819ae8d833b11c2aaccb2c2a0361727f51b
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2151869#c6 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Michal Privoznik [Wed, 21 Dec 2022 15:09:29 +0000 (16:09 +0100)]
qemu_capabilities: Report Hyper-V Enlightenments in domcapabilities
Inside of qemuCaps (for the corresponding accelerator) we have
full host CPU expansion stored, among with supported Hyper-V
Enlightenments. To report them in the domain capabilities, we
just have to pick those starting with "hv-" and see if we know
them.
You may notice that neither of our domaincapsdata test shows any
enlightenment. This is because the test works by parsing
corresponding qemucapabilitiesdata/caps_*.xml file and none of
these store the full host CPU expansion (hostCPU.fullQEMU)
because that is runtime piece of information and not formatted
into virQEMUCaps XML.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1717611 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Mon, 19 Dec 2022 14:48:02 +0000 (15:48 +0100)]
qemu_capabilities: Query for Hyper-V Enlightenments
Now that we have qemuMonitorGetCPUModelExpansion() aware of
Hyper-V Enlightenments, we can start querying it. Two conditions
need to be met:
1) KVM is in use,
2) Arch is either x86 or arm.
It may look like modifying the first call to
qemuMonitorGetCPUModelExpansion() inside of
virQEMUCapsProbeQMPHostCPU() would be sufficient but it is not.
We really need to ask QEMU for full expansion and the first call
does not guarantee that.
For the test data, I've just copied whatever
'query-cpu-model-expansion' returned earlier, therefore there are
no hv-* props. But that's okay - the full expansion is not stored
in cache (and thus not formatted in
tests/qemucapabilitiesdata/caps_*.replies files either). This is
purely runtime thing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Apart from setting @migratable prop to the
query-cpu-model-expansion command, we will need @hv-passthrough
so that we can query for expansion of Hyper-V Enlightenments
supported on the current host. The idea is to run:
The virDomainCapsEnumFormat() function does not return anything
but zero and none of its callers is interested in the failure
anyways. Switch its return type from integer to void.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
virDomainCapsEnumFormat: Switch to virXMLFormatElement()
We are formatting <enum/> element and its children using
virBufferAddLit(), virBufferAsprintf(), virBufferAdjustIndent(),
etc. Well, we can avoid that when switching to
virXMLFormatElement().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In a recent commit, when ditching virXPathULong() the parsing of
<selfvers/> was changed. But it was changed to virXMLPropUInt()
which is not correct because the value we're interested in is not
in an attribute but element itself.
Fixes: a3c7426839df25f4026707c5877be75f2461f5e9 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Peter Krempa [Mon, 19 Dec 2022 08:59:36 +0000 (09:59 +0100)]
util: qemu: Remove 'skipKey' argument from virQEMUBuildCommandLineJSONArrayFormatFunc prototype
Since we really only need to handle key skipping in the top level object
the caller doesn't at this point even pass it to the array formatting
helper function. Remove the unused argument.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Fri, 16 Dec 2022 16:00:26 +0000 (17:00 +0100)]
virqemu: Don't strip the requested key from nested objects
Skipping of a specific key is needed only for the top level object to
specially handle the object type. We must not pass it to any recursed
printing of nested objects as skipping keys there might be surprising
and also is unhandlable later when formatting the commandline.
Until now this did not pose a problem but was discovered when adding a
new netdev backend which has a nested config object which also has the
'type' key which was being skipped.
Modern usage will prefer JSON directly but fix the commandline generator
to prevent surprises.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Wed, 21 Dec 2022 08:55:50 +0000 (09:55 +0100)]
qemu_capabilities: Decrease scope of @hash in virQEMUCapsProbeQMPHostCPU()
The @hash variable inside of virQEMUCapsProbeQMPHostCPU() is used
only within a block, but declared at the beginning of the
function. Bring the variable declaration into the said block.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There's nothing qemu specific about
qemuDomainCapsFeatureFormatSimple() and in fact, the function
lives in hypervisor agnostic location and thus mustn't have qemu
prefix.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 21 Dec 2022 07:31:01 +0000 (08:31 +0100)]
docs: Recommend static seclabels for migration on shared storage
There are some network FSs (ceph, CIFS) that propagate XATTRs
properly and thus SELinux labels too. In such case using dynamic
seclabels would get in the way of migration as new seclabel is
assigned to the domain on the destination and thus two processes
with different labels (the source and the destination QEMU/helper
process) would try to access the same file. One of them is
necessarily going to be denied access.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 14 Dec 2022 09:33:51 +0000 (10:33 +0100)]
qemu_tpm: Open code qemuSecurityStartTPMEmulator()
When starting swtpm binary, the qemuSecurityStartTPMEmulator() is
called which sets seclabel on the TPM state and then uses
qemuSecurityCommandRun() to execute the swtpm binary with proper
seclabel. Well, the aim is to ditch
qemuSecurityStartTPMEmulator() because it entangles two distinct
operations. Just call functions for them separately.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 14 Dec 2022 14:12:38 +0000 (15:12 +0100)]
qemu_tpm: Restore TPM labels on failed start
If swtpm binary fails to start after successful exec() (e.g. it
fails to initialize itself), the seclabels set in
qemuSecurityStartTPMEmulator() are not restored. This is due to
lacking qemuSecurityRestoreTPMLabels() call in the error path.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that we have qemuSecurityRestoreTPMLabels() we might as well
have qemuSecuritySetTPMLabels(). The aim here is to remove
qemuSecurityStartTPMEmulator() which couples two separate things
into a single function call.
Therefore, introduce qemuSecuritySetTPMLabels() which does only
set seclabels on the TPM state.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The qemuSecurityCleanupTPMEmulator() function calls
virSecurityManagerRestoreTPMLabels() and thus the proper name is
qemuSecurityRestoreTPMLabels(). Rename it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently, qemuSecurityCleanupTPMEmulator() returns nothing which
means a caller (well, there's only one - qemuExtTPMStop()) can't
produce a warning when restoring seclabels on TPM state failed.
True, qemuSecurityCleanupTPMEmulator() does report a warning
itself, but only in one specific error path.
Make the function return an integer, just like the rest of
qemuSecurity*Restore() functions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Tue, 3 Jan 2023 09:03:06 +0000 (10:03 +0100)]
qemu: Use '-machine hpet=off' instead of '-no-hpet'
qemu is about to deprecate the '-no-hpet' option in favor of configuring
the timer via '-machine'.
Use the QEMU_CAPS_MACHINE_HPET capability to switch to the new syntax
and mask out the old QEMU_CAPS_NO_HPET capability at the same time to
prevent using the old syntax.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
The capability represents that qemu accepts the configuration of the
HPET timer via -machine hpet=on/off rather than the
soon-to-be-deprecated '-no-hpet' option.
The capability is detected from 'query-command-line-options' which
recently added the 'hpet' option.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
- query-command-line-options now reports more accurate data
- machine types for the 8.0 cycle were added
- vhost-vdpa device support was added
- default value of 'noreboot' changed from 'true' to 'false'
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2033879 Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 21 Dec 2022 10:08:02 +0000 (11:08 +0100)]
qemumonitortestutils: Fix line counting in qemuMonitorTestProcessFileEntries()
It just so happens that our JSON snippets in
qemucapabilitiesdata/*.replies files are separated by an empty
line. These empty lines are then overwritten to make a single
line JSON. Nevertheless, the line counter @line is not
incremented which then leads to a misleading numbers in errors.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 20 Dec 2022 08:04:48 +0000 (09:04 +0100)]
secret: Inhibit shutdown for ephemeral secrets
Our secret driver divides secrets into two groups: ephemeral
(stored only in memory) and persistent (stored on disk). Now, the
aim of ephemeral secrets is to define them shortly before being
used and then undefine them. But 'shortly before being used' is a
very vague time frame. And since we default to socket activation
and thus pass '--timeout 120' to every daemon it may happen that
just defined ephemeral secret is gone among with the virtsecretd.
This is no problem for persistent secrets as their definition
(and value) is restored when the virtsecretd starts again, but
ephemeral secrets can't be restored.
Therefore, we could view ephemeral secrets as active objects that
the daemon manages and thus inhibit automatic shutdown (just like
hypervisor daemons do when a guest is running).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Xen 4.17 has strict parsing of 'soundhw' option that allows only
specific values (instead of passing through any value directly to
qemu's -soundhw option, it uses -device now). For 'intel-hda' audio
device, it requires "hda" string. "hda" works with older libxl too.
Other supported models are the same as in libvirt XML.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
libxl: add validation if sound device is supported
Xen supports only subset of libvirt's sound devices, and starting with
Xen 4.17 it is enforced by libxl. Verify it early.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
projects / libvirt.git / log