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>
Andrea Bolognani [Mon, 17 Nov 2025 18:48:43 +0000 (19:48 +0100)]
tests: Add firmware-manual-efi-tdx
This test case demonstrates that firmware selection does not run
for domains manually configured to use the Intel TDX build of
edk2, and as a result some expected information is missing; in
particular, the fact that the firmware type is EFI is not
reflected in the domain XML.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Mon, 17 Nov 2025 18:42:35 +0000 (19:42 +0100)]
tests: Add firmware-manual-efi-sev-snp
This test cases demonstrates that firmware selection runs for
domains manually configured to use the AMD SEV build of edk2, and
that the missing information (firmware features, as well as the
fact that firmware type is EFI) are correctly filled in.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Fri, 28 Nov 2025 14:53:00 +0000 (15:53 +0100)]
qemu_firmware: Remove NVRAM to loader format copy hack
Now that the hack is gone, a few test cases that were failing
before start succeeding instead.
The firmware-auto-efi-format-nvramtemplate-qcow2 test case
originally passed but produced wrong results, then started
failing once we began taking templateFormat into account, and now
passes once again, finally producing the correct results.
The firmware-auto-efi-format-nvram-raw-loader-path and
firmware-auto-efi-format-nvram-raw-nvramtemplate-path test cases,
on the other hand, never passed before now, because the hack
resulted in information contradicting those provided by the user
being injected into the configuration, which in turn made it
impossible to successfully pick a firmware build. With the hack
gone they can finally succeed, as they should have in the first
place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Fri, 28 Nov 2025 14:18:35 +0000 (15:18 +0100)]
qemu_firmware: Take NVRAM format into account when matching
Commit d3016e47be5f removed a hunk very similar to the one we're
adding with the rationale that there is no actual requirement for
the NVRAM file and the NVRAM template to have the same format,
which is completely correct: while libvirt will not perform the
format conversion itself, the user can do that on their own and
everything (except RESET_NVRAM) will work just fine.
That said, we also need <nvram format='foo'/> specified on its
own with no <loader> element to result in a firmware build with a
foo-formatted NVRAM template to be picked. Right now this works
thanks to the hack at the top of qemuFirmwareFillDomain() which
copies nvram.format to loader.format, but we want to get rid of
that because it has additional side effects that can lead to
confusing outcomes in certain specific scenarios.
So reintroduce this check, but make it extremely narrow: if any
other information that can influence firmware selection is
present in the domain XML, ignore the NVRAM format entirely; if
however the NVRAM format is the only information that was
provided, consider it when looking for a match.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Wed, 26 Nov 2025 18:05:18 +0000 (19:05 +0100)]
qemu_firmware: Take templateFormat into account when matching
If the user has specified a desired format for the NVRAM
template, we should take that information into account when
looking for a suitable firmware build instead of ignoring it.
Two test cases start failing as a result of this change.
For firmware-auto-efi-format-nvramtemplate-qcow2, the failure
is temporary and the test case will pass once again with an
upcoming commit. It should be noted that, until now, the selected
firmware used raw, not qcow2, as the NVRAM template format,
meaning that though the test case passed the outcome was not the
desired one.
For firmware-auto-efi-format-mismatch-nvramtemplate, the failure
is desired and the test case should not have succeeded in the
first place, as there are no firmware descriptors for a build
that uses raw format for the executable and qcow2 format for the
NVRAM template.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Right now we throw the entire definition away if the path is
not present, including the format. This effectively results in
discarding user-provided information.
This change fixes the firmware-auto-efi-format-mismatch test
case. Until now, the NVRAM format ended up being raw (matching
the NVRAM template) despite the user explicitly asking for it
to be qcow2 instead.
While this means that libvirt will no longer be able to start
such a VM without user intervention, since it does not
automatically perform conversion between formats, that's still
preferrable to silently overriding an explicit user's request.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Fri, 28 Nov 2025 16:00:09 +0000 (17:00 +0100)]
qemu_firmware: Prefer template format to loader format
In the vast majority of cases they will match, but it just makes
more logical sense to copy the format from the NVRAM template to
the NVRAM file itself.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Wed, 17 Dec 2025 00:12:35 +0000 (01:12 +0100)]
qemu_firmware: Refactor setting NVRAM format
Instead of setting the format every single time, knowing that we
might throw away the entire definition immediately afterwards,
and duplicating a check, only set it if we are going to perform
an early return due to the rest of the definition being properly
filled in already.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently we're doing a weird dance to avoid overwriting the
user-provided path to the NVRAM template, which might potentially
be one we actually know about but just so happens not to be
listed first. Explaining why we're doing things this way requires
a fairly long comment.
We can make things simpler: if the NVRAM template path is present
in the domain XML, include it into the matching criteria. This is
consistent with how we match firmware descriptors.
Handling of format, both for the firmware executable and the
NVRAM template, is improved too. Legacy paths were used before
non-raw firmware builds existed, so we can set the format to raw
unconditionally.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Simple helper for the case where completely custom firmware paths
are in use. It's quite trivial right now, but it will be expanded
slightly in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates an issue with the current
implementation of firmware autoselection.
While the test case passes, the outcome is not the desired one.
The domain XML explicitly requests that the format for the
firmware excutable is raw and the format for the NVRAM template
is qcow2: since there are no firmware descriptors that satisfy
these requirements, this should result in a failure. Instead, the
second request is simply ignored and a firmware that uses raw
format NVRAM template is selected.
The issue will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates an issue with the current
implementation of firmware autoselection.
While the test case passes, the outcome is not the desired one.
The domain XML explicitly requests that the NVRAM template is in
qcow2 format, and yet the selected firmware build uses the raw
format for the NVRAM template instead.
The issue will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates an issue with the current
implementation of firmware autoselection.
There is no requirement for the format of the NVRAM file (raw in
this case) to match that of the NVRAM template (qcow2 in this
case), and yet libvirt incorrectly rejects the configuration.
The issue will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates an issue with the current
implementation of firmware autoselection.
libvirt would normally be able to find the firmware descriptor
for the binary mentioned in the domain XML, but the fact that at
the same time we're asking for the NVRAM file to be of a
different format throws a spanner in the works.
Of course there is no requirement for the format of the NVRAM
file to match that of the NVRAM template, so the fact that
libvirt is unable to produce a working configuration out of this
input is an issues that will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Mon, 15 Dec 2025 22:21:16 +0000 (23:21 +0100)]
tests: Add firmware-auto-efi-format-nvram-raw
This test case demonstrates that it's possible to explicitly
select the format for the NVRAM template, and usually the
firmware binary itself, by using the <nvram format='foo'/>
shorthand syntax.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test cases demonstrates that it's possible to use a custom
NVRAM template together with a standard firmware binary even when
referring to the latter by its legacy path rather than its
modern, canonical one.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
projects / thirdparty / libvirt.git / log
