tests: validate an XML config with USB bus/port set
USB bus/port addressing is translated into a bus/device addressing
at startup using the hostdev logic. This test covers XML parsing
and CLI formatting for bus/port addressing.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
This patch implements USB bus/port matching in the XML schema.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
[DB: split host USB search parts out into previous patches] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
util: implement support for finding host USB devices by port
Extend the API for finding host USB devices, to allow requesting
a search based on the port.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
[DB: split out of bigger patch] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for adding the ability to find host USB devices based
on their port, by generalizing the APIs for device searching
into one all-purpose API
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
[DB: split out of bigger patch] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
virusb test data: add devpath files for port addressing
This patch adds devpath files to the virusb test data.
These files are mockups for the USB sysfs files that
contain the port of a USB device in dotted notation.
They are used for testing of USB bus/port matching.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
Since commit 99a637a8 in qemu 10.0, the way the cmp_legacy flag is
reported changed. The same way as happend with the 'ht' flag in commit c6bd2dd634208, which was fixed in libvirt since commit ba16113c.
This causes migrations from a hypervisor running a qemu version before
that commit to a hypervisor running qemu after that commit fails
with the following error:
guest CPU doesn't match specification: extra features: cmp_legacy
We can just ignore this flag, just like we did with the 'ht' flag.
The aim of cmdDomIfAddr() is to obtain IP addresses for given
domain and then print (ifName, MAC, type, IP Address) tuple.
Preferably in an aligned table. This is hard to do with printf
style of spacing ("%-NNs") since the interface name (ifName) can
vary a lot in length. Fortunately, we have vshTable which is
designed to handle this case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 21 Jan 2026 12:00:39 +0000 (13:00 +0100)]
qemu_command: Generate granule prop for virtio-iommu
Resolves: https://issues.redhat.com/browse/RHEL-76269 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 21 Jan 2026 11:54:17 +0000 (12:54 +0100)]
qemu_validate: Check whether granule of virtio-iommu is supported
Just like with other features, check whether QEMU supports them
based on capabilities. Now, instead of inventing a new QEMU
capability, an existing one can be used:
QEMU_CAPS_VIRTIO_IOMMU_AW_BITS.
This is because the aw-bits and granule attributes were
introduced into QEMU in close succession (v9.0.0-rc0~9^2~7
v9.0.0-rc0~9^2~11), neither can be disabled at compile time and
backporting just one without the other makes almost no sense.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 21 Jan 2026 11:51:20 +0000 (12:51 +0100)]
conf: Introduce granule attribute for virtio-iommu
In PCI assignment scenario the virtio-iommu needs to know the
guest page size also known as granule. Expose it as an attribute
to the <driver/> element of a virtio-iommu.
This is possibly interesting only for aarch64 since it supports
virtio-iommu and also supports running guests with different page
size than the host.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 21 Jan 2026 11:56:06 +0000 (12:56 +0100)]
qemu_command: Generate aw_bits prop for virtio-iommu
Resolves: https://issues.redhat.com/browse/RHEL-76269 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 21 Jan 2026 09:46:43 +0000 (10:46 +0100)]
conf: Allow aw_bits for virtio-iommu
Introduced in QEMU commit of v9.0.0-rc0~9^2~7 the virtio-iommu
device is also capable of using different addres width. The
corresponding attribute is also called 'aw-bits', just like in
case of intel-iommu. Wire up the missing pieces.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Fri, 23 Jan 2026 09:09:15 +0000 (10:09 +0100)]
conf: Teach virDomainParseMemory() new retval
So far, virDomainParseMemory() returns either 0 or -1. While this
allows callers to distinguish a success case from an error it
doesn't allow them to differentiate the case when no value was
provided in the XML, thus nothing was parsed and nothing was
required. Therefore, make virDomainParseMemory() return 1 on
success, 0 in case nothing was parsed and nothing was required,
and -1 on failure.
Arguably, no caller needs this distinction currently, but that is
about to change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
hyperv: Avoid memleak in hypervDomainDefParsePhysicalDisk
When parsing a physical disk, the @hostResouce is escaped once
with the retval being stored into @hostEscaped. Then, it's
escaped again, but the retval is stored into the very same
variable, leading to a leak where intermediate value is lost.
256 bytes in 1 blocks are definitely lost in loss record 469 of 483
at 0x49543A0: realloc (vg_replace_malloc.c:1804)
by 0x516C251: g_realloc (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x518BB7E: g_string_expand (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x518BFF9: g_string_insert_len (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x4A58B5F: g_string_append_len_inline (gstring.h:247)
by 0x4A58B5F: virBufferAdd (virbuffer.c:164)
by 0x4AFDA71: virStringReplace (virstring.c:708)
by 0x4DA4381: hypervDomainDefParsePhysicalDisk (hyperv_driver.c:1375)
by 0x4DA4A18: hypervDomainDefParseStorage (hyperv_driver.c:1487)
by 0x4DA9E31: hypervDomainGetXMLDesc (hyperv_driver.c:2761)
by 0x4DFB3E5: virDomainGetXMLDesc (libvirt-domain.c:2898)
by 0x406D39B: cmdDumpXML (virsh-domain.c:10787)
by 0x40B13B1: vshCommandRun (vsh.c:1383)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Libvirt vpx:// and esx:// URIs are quite obscure. In particular it is
very difficult to construct a correct path to a VMware resource.
Basically you are iterating over VMware structures blindly with no way
to know what your choices are at each level in the path.
This commit doesn't directly address this. It's still difficult. But
at least let's add the true path choices to the debug output so
someone could in theory use 'LIBVIRT_DEBUG=1' to find out what
possible choices exist at a path level.
For example this command fails because the label (which looks like an
IPv6 address, but is really a label) should use "::" instead of ":0:":
2026-02-05 10:58:25.421+0000: 1528876: debug : esxVI_LookupManagedObjectHelper:4956 : comparing path element 'aaaa:52:0:49e0:2eea:7fff:fee6:eca0' with candidate name 'aaaa:52::49e0:2eea:7fff:fee6:eca0'
2026-02-05 10:58:25.421+0000: 1528876: error : esxVI_Context_LookupManagedObjectsByPath:1098 : internal error: Could not find compute resource specified in '/data/aaaa:52:0:49e0:2eea:7fff:fee6:eca0/'
In an ideal world we should improve the error message to show the
possible choices, but the way the code is structured makes that
prohibitive.
Related: https://issues.redhat.com/browse/RHEL-145080 Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Driver capabilities are allocated at the beginning of mymain(),
but roughly in the middle the architecture is switched to aarch64
and capabilities are constructed again. Without freeing the old
ones.
704 (288 direct, 416 indirect) bytes in 1 blocks are definitely lost in loss record 328 of 332
at 0x4885098: calloc (vg_replace_malloc.c:1682)
by 0x4EE35CA: g_malloc0 (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x53314B8: g_type_create_instance (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x531A263: ??? (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x531975E: g_object_new (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x4AA9AB6: virObjectNew (virobject.c:252)
by 0x4AF0BBA: virCapabilitiesNew (capabilities.c:87)
by 0x401797B: virBhyveCapsBuild (bhyve_capabilities.c:51)
by 0x4012F57: mymain (bhyvexml2xmltest.c:60)
by 0x4016872: virTestMain (testutils.c:913)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
The firmwareDir member of driver config is set at the beginning
of mymain(). But then, roughly in the middle of test cases it is
overwritten to fakefirmwareemptydir. But this means the old value
must be freed. Or reassigned back to its original variable which
is freed automatically.
16 bytes in 1 blocks are definitely lost in loss record 190 of 505
at 0x4883224: malloc (vg_replace_malloc.c:451)
by 0x4EE6562: g_malloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F0100F: g_strdup (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4013E26: g_strdup_inline (gstrfuncs.h:321)
by 0x4013E26: mymain (bhyvexml2argvtest.c:151)
by 0x40189A2: virTestMain (testutils.c:913)
by 0x4013DE6: main (bhyvexml2argvtest.c:354)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
bhyvexml2argvtest: Don't leak parts of driver config
At the beginning of mymain() the virBhyveDriverConfigNew() is
called which inits driver config with some paths. These are
then overwritten to produce stable test output. Well, the old
ones should be freed first.
128 bytes in 1 blocks are definitely lost in loss record 453 of 508
at 0x4883224: malloc (vg_replace_malloc.c:451)
by 0x506BD16: vasprintf_l (in /lib/libc.so.7)
by 0x4F39073: g_vasprintf (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F01288: g_strdup_printf (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x401F75B: virBhyveDriverConfigNew (bhyve_conf.c:62)
by 0x4013FAA: mymain (bhyvexml2argvtest.c:164)
by 0x4018892: virTestMain (testutils.c:913)
by 0x4013DC6: main (bhyvexml2argvtest.c:352)
25 bytes in 1 blocks are definitely lost in loss record 206 of 508
at 0x4883224: malloc (vg_replace_malloc.c:451)
by 0x4EE6562: g_malloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F0100F: g_strdup (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x401F715: g_strdup_inline (gstrfuncs.h:321)
by 0x401F715: virBhyveDriverConfigNew (bhyve_conf.c:60)
by 0x4013FAA: mymain (bhyvexml2argvtest.c:164)
by 0x4018892: virTestMain (testutils.c:913)
by 0x4013DC6: main (bhyvexml2argvtest.c:352)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Driver capabilities are allocated at the beginning of mymain(),
but roughly in the middle the architecture is switched to aarch64
and capabilities are constructed again. Without freeing the old
ones.
1,583 (288 direct, 1,295 indirect) bytes in 1 blocks are definitely lost in loss record 520 of 536
at 0x4888098: calloc (vg_replace_malloc.c:1682)
by 0x4EE65CA: g_malloc0 (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x53344B8: g_type_create_instance (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x531D263: ??? (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x531C75E: g_object_new (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x4AAC806: virObjectNew (virobject.c:252)
by 0x4AF366A: virCapabilitiesNew (capabilities.c:87)
by 0x401998B: virBhyveCapsBuild (bhyve_capabilities.c:51)
by 0x4013E93: mymain (bhyvexml2argvtest.c:155)
by 0x4018882: virTestMain (testutils.c:913)
by 0x4013DC6: main (bhyvexml2argvtest.c:351)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
The bhyvexml2argvmock is loaded by bhyvexml2argvtest which calls
virBhyveCapsBuild() which in turn calls virCPUProbeHost(). To
make our test environment stable, it shouldn't depend on actual
CPU and thus mocked implementation for virCPUProbeHost should be
offered. Surprisingly, this is done in bhyveargv2xmlmock but not
in bhyvexml2argvmock. Until now.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
bhyve_command: Avoid memleak in bhyveBuildNetArgStr()
Inside of bhyveBuildNetArgStr() there is @nic_model which is
allocated, appended into cmd line and then freed under cleanup
label. Firstly, There are few cases where instead of jumping onto
the label there's a return statement (this alone can lead to a
memory leak), but more importantly - the variable doesn't need
dynamically allocated string. It's the same story with @brname.
After making them both const strings, the return statements can
be used more freely (up until first possible allocation).
6 bytes in 1 blocks are definitely lost in loss record 4 of 508
at 0x4883224: malloc (vg_replace_malloc.c:451)
by 0x4EE6562: g_malloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F0100F: g_strdup (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x401BC02: g_strdup_inline (gstrfuncs.h:321)
by 0x401BC02: bhyveBuildNetArgStr (bhyve_command.c:64)
by 0x401B362: virBhyveProcessBuildBhyveCmd (bhyve_command.c:1033)
by 0x4015F15: testCompareXMLToArgvFiles (bhyvexml2argvtest.c:72)
by 0x4015BB9: testCompareXMLToArgvHelper (bhyvexml2argvtest.c:144)
by 0x4016598: virTestRun (testutils.c:143)
by 0x4015121: mymain (bhyvexml2argvtest.c:275)
by 0x4018892: virTestMain (testutils.c:913)
by 0x4013DC6: main (bhyvexml2argvtest.c:352)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
bhyve_command: Avoid leaking @buf in virBhyveProcessBuildBhyveCmd()
When building OS loader part of bhyve command line, there's @buf
declared and it is even correctly annotated with g_auto() to be
freed automatically. But then, the buffer contents is appended
onto the command line using virBufferContentAndReset() which
leads to a memleak because the buffer is reset. It's
virBufferCurrentContent() that should have been used instead.
128 bytes in 1 blocks are definitely lost in loss record 476 of 536
at 0x48882B1: realloc (vg_replace_malloc.c:1810)
by 0x4EE6622: g_realloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F048BC: g_string_new (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4A59E1E: virBufferInitialize (virbuffer.c:121)
by 0x4A5A63C: virBufferVasprintf (virbuffer.c:321)
by 0x4A5A5DE: virBufferAsprintf (virbuffer.c:303)
by 0x401B22F: virBhyveProcessBuildBhyveCmd (bhyve_command.c:1021)
by 0x4015F05: testCompareXMLToArgvFiles (bhyvexml2argvtest.c:72)
by 0x4015BA9: testCompareXMLToArgvHelper (bhyvexml2argvtest.c:144)
by 0x4016588: virTestRun (testutils.c:143)
by 0x4015919: mymain (bhyvexml2argvtest.c:341)
by 0x4018882: virTestMain (testutils.c:913)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
bhyve: Avoid leaking @addrs in bhyveDomainAssignPCIAddresses()
Inside of bhyveDomainAssignPCIAddresses() the @addr variable is
allocated and in a few cases stolen into domain private data. But
in all other cases the associated memory is never freed.
12,800 (3,200 direct, 9,600 indirect) bytes in 100 blocks are definitely lost in loss record 533 of 538
at 0x4888098: calloc (vg_replace_malloc.c:1682)
by 0x4EE67D9: g_malloc0_n (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4AFD4AC: virDomainPCIAddressSetAlloc (domain_addr.c:1011)
by 0x4020F68: bhyveDomainPCIAddressSetCreate (bhyve_device.c:65)
by 0x40210BD: bhyveDomainAssignPCIAddresses (bhyve_device.c:219)
by 0x402180C: bhyveDomainAssignAddresses (bhyve_device.c:241)
by 0x4020083: bhyveDomainDefAssignAddresses (bhyve_domain.c:230)
by 0x4B71820: virDomainDefPostParse (domain_postparse.c:1503)
by 0x4B28282: virDomainDefParseNode (domain_conf.c:20565)
by 0x4B2810B: virDomainDefParse (domain_conf.c:20502)
by 0x4B281DF: virDomainDefParseFile (domain_conf.c:20549)
by 0x4015D6B: testCompareXMLToArgvFiles (bhyvexml2argvtest.c:47)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
The aim of bhyveParsePassthru() is to parse PCI address from
bhyve command line. The PCI address might be of a form
bus:slot:function or bus/slot/function. If the former isn't found
the latter is parsed (both using g_strsplit()). But after the
first call, g_strsplit() just returns a string list containing
but the whole input duplicated. Therefore, calling plain g_free()
is not enough, the array must be freed too.
6 bytes in 1 blocks are definitely lost in loss record 1 of 325
at 0x4863224: malloc (vg_replace_malloc.c:451)
by 0x4EC6562: g_malloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4EE28D9: g_strsplit (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4011297: bhyveParsePassthru (bhyve_parse_command.c:699)
by 0x4010082: bhyveParseBhyvePCIArg (bhyve_parse_command.c:800)
by 0x400EE14: bhyveParseBhyveCommandLine (bhyve_parse_command.c:862)
by 0x400DF9C: bhyveParseCommandLineString (bhyve_parse_command.c:1058)
by 0x4008CA0: testCompareXMLToArgvFiles (bhyveargv2xmltest.c:39)
by 0x4008B29: testCompareXMLToArgvHelper (bhyveargv2xmltest.c:105)
by 0x4009288: virTestRun (testutils.c:143)
by 0x40085AC: mymain (bhyveargv2xmltest.c:164)
by 0x400B582: virTestMain (testutils.c:913)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Consider bitmaps for incoming migration regardless of non-shared storage
flag.
When bitmaps are offered from the source, consult the local image if the
bitmap is present and if not accept migration. Migration of bitmaps
which exist in the qcow2 metadata is skipped because qemu rejects such
setup (although handles it correctly in case of shared storage setup;
see below).
This allows bitmap propagation for cases when the qcow2 image is not
actually shared between destinations but the data is (using the
data_file feature).
At the same time this preserves existing bitmap handling semantics for
other cases. Specifically qemu, in case of shared storage properly
propagates the bitmap which was already recorded in the qcow2 metadata
on disk even if libvirt doesn't instruct migration, yet tolerates
migration instruction if the file is not yet recorded in the on-disk
metadata. In both cases the contents are preserved correctly.
When storage is not shared (which includes even cases when we migrate
it via NBD) it's expected that the bitmaps don't exist on the
destination and thus all will be picked for migration. We can also
infer that this wasn't ever a problem by the fact that the code skipping
migration of existing bitmaps was broken until recently, and qemu
would refuse such config.
I've tested all the above scenarios including verifying that the
resulting bitmaps capture dirtied regions before and after migration.
For testing this the following command is useful:
Peter Krempa [Tue, 27 Jan 2026 16:00:10 +0000 (17:00 +0100)]
qemu: migration: Always offer block dirty bitmaps during migration
Until now block dirty bitmaps were offered to destination only if
non-shared storage migration was enabled.
Upcoming patches will want to support it also in cases when storage is
shared but the destination has a qcow2 overlay using the 'data_file'
feature where the qcow2 overlay is not actually shared.
To support that we'll now always offer bitmaps for migration. The
destination can then decide (using existing logic) to pick only the
ones that are not present in the image on destination, which is how
it was supposed to work even now.
The patch removes all the flag checks and simply offers bitmaps in any
case. The overhead incurred by this is one 'query-named-block-nodes'
call to qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 27 Jan 2026 18:22:08 +0000 (19:22 +0100)]
qemuMigrationDstPrepareAnyBlockDirtyBitmaps: Fix check for existing bitmaps
On incoming migration qemu doesn't load bitmaps into memory (which makes
them available under the 'dirty-bitmaps' field which we parse as the
'bitmaps' array in 'qemuBlockNamedNodeData') until after actually
resuming CPUs, thus the check for existing bitmaps never actually
worked.
We need to check the 'qcow2bitmaps' field instead which is populated
from the qcow2 headers prior to activating the image.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 27 Jan 2026 19:07:32 +0000 (20:07 +0100)]
qemu: monitor: Detect list of bitmaps from 'qcow2' format specific data
We currently probe dirty block tracking bitmaps by looking at the loaded
ones ('dirty-bitmaps'). Unfortunately those may not yet be populated on
incoming migration when the image was not yet activated, but we need to
know which ones are stored in the image so that we don't migrate those
explicitly, which would fail.
Load the list of bitmaps in a qcow2 image from the format specific data,
which is already loaded at that point.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 27 Jan 2026 21:49:09 +0000 (22:49 +0100)]
qemublocktest: Iterate all nodenames in 'testQemuDetectBitmaps'
Rather than looking for 30 specific nodenames (via a loop) iterate
everything in the hash table (in a sorted order). This simplifies the
code and provides more test outputs on previously-ignored nodenames.
The listing of internal snapshots in the output was also missing a
newline, which would now cause problems with multiple images reproted.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
In previous commit of v12.0.0-85-g2c66b6d72c we've tried to solve
a problem where xdrproc_t is a prototype of a function which
takes only two arguments instead of three. See original commit
for more info. The fix consists of a config time check and
setting XDRPROC_T_3ARGS accordingly (in meson-config.h). This
works for nearly all of our code, except rpcgen which is
intentionally independent of the rest of the code. Therefore, the
macro has to be set extra - by specifying it on the compiler cmd
line.
Fixes: 2c66b6d72cd48d3cf80f957f55cfb1548feb46c4 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Passing 3 arguments was a good common ground, but since
recently[1] FreeBSD only accepts 2 arguments.
Add a meson.build check whether 3 arguments are accepted,
and add macros which passes either 2 or 3 arguments to
xdrproc_t based on the result of this check.
Nathan Chen [Fri, 30 Jan 2026 18:59:17 +0000 (10:59 -0800)]
qemu: Update Cgroup, namespace, and seclabel for iommufd
When launching a qemu VM with the iommufd feature enabled for VFIO
hostdevs:
- Do not allow cgroup, namespace, and seclabel access to VFIO
paths (/dev/vfio/vfio and /dev/vfio/<iommugroup>)
- Allow access to iommufd paths (/dev/iommu and
/dev/vfio/devices/vfio*) for AppArmor, SELinux, and DAC
Signed-off-by: Nathan Chen <nathanc@nvidia.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Nathan Chen [Fri, 30 Jan 2026 18:59:16 +0000 (10:59 -0800)]
qemu: open iommufd FD from libvirt backend
Open iommufd FD from libvirt backend without exposing
these FDs to XML users, i.e. one per domain for
/dev/iommu, and pass the FD to qemu command line. Set
per-process memory accounting for iommufd instead of
the default per-user memory accounting.
Suggested-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Nathan Chen <nathanc@nvidia.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Nathan Chen [Fri, 30 Jan 2026 18:59:15 +0000 (10:59 -0800)]
qemu: open VFIO FDs from libvirt backend
Open VFIO FDs from libvirt backend without exposing
these FDs to XML users, i.e. one per iommufd hostdev
for /dev/vfio/devices/vfioX, and pass the FD to qemu
command line.
Suggested-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Nathan Chen <nathanc@nvidia.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Nathan Chen [Fri, 30 Jan 2026 18:59:14 +0000 (10:59 -0800)]
qemu: Support per-process memory accounting for iommufd
Implement the IOMMU_OPTION_RLIMIT_MODE
ioctl to set per-process memory accounting for
iommufd. This prevents ENOMEM errors from the
default per-user memory accounting when multiple
VMs under the libvirt-qemu user have their pinned
memory summed and checked against a per-process
RLIMIT_MEMLOCK limit.
Signed-off-by: Nathan Chen <nathanc@nvidia.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Pavel Borecki [Mon, 2 Feb 2026 08:04:48 +0000 (08:04 +0000)]
tools: Fix chown syntax in virt-pki-validate.c (dot -> semicolon as owner and group separator)
Closes: https://gitlab.com/libvirt/libvirt/-/issues/847 Signed-off-by: Pavel Borecki <pavel.borecki@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The "virt" board in QEMU has a "virtualization" option
that is documented like this:
virtualization
Set ``on``/``off`` to enable/disable emulating a guest CPU which implements the
Arm Virtualization Extensions. The default is ``off``.
(from system/arm/virt.rst)
According to the documentation, the "virtualiaztion" option
is related to the "gic-version" option. Specifically, gic version=4
requires virtualization to be enabled. And gic version=max will use
version=4 when virtualization is enabled, and 3 when not.
Libvirt does not currently model neither gic version "4" nor "max"
though.
It is also documented for the "vexpress-a(9|15)" boards, where it is
also disabled by default:
- QEMU defaults to providing a CPU which does not provide either
TrustZone or the Virtualization Extensions: if you want these you
must enable them with ``-machine secure=on`` and ``-machine
virtualization=on``
Michal Privoznik [Fri, 30 Jan 2026 09:39:37 +0000 (10:39 +0100)]
networkxmlconftest: Expect success for "hostdev" case only on Linux
Our network has multiple means of forwarding the traffic and
'hostdev' is one of them. This mode means that the network is
configured to use a set of PCI devices which are then assigned to
individual domains to use (PCI device assignment). Now, as of v12.0.0-61-gecb2e06bdf our test runners
(testCompareXMLToXMLFiles() and testCompareXMLToConfFiles()) call
networkValidateTests(). For aforementioned type of network this
means checking that the specified set of devices contains only
VFs (see v3.2.0-rc1~24 for more info). It is true that our
virpcimock is preloaded which mimics VFs, but our utils module
(virpci.c specifically) talks to sysfs to check various PCI
device attributes, including whether it's a VF.
This obviously works on Linux and doesn't work anywhere else.
Therefore, until our utils module is taught how to check PCI
attribs on other systems, make the "hostdev" test case expect
validation failure on non-Linux systems.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Michal Privoznik [Wed, 28 Jan 2026 12:10:26 +0000 (13:10 +0100)]
tests: Rename networkxml2xmltest to networkxmlconftest
Now that networkxml2xmltest does both XML -> XML and XML -> conf
tests its name became misleading. Rename it to networkxmlconftest
and move its data into networkxmlconfdata/ dir.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 27 Jan 2026 15:43:06 +0000 (16:43 +0100)]
networkxml2xmltest: Sync test cases with networkxml2conftest
The networkxml2xmltest does basic parse -> format tests.
The networkxml2conftest does parse -> conf tests.
Now, majority of XMLs are the same. That is, output XMLs of
networkxml2xmltest and input XMls of networkxml2conftest. There
are only a few differences. This is actually great, because it
will allow either tests to do both test cases.
There are some (subtle) differences in individual test cases
though:
1) some test cases exist only in networkxml2conftest and not
networkxml2xmltest, or
2) some test cases in networkxml2conftest have more values, i.e.
extra elements, extra attributes. or
3) some test cases in networkxml2conftest have less values.
For cases from 1) they were just copied over. For cases from 2)
those extra elements/attributes were added, and for cases from 3)
those extra attributes were removed (to minimize changes to .conf
files in near future).
One caveat though: networkxml2xmlupdatetest uses input XMLs of
networkxml2xmltest too (hence changes under
networkxml2xmlupdateout/ dir). This means that the
"delete-srv-record-protocol" test started failing, because the
input network XML now has more <srv/> records than the test case
anticipated. But this is easy to fix - hence seemingly unrelated
change under networkxml2xmlupdatein/ dir.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 17 Dec 2025 10:31:52 +0000 (11:31 +0100)]
networkxml2xmltest: Store parsed def for future tests
Soon, the testRun() will run more than one test case. The input
network XML, however, stays the same. Instead of parsing it and
throwing away immediately, store it temporarily.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
So far, the testInfo struct contained immutable data (from its
lifetime point of view). But that is about to change. For
instance, it will hold parsed network definition (virNetworkDef)
and in order to avoid leaking dynamically allocated data
corresponding free function must be introduced (or clear
function, doesn't really matter). At this point, the structure
might as well be dynamically allocated entirely.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 17 Dec 2025 08:51:17 +0000 (09:51 +0100)]
networkxml2xmltest: Move path generation into testRun()
This effectively dissolves testCompareXMLToXMLHelper() into
testRun(). Motivation is that parts of data generated inside of
testCompareXMLToXMLHelper() is going to be reused from the caller
(testRun()).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 17 Dec 2025 08:46:59 +0000 (09:46 +0100)]
networkxml2xmltest: Introduce testRun()
This is a beginning of something bigger. The idea is that one
DO_TEST_FULL() macro (and its friends) will run multiple test
cases (just like qemuxmlconftest does). But in order to do that
in a readable fashion, the macro should merely just expand to a
function call. The function will then call virTestRunLog(),
multiple times possibly.
This is the first step in that direction.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 17 Dec 2025 09:44:21 +0000 (10:44 +0100)]
networkxml2xmltest: Don't recreate xmlopt object
The aim of virNetworkXMLOption object is to provide some
immutable data to XML parser (e.g. various callbacks). Since the
object is immutable, it can be created once and then reused by
all test cases.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 17 Dec 2025 12:24:06 +0000 (13:24 +0100)]
networkxml2conftest: Allow regenerating more in one run
Currently, there are two calls to virTestCompareToFile() inside
of testCompareXMLToConfFiles(). If the first one fails the
control jumps directly onto the fail label and skips the second
one. This means that When regenerating test case output
(VIR_TEST_REGENERATE_OUTPUT) the test binary has to be called
twice to regenerate all the files. Suboptimal. Try harder to call
both compare helpers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Inside of testCompareXMLToConfFiles() the
networkDnsmasqConfContents() is called. This may also produce
contents of corresponding hosts file. This is then compared to
expected contents stored on disk as ${testname}.hostsfile. But
due to additional checks virTestCompareToFile() might not even be
called. Problem with that is when there's actual content but the
file doesn't exist the compare helper is not called and thus
VIR_TEST_REGENERATE_OUTPUT trick doesn't work. Let's call the
helper more often as it is perfectly capable of handling this
edge case. What it is not capable of handling is when the file
shouldn't exist at all. So handling of that case is kept.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 17 Dec 2025 12:17:02 +0000 (13:17 +0100)]
networkxml2conftest: Avoid potential leak
Inside of testCompareXMLToConfFiles() the network definition is
parsed and if that succeeds a virNetworkObj is created by calling
virNetworkObjNew(). But if the latter fails, the control jumps
onto the fail label where only the object is freed but not
already parsed definition leading to a leak.
Swapping these two steps ensures that if either of them fails no
memleak occurs.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 27 Jan 2026 21:08:18 +0000 (22:08 +0100)]
test: wire up networkValidateTests()
Our network driver calls networkValidate() right after a network
XML is parsed. This is similar to domain validation step when
parsing domain XML. But it's not that convoluted in network
driver. Regardless, any network related test should mimic real
life scenario as close as possible and thus
networkValidateTests() should be called right after domain XML is
parsed.
Now, networkValidate() might query sysfs wrt to PCI devices and
thus tests must start using virpcimock. The function will also
generate random MAC addresses, if needed, hence virrandommock.
With this change, passthrough-pf and passthrough-address-crash
test cases of networkxml2xmltest started failing but looking at
corresponding XMLs those test cases were designed to test just
XML parsing. They were never designed to showcase a "real"
network XML. So mark them as expected fail.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 28 Jan 2026 08:27:51 +0000 (09:27 +0100)]
networkxml2xmltest: Update couple of test cases
Soon, individual test cases of networkxml2xmltest will be subject
to networkValidate() call. This means, that input XMLs must be
valid (or marked as expected fail). Anyway, there are couple of
offenders:
1) 8021Qbh-net.xml setting vlan for <forward mode='private'/> is
unsupported,
2) hostdev.xml networkValidate() will check if hostdevs specified
for <forward mode='hostdev'/> are VFs. Use PCI addresses from
virpcimock.
3) openvswitch-net.xml for <forward mode='bridge'/> only
openvswitch type of virtualports is allowed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 27 Jan 2026 20:25:41 +0000 (21:25 +0100)]
networkxml2conftest: Fail tests where no dnsmasq would be spawned
If network config does not require dnsmasq then none is spawned.
Having a test case that would still require generating dnsmasq
config is weird and can lead to spurious results. Just fail such
test case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 27 Jan 2026 20:24:07 +0000 (21:24 +0100)]
networkxml2conftest: Drop routed-network-no-dns test case
This test case is spurious. If this was real life scenario then
no dnsmasq would be spawned and yet, the test tries to generate
dnsmasq config for it. Just drop the test case and move on.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 27 Jan 2026 19:59:20 +0000 (20:59 +0100)]
network: Move decision on dnsmasq need into a separate function
Whether a network needs dnsmasq or not is decided at the
beginning of networkStartDhcpDaemon(). Move that code into a
separate function so it can be reused later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 27 Jan 2026 19:38:21 +0000 (20:38 +0100)]
network: Separate private APIs declaration to bridge_driver_priv.h
There are two functions implemented in bridge_driver.c that are
used in tests (networkDnsmasqCreateXMLConf() and
networkDnsmasqConfContents()) but are declared in
bridge_driver.h. This goes against our current practice where
such APIs are declared in $name_priv.h.
Therefore, move those APIs to bridge_driver_priv.h
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fixes: https://issues.redhat.com/browse/RHEL-138300
Updates: commit 845210011a9ffd9d17e30c51cbc81ba67c5d3166 Reported-by: Ming Xie <mxie@redhat.com> Signed-off-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Mon, 26 Jan 2026 15:49:50 +0000 (16:49 +0100)]
qemuSnapshotUpdateBackingStore: Retry as curent user if qemu-img fails
The code calls 'qemu-img rebase' to fix the backing store references.
The 'qemu-img' process here is run as the 'qemu' user or whatever the
defaults and domain XML resolve to. Since this, in certain cases, works
also on images which are not part of the backing chain and in privileged
deployments thus can be owned by 'root:root' the update may fail
(silently).
To preserver root-squash deployments but fix also the above case, retry
the operation on failure as current user.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Mon, 26 Jan 2026 15:39:24 +0000 (16:39 +0100)]
qemuSnapshotDiskHasBackingDisk: Use proper 'max_depth' when calling 'virStorageSourceGetMetadata'
The 'max_depth' argument of 'virStorageSourceGetMetadata' doesn't just
limit how far the function goes but also fails completely if the chain
is deeper than the passed value.
In 'qemuSnapshotDiskHasBackingDisk' we only care about finding the
backing image, so just one level below, the passed path, but due to the
above setting '1' as max_depth will make the function simply fail every
time.
Extract and reuse QEMU_DOMAIN_STORAGE_SOURCE_CHAIN_MAX_DEPTH as the
detection depth. While '200' layers is overkill for this code, we also
start a full qemu instance just to delete an snapshot so this doens't
matter and still protects from self-referential images.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Fri, 23 Jan 2026 07:54:32 +0000 (08:54 +0100)]
qemuSnapshotUpdateBackingStore: Remove stale comment
The code does a 'qemu-img rebase' rather than a 'qemu-img create' what
the commit suggests. Since we enumerate all arguments right below,
there's no need for a comment.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Fri, 23 Jan 2026 07:42:50 +0000 (08:42 +0100)]
qemuSnapshotDiskHasBackingDisk: Avoid call of virStorageSourceIsSameLocation with NULL argument
When the 'backingStore' pointer is not populated the function calls
'virStorageSourceGetMetadata' to try to populate it but if the on-disk
metadata doesn't have a backing image (e.g. if it's the 'base' image of
the chain) the 'backingStore' or the metadata fetcher fails the pointer
will still be NULL.
The function then calls 'virStorageSourceIsSameLocation' but the
internal functions for dealing with storage sources don't handle NULL
gracefully.
Since the code calling 'qemu-img' based on the data detected here
doesn't actually raise errors if the operations fail there's no point
in raising errors here either.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/844 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Michal Privoznik [Thu, 22 Jan 2026 14:43:17 +0000 (15:43 +0100)]
Fix printf style used with virDomainIOMMUDef::aw_bits
The aw_bits member of the virDomainIOMMUDef is of type unsigned
int. However, in a few places
(virDomainIOMMUDefCheckABIStability(), virDomainIOMMUDefFormat(),
qemuBuildIOMMUCommandLine()) incorrect printf modifier is used.
Fix those places.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Tue, 20 Jan 2026 15:19:00 +0000 (16:19 +0100)]
src: Use device alias when ifname is unset in virDomainInterfaceAddresses()
The virDomainInterfaceAddresses() API returns an array of
_virDomainInterface structs which then describe IP addresses
associated with given domain. The struct contains 'name' member
which is documented deliberately vaguely: "interface name". This
is because depending on the source of truth used (controlled by
'source' argument) the name can be wildly different from the one
in domain XML. Now, in case of source =
VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_ARP, the host's ARP table is
parsed and matching interfaces are found by comparing MAC
addresses. If it's a match then the 'name' is set to net->ifname
(corresponds to /interface/target/@dev). But that is not always
set and sometimes may be NULL (e.g. for hostdevs, usernet). We
can't change the API (like we did for hwaddr in v1.2.14-rc1~105)
because this is already released. So the next best thing to do is
to put the interface alias in there.
To be on a safe side, do the same change to the
VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_LEASE case.
Resolves: https://issues.redhat.com/browse/RHEL-141496 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 20 Jan 2026 15:15:14 +0000 (16:15 +0100)]
libvirt-domain: Fix documentation of virDomainInterfaceAddresses()
Ever since of v1.2.14-rc1~105 the hwaddr member of
_virDomainInterface struct can be NULL. And this is documented
inside the struct. But then the public API documents it can never
be NULL which is obviously wrong. Fix the public API
documentation.
Fixes: 3640245db7d72bf8e05df726587625a6328c895e Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 16 Jan 2026 15:39:49 +0000 (16:39 +0100)]
qemuDomainSetThrottleGroup: Don't put group name into the 'tunable' event twice
'qemuDomainSetBlockIoTuneFields' already populates the contents of the
VIR_DOMAIN_EVENT_ID_TUNABLE params with the group name so there's no
need to do it explicitly. We'd report the group name twice:
Peter Krempa [Fri, 16 Jan 2026 15:39:40 +0000 (16:39 +0100)]
qemuDomainSetThrottleGroup: Always honour thottle group name passed as argument
Due to the code share with 'qemuDomainSetBlockIoTune' the throttle group
setting code accepts the throttle group name also via typed parameters.
In 'qemuDomainSetThrottleGroup', this means that there are 2 ways to
pass it the throttle group name and both are handled slightly
differently. Specifically the name of the group used in the list of
groups is the name taken from the typed parameters rather than the one
passed via API. We also don't validate that they match.
Now if the name in the typed parameters is missing we'd add empty string
to the group list which would later crash when looking up the group
name.
To avoid this problem always use the name passed via argument. This is
achieved by passing it into 'qemuDomainSetBlockIoTuneFields' so that it
overrides whatever is in the typed parameters.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Notable changes:
- machine type changes: new types added, '5.0' machines dropped
- new and updated cpus:
- ClearwaterForest-v2-x86_64-cpu
- DiamondRapids-v1-x86_64-cpu
- GraniteRapids-v4-x86_64-cpu
- SapphireRapids-v5-x86_64-cpu
- SierraForest-v4-x86_64-cpu
- various CPU flag changes for 'max-x86_64-cpu'
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 14 Jan 2026 08:28:32 +0000 (09:28 +0100)]
qemuxmlconftest: Prepare 'fd-memory-numa-topology4' for removal of 'pc-i440fx-5.0'
Per commit message of 3f390db2e2ed33cda8e which added the
'fd-memory-numa-topology4' case, it's supposed to test memory
preallocation setting in the NUMA setup.
Now the 5.0 machine type is the last one supporting the old-style NUMA
config and thus also the only way to test the formatting of
'--mem-prealloc' commandline option for qemu, which was since replaced
by a property in the memory backend object.
Thus to preserve the idea of this test, add
'fd-memory-numa-topology4-old-machine' test case pinned to qemu-10.2,
which will use pc-i440fx-5.0 and modernize the normal case using the
latest qemu version by dropping the specific machine version.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Tue, 20 Jan 2026 09:54:21 +0000 (10:54 +0100)]
virnetdevtap: Produce more helpful error message in virNetDevTapCreate()
Since v10.8.0-rc1~133 a different error is reported from
virNetDevTapCreate() when the tap device already exists (and
<interface/> XML specifies managed='no'). But the change covers
only one scenario: if multiqueue was requested in <inteface/> XML
BUT pre-created tap device doesn't have multi_queue flag set. The
opposite scenario: if the device has the multi_queue flag set BUT
no multiqueue was specified in the XML. Until now.
Resolves: https://issues.redhat.com/browse/RHEL-118303 Fixes: f6fb097e11a15e390d989411b2660ead0d1a7c10 Fixes: 465a38154f0cfc31d62c4105770e1f4a9599a611 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 20 Jan 2026 09:08:29 +0000 (10:08 +0100)]
esx: Allow connecting to IPv6 server
When connecting to a VMWare server, the hostname from URI is
resolved using esxUtil_ResolveHostname() which in turn calls
getaddrinfo(). But in the hints argument, we restrict the return
address to be IPv4 (AF_INET) which obviously fails if the address
to resolve is an IPv6 address. Set the hint to AF_UNSPEC which
allows both IPv4 and IPv6. While at it, also allow IPv4 addresses
mapped in IPv6 by setting AI_V4MAPPED flag.
Resolves: https://issues.redhat.com/browse/RHEL-138300 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
bhyve: workaround for the lack of UTC clock on ARM64
Currently, bhyve does not support UTC clock offset on ARM64.
However, when <clock offset= > is not specified in the domain XML,
UTC offset is used by default. That results in an incorrect
configuration for the bhyve ARM64 guests by default.
Workaround is to extend bhyveDomainDefPostParse() to fall back
to the LOCALTIME clock offset when UTC clock offset is not
supported by bhyve.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Serge Hallyn [Mon, 5 Jan 2026 20:27:21 +0000 (14:27 -0600)]
virt-aa-helper: Ask for no deny rule for readonly disk elements
Just because a disk element only requests read access doesn't mean
there may not be another readwrite request.
Using 'R' when creating the apparmor rule will prevent an implicit
write-deny rule to be created alongside. This does not mean write
is allowed but it would cause a denial message and probably more
relevant, allows to add write access later.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/622
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/806
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1554031
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1692441 Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In shell, the following function doesn't echo '1' but '0':
func() {
local var=$(false)
echo $?
}
This is because '$?' does not refer to 'false' but 'local'. The
bash_builtins(1) manpage explains it well. And it also mentions
other commands behaving the same: export, declare and readonly.
Since it is really easy to miss this pattern, introduce a
syntax-check rule. Mind you, the following pattern (which passes
the rule) does check for the subshell exit code:
func() {
local var
var=$(false)
echo $?
}
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Mon, 19 Jan 2026 10:42:14 +0000 (11:42 +0100)]
libvirt-guest.sh.in: Fix logical error in guest_is_on()
The guest_is_on() function is documented to check whether given
domain is running and set guest_running variable accordingly. It
does so by running virsh (transitively), then setting the
variable and only after that comparing $? variable. This is
obviously wrong, because after the guest_running variable
assignment the $? variable no longer holds the exit code of
virsh. Even worse, as explained in the previous commit, it never
held that value in the first place. Fix this by firstly setting
the global variable and only after that running virsh.
Fixes: 08071ec0f113bb1fe8dcc263cb6bf87529e8b76b
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/839 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Mon, 19 Jan 2026 10:28:47 +0000 (11:28 +0100)]
libvirt-guests.sh: Declare and assign separately to avoid masking return values
In Bash, the following code does not do what you think it does:
func() {
local var=$(false)
echo $?
}
Here, '0' is echoed even though false is designed to exit with a
non-zero code. This is because in fact the last executed command
is 'local' not 'false' and thus '$?' contains zero as in "yeah,
the variable is successfully declared" [1]. In our libvirt-guest
shell script, there are a few places like this. Fix them.
1: bash_builtins(1) Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
meson: write all warning flags to 'c-warnings.txt'
Passing warning flags to the C compiler results in incredibly long
command lines, which in turns results in incredibly large CI log
files. Our logs are so large that they often exceed the GitLab
file limits.
We've cut out the irrelevant cruft from the logs and they're still
too large. The only option left is to stop passing so many args
to the compiler.
Fortunately it is easy to achieve this with GCC/CLang as when seeing
an argument "@somepath" they will treat each line in "somepath" as
being an additional compiler argument.
Putting the warning flags in a 'c-warnings.txt' file is fairly
easy and a massive win. We don't lose anything from the CI logs
as we print the full set of warning flags at the end of running
'meson'. Meanwhile for interactive builds the flags are visible
in the c-warnings.txt file in the build directory root.
Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This patch changes how the maximum socket count is calculated.
On some systems (e.g. GB200), physical_package_id values are not
contiguous or zero-based. Instead of 0..N, they may contain large
arbitrary identifiers (e.g. 256123234). The previous implementation
assumed a 0..N range and used the maximum ID value directly.
This caused:
excessive memory allocation
extremely large loop bounds
OOM / DoS scenarios
unnecessary CPU time consumption
The new implementation computes the socket count as the number of unique
package IDs present on the node, rather than relying on the maximum numeric
value.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Alexandr Semenikhin <alexandr2e78@gmail.com>
Laine Stump [Thu, 15 Jan 2026 00:28:17 +0000 (19:28 -0500)]
conf: simplify check for vlan tagging support in virDomainActualNetDefValidate()
Since the only two types of bridges we support are OVS bridges and
Linux host bridges, and since both of those now support vlan tagging,
we don't need to check the virtualport type etc - if there is a bridge
specified then we know the interface will support vlan tagging.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
projects / thirdparty / libvirt.git / log
