util: remove duplicate logging of firewall command
The vircommand.c code will always log the argv about to
be run, so logging it again in virfirewall.c is redundant.
Removing the dupe avoids the repeated memory allocation
from the array -> string conversion.
The minor difference is the downgrade from INFO to DEBUG
level, but the use of INFO level was out of character for
libvirt to begin with.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Arun Menon [Tue, 10 Feb 2026 17:56:42 +0000 (23:26 +0530)]
secret: Add functionality to load and save secrets in encrypted format
Now that we have the functionality to provide the secrets driver
with an encryption key through a configuration file or using system
credentials, and the newly introduced array to iterate over the
encryption schemes, we can use the key to save and load secrets.
Encrypt all secrets that are going to be saved on the disk if the
'secrets_encryption_key' path is set in the secret.conf file OR
if a valid systemd generated credential exists.
While loading secrets, identify the decryption method by matching the file
extension of the stored secret against the known array values.
If no matching scheme is found, the secret is skipped. If the encryption
key is changed across restarts, then also the secret driver will fail to load
the secrets from the disk that were encrypted with the former key.
Signed-off-by: Arun Menon <armenon@redhat.com> Co-authored-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Arun Menon [Tue, 10 Feb 2026 17:56:41 +0000 (23:26 +0530)]
secret: Rename virSecretObj structure attribute from base64File to secretValueFile
Change the attribute name of _virSecretObj because we want it to have a generic
name to indicate that secret values can be stored in it in both base64 and
encrypted formats.
Signed-off-by: Arun Menon <armenon@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Arun Menon [Tue, 10 Feb 2026 17:56:40 +0000 (23:26 +0530)]
secret: Add secret.conf configuration file and parse it
A new configuration file called secret.conf is introduced to
let the user configure the path to the secrets encryption key.
This key will be used to encrypt/decrypt the secrets in libvirt.
By default the path is set to the runtime directory
/run/libvirt/secrets, and it is commented in the config file.
After parsing the file, the virtsecretd driver checks if an
encryption key is present in the path and is valid.
If no encryption key is present in the path, then
the service will by default use the encryption key stored in the
CREDENTIALS_DIRECTORY.
Add logic to parse the encryption key file and store the key.
It also checks for the encrypt_data attribute in the config file.
The encryption and decryption logic will be added in the subsequent patches.
Signed-off-by: Arun Menon <armenon@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Arun Menon [Tue, 10 Feb 2026 17:56:39 +0000 (23:26 +0530)]
secret: Set up default encryption secret key for the virtsecretd service
This commit sets the foundation for encrypting the libvirt secrets by providing a
secure way to pass a secret encryption key to the virtsecretd service.
A random secret key is generated using the new virt-secret-init-encryption
service. This key can be consumed by the virtsecretd service.
By using the "Before=" directive in the new virt-secret-init-encryption
service and using "Requires=" directive in the virtsecretd service,
we make sure that the daemon is run only after we have an encrypted
secret key file generated and placed in /var/lib/libvirt/secrets.
The virtsecretd service can then read the key from CREDENTIALS_DIRECTORY. [1]
This setup therefore provides a default key out-of-the-box for initial use.
A subsequent commit will introduce the logic for virtsecretd
to access and use this key via the $CREDENTIALS_DIRECTORY environment variable. [2]
Arun Menon [Tue, 10 Feb 2026 17:56:38 +0000 (23:26 +0530)]
util: Add support for GnuTLS decryption
Adds `virCryptoDecryptDataAESgnutls` and `virCryptoDecryptData`
as wrapper functions for GnuTLS decryption.
These functions are the inverse of the existing GnuTLS encryption wrappers.
This commit also includes a corresponding test case to validate data decryption.
Signed-off-by: Arun Menon <armenon@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Thu, 5 Feb 2026 14:10:36 +0000 (15:10 +0100)]
qemuProcessRefreshDisks: Don't bother to refresh disks on cold boot
The only thing that 'qemuProcessRefreshDisks' currently does is to
update tray state for disks. This makes no sense on cold boot since only
cdroms have tray and the tray is closed.
Avoid the extra call to 'query-block' on cold boot and just assume CDROM
has a closed tray.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 5 Feb 2026 13:31:41 +0000 (14:31 +0100)]
qemu: Refactor tray_status handling
Modify the monitor code to directly return values from 'virDomainDiskTray'
enum instead of two bools.
This allows simplification of the other code:
- qemuProcessRefreshDiskProps just assigns the value, thus can be deleted
- old_tray_status is no longer needed as we can directly access the
disk status instead and assign later
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 5 Feb 2026 13:18:46 +0000 (14:18 +0100)]
qemuDomainAttachDiskGeneric: Avoid unneeded disk property refresh after hotplug
The only thing the call to 'qemuProcessRefreshDiskProps' would update
from data gathered from a 'query-block' QMP call would be the state of
the tray of the device. We know that only CDROM devices have a tray and
after hotplug it's closed.
Remove the unneeded code and adjust tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 3 Feb 2026 14:14:14 +0000 (15:14 +0100)]
conf: domain: Add VIR_DOMAIN_DISK_TRAY_NONE state for devices without tray
Currently the default state was VIR_DOMAIN_DISK_TRAY_CLOSED. Not all
disks have a tray so add another state as the default and adjust code
which was based on the assumption that the tray is always present.
This change also removes the need for the 'tray' field in the disk
private data which was used inconsistently.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 4 Feb 2026 10:35:57 +0000 (11:35 +0100)]
qemu: monitor: Add test validating that 'eventHandlers' are properly sorted
The monitor code uses 'bsearch' to look up the event handler so the
event names must be properly listed. Until now only a comment reminded
us to do it. Add a test to verify that it is actually sorted properly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 3 Feb 2026 17:01:15 +0000 (18:01 +0100)]
qemu: Drop 'removable' field from 'qemuDomainDiskInfo'
The only real use was in 'qemuProcessRefreshDiskProps' where it guarded
assignment of 'tray' status. Since qemu doesn't actually report any tray
status for devices which don't have a tray there's no need for the extra
guard.
Remove the field completely.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 3 Feb 2026 16:46:10 +0000 (17:46 +0100)]
qemuMigrationSrcBegin: Drop disk refresh step
Since 'qemuProcessRefreshDiskProps' doesn't remove the source since we
switched to blockdev mode, we don't need to update disk state at the
beginning of migration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 3 Feb 2026 16:41:21 +0000 (17:41 +0100)]
qemuProcessRefreshDiskProps: Drop code to remove disk source
In blockdev mode, the guest OS can't force the drive to become empty
(opening cdrom tray doesn't remove media; floppies can't be ejected from
guest OS), so the check if a drive is empty is dead code at this point.
Remove it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 11 Dec 2025 18:47:16 +0000 (19:47 +0100)]
qemu: Implement support for persistent reservation migration control
The 'migration' attribute for the '<reservations>' element allows to
control the persistent reservation migration feature independently of
the machine type default.
Add the XML plumbing and qemu support.
We consider it ABI for now since it influences qemu migration protocol.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
network: add comment to table that it belongs to libvirt
The result looks like
$ nft list ruleset
...snip...
table ip6 libvirt_network {
comment "Managed by libvirt for virtual networks: https://libvirt.org/firewall.html#the-virtual-network-driver"
chain forward {
...snip...
This should reduce the number of people wondering why
these rules exists.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virDomainInterfaceAddresses() API accepts @source argument,
but since this is hyperv, we can't really use _SRC_LEASE (we
didn't spawn any dnsmasq there), not _SRC_ARP. The only source
that's more or less usable is _SRC_AGENT. Okay, there's no QEMU
guest agent running, but hyperv has its own guest agent. In my
testing (with Linux guest) I had to install 'hyperv' package and
then enable 'hv_kvp_daemon.service'. After that,
Msvm_GuestNetworkAdapterConfiguration struct [1] contained guest
IP addresses.
There's one caveat though: the interface name
(virDomainInterface::name). We don't fetch that one even for
hypervDomainGetXMLDesc() case. And there's no <target dev=''/>
either nor device alias (v12.0.0-43-g4009126f17). So just put
InstanceID there for now, which is this long path, with some
UUIDs, e.g.:
When constructing a domain definition, NICs are fetched from WMI
and their MAC addresses are then parsed. Move this code into a
separate function so that it can be reused later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The aim of this helper is to convert subnet mask to prefix. For
instance for input "255.0.0.0" to return 8. Additionally, if the
input string is already a prefix (with optional leading slash
character) just return that number parsed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
datatypes: Declare autofree func for virDomainInterface type
The virDomainInterface type (struct _virDomainInterface) is
defined in our public header and even has a public free function
(virDomainInterfaceFree()). But in our code we will want to use
automatic memory freeing for it. Hence, make appropriate
declaration in datatypes.h.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Dion Bosschieter [Tue, 10 Feb 2026 10:16:26 +0000 (11:16 +0100)]
nwfilter: move shared nwfilter driver functions into nwfilter_tech_driver.c
Introduce nwfilter_tech_driver.c which holds shared non driver specific
methods.
The following logic can be reused by new nwfilter drivers, which are not
ebiptables specific:
- data type print logic, used for constructing ascii cli arguments out
of nwfilter data;
- chain jump proto type l3_proto_idx logic;
- virNWFilterRule sorting.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
[DB: moved virstring.h include to source file & added to POTFILES] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Dion Bosschieter [Thu, 12 Feb 2026 12:17:49 +0000 (12:17 +0000)]
nwfilter: remove redundant sys/utsname.h include
There are no calls to uname() in the ebiptables driver code.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
[DB: split from larger patch] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Dion Bosschieter [Tue, 10 Feb 2026 10:16:25 +0000 (11:16 +0100)]
nwfilter: rename generic names to virNWFilter* and CamelCase
Rename generic nwfilter data types and functions to virNWFilter prefix
and convert them to CamelCase. These data types and functions are quite
common to any nwfilter driver implementation. Prior to moving them out
of the nwfilter_ebiptables_driver.c file, we'll first rename them.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
Adds documentation for the new USB bus/port addressing.
The new "port" attribute is explained.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/513
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
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>
projects / thirdparty / libvirt.git / log
