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>
Laine Stump [Thu, 15 Jan 2026 00:19:38 +0000 (19:19 -0500)]
conf: validate that specified interface type supports vlan tags
Somehow this was never done in virDomainNetDefValidate() (which is run
immediately post-parse) - it was only in
virDomainActualNetDefValidate() (which isn't done until the interface
is actually attached to the domain). While it is true that we *might*
not know if vlan tagging is supported for the interface if the
interface type == 'network', we otherwise will always know right away,
so we may as well check sooner than later.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Wed, 14 Jan 2026 02:00:39 +0000 (21:00 -0500)]
qemu: use actual/effective vlan when updating OVS-based interface vlan tag
Using &newdev->vlan when updating the vlan tag causes problems if the
interface is using a libvirt virtual network to get its vlan tag
info - in this case the info won't be properly pulled from the virtual network
config, but instead it will just use the (empty)
vlan object from the netdef.
The proper thing to do is to use virDomainNetGetActualVlan(), which
will pull the vlan tag from the network definition, if applicable.
Signed-off-by: Laine Stunp <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Wed, 14 Jan 2026 01:16:50 +0000 (20:16 -0500)]
qemu: update vlan tag of macvtap (direct) passthrough devices during update-device
We already update the vlan tag of interfaces that are attached to an
OVS bridge or Linux host bridge. This patch adds the bit of code
necessary to update the vlan tag of a macvtap passthrough interface
(the only other type of interface that supports vlan tagging).
Resolves: https://issues.redhat.com/browse/RHEL-74487
Resolves: https://issues.redhat.com/browse/RHEL-7300 Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Tue, 13 Jan 2026 05:01:18 +0000 (00:01 -0500)]
qemu: forbid modifying network device portForwards with update-device
Prior to this patch, a network device of a running domain could be
updated to change the portForwards list, and libvirt wouldn't
complain, but the change would be silently ignored. This list is only
used by the passt backend, and passt can only change the list of
portForwards by killing and re-running the passt process, which we
don't want to do because that would destroy any open tcp session flows
in passt (ie. it would disrupt guest network traffic); we don't want
to do *that*, but we should at least let the user know that their
requested change isn't possible.
This patch checks if the portForwards list of the updated network
device exactly matches the portForwards list of the current network
device, and fails the update if they don't match.
Resolves: https://issues.redhat.com/browse/RHEL-7338 Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Mon, 12 Jan 2026 20:20:39 +0000 (15:20 -0500)]
conf: new function virDomainNetPortForwardIsEqual()
This function checks two arrays of virDomainNetPortForwards for
equality. It seemed silly to send a separate #elements for each array
just to check for their equality, but I could easily be convinced to
do it that way (rather than having the caller check for equal #element
and then just send it once).
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Tue, 13 Jan 2026 06:03:23 +0000 (01:03 -0500)]
util: fix equivalence of AF_UNSPEC virSocketAddrs
If a virSocketAddr has family AF_UNSPEC that means it is
unspecified/empty. If two virSocketAddrs are AF_UNSPEC then they are
equal, but virSocketAddrEqual() was countint that as *not* equal. This
doesn't make a difference for current uses of the function since they
all check that at least one of the virSocketAddrs is *not* AF_UNSPEC
before calling virSocketAddrEqual(), but an upcoming patch using
virSocketAddrEqual() will not be making that check, so let's fix the
utility function.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Dion Bosschieter [Thu, 11 Dec 2025 14:00:50 +0000 (15:00 +0100)]
nwfilter: rename ebiptables unit tests and data files
Prepare for introduction of nwfilter nftables driver test files.
Create new nwfilterxml2ebipfirewalldata directory for nwfilter
ebiptables driver specific test files.
This way we split off the xml test data from the argument test
files, which are driver specific.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
Michal Privoznik [Thu, 15 Jan 2026 14:31:54 +0000 (15:31 +0100)]
domain_logcontext: Don't assume remote driver is always available
Some functions inside of domain_logcontext.c call virLogManager
APIs. But that one is available only when remote driver is
enabled. Therefore, make domain_logcontext.c conditional, just
like log_manager.c is: if config.has('WITH_REMOTE').
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/842 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Tue, 13 Jan 2026 16:20:00 +0000 (17:20 +0100)]
qemucapabilitestest: Add 'caps_10.2.0_aarch64' test data
The test dump is obtained on a Raspberry Pi 5, thus the differences in
some of the config, but using this platform will give us the possibility
to update them more frequently.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 11 Dec 2025 17:43:39 +0000 (18:43 +0100)]
qemu: capabilities: Probe properties of 'scsi-block' and 'scsi-generic' devices
Add code to probe properties of 'scsi-block' and 'scsi-generic' qemu
devices. For now the '.replies' are modified using the
'qemu-replies-tool' script and the data is annotated as fake and is in
fact missing. Further updates will populate them for any real dump.
The properties for the two devices will be later used e.g. to detect
support for persistent reservations migration support.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 12 Jan 2026 09:54:38 +0000 (10:54 +0100)]
qemuSecurityMoveImageMetadata: Move seclabels only to virStorageSource of same type
The concept of moving a seclabel is used e.g. when a new image is
introduced to the backing chain (or one of the existing ones becomes
active during block commit). What it does is that it moves the metedata
remembering the original seclabel to the new image.
That idea works reasonably well if both the original and new image are
of same type e.g. a file, where they have comparable seclabel.
It breaks down though when you e.g. create a snapshot stored in a 'file'
on top of a disk originally backed by a 'block' storage source, since
the seclabels differ quite siginificantly.
This patch restricts the seclabel move in qemuSecurityMoveImageMetadata
to happen only if the storage sources are of same type to avoid the
issue. This means that the seclabels will not be remebered and will be
restored to the default but it's better than to transfer wrong labels.
Erik Huelsmann [Tue, 13 Jan 2026 20:10:47 +0000 (21:10 +0100)]
Align help text of virt-aa-helper with actual expectated input
When virt-aa-helper is invoked with a -u parameter followed by an actual UUID
as suggested by the help text, it throws an 'invalid UUID' error, even when the
UUID is the UUID of an existing VM. With this adjustment of the help text,
there's a better chance of users providing the correct input.
Signed-off-by: Erik Huelsmann <ehuels@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
network: Drop const for forwardIf in pfAddNatFirewallRules()
The 'forwardIf' variable inside of pfAddNatFirewallRules() is
declared as both g_autofree and const. This makes no sense.
Since the variable is g_strdup()-ed into right in the
declaration, it's not const. Drop that part of variable
declaration.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
hyperv: Drop const for resourceType in hypervDomainAttachSerial()
The 'resourceType' variable inside of hypervDomainAttachSerial()
is declared as both g_autofree and const. This makes no sense.
Since the variable is g_strdup_printf()-ed into a couple of lines
later, it's not const. Drop that part of variable declaration.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The ELN build root performs rebuilds of Fedora rawhide packages with
%{rhel} set instead of %{fedora}. The vast majority of the time this
will "do the right thing", but when we control -Dwerror we chose to
enable -Werror on RHEL on the basis that the GCC toolchain is stable
and thus we don't expect new warnings to appear. That does not hold
true for ELN which tracks rawhide GCC. Thus we have the rare situation
where we should explicitly check %{eln} not just %{rhel}.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 17 Nov 2025 17:02:15 +0000 (18:02 +0100)]
qemu_firmware: Allow matching both UEFI and BIOS for ROM loader
Currently we apply a 1:1 mapping between loader type and firmware
type: ROM can only match BIOS and pflash can only match UEFI.
That was accurate at the time when the check was introduced, but
is no longer the case today: the Intel TDX build of edk2, for
example, is loaded as a ROM but it still provides an UEFI
implementation to the guest.
Tweak the matching logic so that a ROM loader is allowed to match
both BIOS and UEFI firmware descriptors.
The firmware-manual-efi-tdx test case benefits from this change,
as all the missing information is now correctly filled in.
This will also solve an issue reported to the list, where
firmware builds targeting the confidential VM use case on aarch64
would not be usable at all, due to the way UEFI and ACPI are
depending on each other on the architecture.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Mon, 17 Nov 2025 14:47:30 +0000 (15:47 +0100)]
qemu_firmware: Don't skip autoselection for ROM
It's possible to have firmware descriptors for builds intended to
be loaded as ROM, as is the case for those loaded as pflash.
There is no reason to skip firmware autoselection in those cases,
and doing so prevents useful information from being filled in.
After this change, the firmware-manual-efi-tdx test case is
augmented with some additional information. Even more information
will be filled in later, when we improve the matching logic.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
projects / thirdparty / libvirt.git / log
