Laine Stump [Tue, 3 Feb 2026 21:24:09 +0000 (16:24 -0500)]
qemu: delete passt "repair" socket when appropriate
When using a vhost-user connection between passt and QEMU, passt will
autocreate a socket called ${socketname}.repair, but doesn't delete
this socket when it exits, so to be a good citizen, libvirt should
delete it when we are tearing down the passt device plumbing.
Resolves: https://issues.redhat.com/browse/RHEL-80285 Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jim Fehlig [Fri, 6 Mar 2026 16:56:16 +0000 (09:56 -0700)]
test: Default to ROM type for loader
Commit 1504b7f687 moved the corresponding logic from the generic
postparse code to drivers but failed to update the test driver,
which causes failures in virt-manager's test suite.
Fixes: 1504b7f687bdfc679377e605d076776b18533468 Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Bhyve supports NUMA domains configuration using the '-n'
command line argument:
-n id,size,cpus[,domain_policy]
Here, "id" is a numeric NUMA domain id, "size" is the total VM
memory size with units format similar to the "-m" switch,
"cpus" is a cpuset, and "domain_policy" is an optional
domainset(9) memory allocation policy. The "domain_policy"
is currently not used by the libvirt driver.
This argument is repeated for every NUMA domain to be configured, e.g.:
Jonathon Jongsma [Fri, 27 Feb 2026 20:34:58 +0000 (14:34 -0600)]
hyperv: fix flags passed to virDomainDefParseString()
This function expects flags that are bitwise-or values of the
VIR_DOMAIN_DEF_PARSE_* constants, but we were passing two flags that
were not part of this flag set:
- 1 < VIR_DOMAIN_VIRT_HYPERV
- VIR_DOMAIN_XML_INACTIVE
Replace VIR_DOMAIN_XML_INACTIVE with VIR_DOMAIN_DEF_PARSE_INACTIVE
(which fortunately happens to be the exact same value). Remove flag
"1 < VIR_DOMAIN_VIRT_HYPERV", which turns out to the the same value
as the flag VIR_DOMAIN_DEF_PARSE_ABI_UPDATE_MIGRATION, which seems
unnecessary and undesirable here.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jonathon Jongsma [Fri, 27 Feb 2026 17:56:00 +0000 (11:56 -0600)]
hyperv: ensure we don't define multiple domains with the same name
Right now if we run `virsh define domain.xml` multiple times, it will
result in multiple domains being defined with the same name. This
violates libvirt assumptions about name uniqueness, so prevent this from
happening by returning an error.
There's not much we can do about vms that may have been created outside
of libvirt that might have the same name (unless we switch to using
something like the UUID as the name for hyperv domains, which would
not be very user-friendly), but at least we can not contribute to the
problem.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
Jonathon Jongsma [Fri, 27 Feb 2026 17:47:00 +0000 (11:47 -0600)]
hyperv: improve error message when redefining domain
The current error message results in something like the following when
running `virsh define` for an existing domain:
`domain Domain already exists with UUID '$UUID' exists already`
Improve the error message and make it behave like the esx driver and
indicate that we do not yet support redefining existing domains in hyperv.
Also avoid using the public LookupByUUID() API to check for existance,
which requires unnecessarily allocating and de-allocating a virDomainPtr
object.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
util: json: fix memory leak in virJSONValueFromJsonC()
In the 'json_type_object' and/ro 'json_type_array' cases, the
error path uses 'g_free()', which doesn't release other nested
memory allocations. Replace it with 'virJSONValueFree()' to
properly free the entire 'virJSONValue' structure.
Fixes: 9e6555fd90988948a05e83466b1903bb95b36f39 Fixes: da66bf53b09ee8f5facacae700638a9a6f3a2477 Signed-off-by: Elizaveta Tereshkina <teryoshkina.ea@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Pavel Hrdina [Fri, 27 Feb 2026 16:55:34 +0000 (17:55 +0100)]
qemu: Fix IOMMUFD and VFIO security labels
When IOMMUFD support was introduced it incorrectly tried to label
`/dev/iommu` and `/dev/vfio/devices/vfioX` but they are not added to
QEMU namespace because libvirt opens FDs and passes these FDs to QEMU.
We need to label these FDs instead.
Fixes: 7d2f91f9cb572ab95d0916bdd1a46dd198874529 Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
A recent commit caused the virFDStreamRead method to loop reading data
until the provided buffer is full. Unfortunately the EOF handling was
not quite correct.
* When seeing a virFDStreamMsg with length zero, it would still
loop trying to read more and then get an error that the thread
has quit.
* When seeing a virFDStreamMsg with length zero on subsequent
iterations, it would discard this message, which would in turn
prevent the caller from ever seeing the 'ret == 0' return value
indicating EOF. The caller would then try to read again and get
an error about the stream being closed.
Fixes: e23fd0b7fd36c41e6db49df4f4962762d3ef6ab0 Reported-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Tested-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
fdstream: don't set return value if looping to read more data
The 'ret' variable should only have a value assigned once we have
completely finished reading data, otherwise an error on a subsequent
iteration will report an error but not return a negative value.
Fixes: e23fd0b7fd36c41e6db49df4f4962762d3ef6ab0 Reported-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Tested-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Pavel Hrdina [Thu, 26 Feb 2026 09:18:23 +0000 (10:18 +0100)]
domain_conf: initialize network hostdev private data
Currently virDomainNetDef and virDomainActualNetDef use
virDomainHostdevDef directly as structure and the code doesn't call
virDomainHostdevDefNew() that would initialize private data.
This is hackish quick fix to solve a crash that happens in two
scenarios:
1. attaching any interface with hostdev backend
0x0000fffbfc0e2a90 in qemuDomainAttachHostPCIDevice (driver=0xfffbb4006750, vm=0xfffbf001f790, hostdev=0xfffbf400b150) at ../src/qemu/qemu_hotplug.c:1652
1652 if ((ret = qemuFDPassDirectTransferMonitor(hostdevPriv->vfioDeviceFd, priv->mon)) < 0)
2. starting VM with interface with hostdev backend using iommufd
0x00007f6638d5b9ca in qemuProcessOpenVfioDeviceFd (hostdev=hostdev@entry=0x7f6634425ee0) at ../src/qemu/qemu_process.c:7719
7719 hostdevPriv->vfioDeviceFd = qemuFDPassDirectNew(name, &vfioDeviceFd);
Proper fix for this issue is to refactor network code to use pointer and to
use virDomainHostdevDefNew().
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Stefan Kober [Wed, 25 Feb 2026 12:50:16 +0000 (13:50 +0100)]
util: fix use-after-free in virIdentityGetSystem
We have a g_autoptr ret in the virIdentityGetSystem function. In the
happy path it is properly returned by doing: return g_steal_pointer(&ret);
There are 2 early return paths, were we do the following: "return ret;"
This leads to the g_autoptr being cleaned up after we leave the
function, as we do not properly "steal" it.
When later using the return value we have a use-after-free, which has
led to segfaults in some cases.
As this is a regression introduced in v5.9.0-rc1~269, we change
the behavior to properly return NULL in those cases.
Fixes: c6825d88137cb8e4debdf4310e45ee23cb5698c0
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Mon, 23 Feb 2026 15:23:10 +0000 (16:23 +0100)]
qemu: Fix job handling when domain dies in post-copy migration
When a domain is in post-copy migration phase, we need to keep the job
active if something fails to protect the domain from changes.
Unfortunately, there is a race between migration code and
qemuProcessStop that can cause the job to stay active even when the
domain is gone and thus preventing the domain from being started again
(until virtqemud is restarted). The race is caused by unlocking the vm
object when calling virConnectUnregisterCloseCallback. While the domain
is unlocked qemuProcessStop can finish its work and the domain may no
longer be active when we get the lock back. The post-copy path does not
properly check if a domain is still active.
Instead of adding the virDomainObjIsActive check in all places where
this could happen, we can add it in virDomainObjIsPostcopy and
virDomainObjIsFailedPostcopy and let the code take the pre-copy cleanup
path. Clearly an inactive domain can never be in (failed) post-copy
migration.
https://issues.redhat.com/browse/RHEL-145179
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
news: Document support for uefi-vars device and firmwares
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Document the fact that the existing flags which apply to
NVRAM files also do the right thing when varstore files are
used instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Fri, 30 Jan 2026 17:34:40 +0000 (18:34 +0100)]
include: Mention varstore where applicable
We are not introducing additional API flags for varstore
handling since that would require unnecessary churn in all
libvirt-based apps, and the intent is the same: recreate
the UEFI variable storage, be it NVRAM or varstore, from its
template.
In order to clarify that the existing flags affect varstore
too, update their documentation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Tue, 11 Nov 2025 14:33:41 +0000 (15:33 +0100)]
qemu_command: Use uefi-vars device where appropriate
This makes guests actually functional.
https://issues.redhat.com/browse/RHEL-82645
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Tue, 20 Jan 2026 14:28:17 +0000 (15:28 +0100)]
tests: Add firmware descriptors for uefi-vars builds
Now that everything else is in place, we can finally add the
firmware descriptors for the edk2 builds that use the uefi-vars
QEMU device.
Several existing test cases that were failing up until this
point can pass now. This includes firmware-auto-efi-varstore-q35,
firmware-auto-efi-varstore-aarch64 and
firmware-auto-efi-enrolled-keys-aarch64, which were only failing
because a matching firmware descriptor could not be found.
firmware-manual-efi-varstore-aarch64 also passes now, because
with the firmware descriptor in place libvirt is able to figure
out that the manually-provided path corresponds to a UEFI
firmware build, which means that the use of ACPI is fine.
The test cases using older version of QEMU still fail, as is
expected, though the error message is now slightly different and
reflect the actual reason why that is.
The qemufirmware and domaincaps tests are updated in the
expected ways. In particular, versions QEMU 10.0 and newer now
advertise varstore support as available.
https://issues.redhat.com/browse/RHEL-82645
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Wed, 28 Jan 2026 14:42:16 +0000 (15:42 +0100)]
security: Handle varstore file
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
security: Mark ROMs as read only when using AppArmor
Before this, attempting to use a ROM that was not explictly
marked at read only resulted in an error at startup time.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Fri, 23 Jan 2026 18:47:13 +0000 (19:47 +0100)]
qemu: Create and delete varstore file
Simply mimicking what is currently done for NVRAM files does
the trick. A few user-visible messages are updated to reflect
the fact that they apply both to NVRAM and varstore.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Most of the code in the qemuPrepareNVRAMFile() function can
be reused to create a varstore file from template. Move the
common parts to a generic helper, leaving only the parts
that are NVRAM-specific in the original function.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Wed, 21 Jan 2026 17:25:37 +0000 (18:25 +0100)]
qemu_firmware: Generate varstore path when necessary
Introduce qemuFirmwareEnsureVarstore(), which performs the same
task as the existing qemuFirmwareEnsureNVRAM() but for the
varstore element.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This is the same as the existing nvramDir, except it will be
used to store the files used with the uefi-vars QEMU device.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Wed, 21 Jan 2026 18:42:40 +0000 (19:42 +0100)]
qemu_firmware: Fill in varstore information
If the matching firmware requires the use of varstore, we
have to bubble up information about it, namely the path to
the template. If the struct member doesn't exist yet, we need
to allocate it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 19 Jan 2026 17:48:50 +0000 (18:48 +0100)]
qemu_firmware: Allow matching stateful ROMs
Stateful ROMs are those that use the uefi-vars QEMU device to
implement access to UEFI variable storage.
Matching works much the same as it does for pflash-based
firmware images. Notably, the <varstore> element is only
allowed for ROM and the <nvram> element is only allowed for
pflash.
The firmware-auto-efi-varstore-q35 and
firmware-auto-efi-varstore-aarch64 fail in a different way
after this change: the input XML is now considered valid, and
the only remaining issue is that the firmware autoselection
process is unable to find a match.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
qemu_firmware: Use of NVRAM implies stateful firmware
Currently we only look at the value for the stateless attribute
itself when matching, but the <nvram> element being included in
the input XML is likewise a clear sign that a stateless firmware
build will not satisfy the user's requirements.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Fri, 30 Jan 2026 16:45:08 +0000 (17:45 +0100)]
qemu: Fill in varstore element in domcaps
The element should only be advertised as supported if the QEMU
binary contains the necessary device and a suitable JSON firmware
descriptor is found on the system. Right now the latter
requirement is not satisfied, so it's marked as not supported
across the board.
The qemufirmware test is extended to cover the new attribute.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Fri, 30 Jan 2026 16:46:30 +0000 (17:46 +0100)]
conf: Include varstore element in domcaps
We want to advertise whether the element is usable when
defining new domains.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 17 Nov 2025 15:59:40 +0000 (16:59 +0100)]
qemu_firmware: Report NVRAM template path for ROMs
This was not necessary until now since ROMs couldn't have an
associate NVRAM template, and technically speaking they still
can't; however, the varstore template serves essentialy the
same purpose.
The qemuFirmwareGetSupported() helper is used in two places:
one is the code that is responsible for filling in domaincaps,
where templates are ignored so this change has no impact on it;
the other is the qemufirmware test program, where this value
being reported is useful as it will allow us to confirm that
the JSON firmware descriptors for uefi-vars enabled builds are
parsed correctly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 19 Jan 2026 16:34:23 +0000 (17:34 +0100)]
qemu_firmware: Support extended syntax for ROM firmware descriptors
The existing syntax can only describe stateless firmware builds,
while the extended one can additionally describe builds intended
for use with the uefi-vars device. This involves including the
path to the corresponding varstore template.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 24 Nov 2025 13:42:45 +0000 (14:42 +0100)]
qemu_firmware: Consider host-uefi-vars feature in sanity check
Just like with firmware builds targeting the confidential use
case, use of the uefi-vars device obviates the need to have SMM
emulation enabled while still guaranteeing that protected EFI
variables work as intended.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 24 Nov 2025 13:36:55 +0000 (14:36 +0100)]
qemu_firmware: Split sanity check
The two checks are semantically different, so it makes sense to
perform them separately. We will soon extend the first one.
While at it, start printing out the value of isConfidential. We
could print the value of each firmware feature it's derived from,
but that would make things unnecessarily verbose; at the same
time, knowing that libvirt believes that the firmware build is
targeting the confidential use case can be useful for debugging
so it's worth including it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When present in a firmware descriptor, this feature indicates that
the corresponding executable expects to access variable storage
through the uefi-vars QEMU device.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This test case demonstrates how to automatically configure an
aarch64 guest so that Secure Boot support is available and only
signed operating systems are allowed to boot.
It currently fails because there is no firmware descriptor that
describes a suitable firmware build yet. That will change in a
future commit.
In addition to the latest version, the test case is also executed
against QEMU 8.2.0 specifically. This version of the test case is
intended to fail, because the uefi-vars device that we need to
support Secure Boot on aarch64 was not yet available in that
version of QEMU. The exact error message will change down the
line.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Thu, 22 Jan 2026 13:45:28 +0000 (14:45 +0100)]
tests: Add firmware-auto-efi-varstore-aarch64
This test case demonstrates how to explicitly opt into using
the uefi-vars device for an aarch64 guest.
Normally the firmware autoselection process will pick a UEFI
build that is loaded via pflash, but by including the <varstore>
element in the input XML we can tell the QEMU driver that we
want want the uefi-vars device to be used instead.
Currently this results in an error, because the firmware
autoselection algorithm doesn't yet know how to properly handle
the scenario. A future commit will address this and make things
work as expected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Thu, 22 Jan 2026 13:42:34 +0000 (14:42 +0100)]
tests: Add firmware-auto-efi-varstore-q35
This test case demonstrates how to explicitly opt into using
the uefi-vars device for an x86_64 guest.
Normally the firmware autoselection process will pick a UEFI
build that is loaded via pflash, but by including the <varstore>
element in the input XML we can tell the QEMU driver that we
want want the uefi-vars device to be used instead.
Currently this results in an error, because the firmware
autoselection algorithm doesn't yet know how to properly handle
the scenario. A future commit will address this and make things
work as expected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Tue, 18 Nov 2025 13:46:12 +0000 (14:46 +0100)]
tests: Add firmware-manual-efi-varstore-aarch64
This test case demonstrates how to manually configure an aarch64
guest to use the uefi-vars device.
It currently fails because the QEMU driver does not yet recognize
the firmware type as EFI, and so rejects the attempt to use ACPI
together with it. That will change in a future commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This test case demonstrates how to manually configure an x86_64
guest to use the uefi-vars device.
It fails when using an older version of QEMU which didn't have
the device, and succeeds when using the latest version. The
relevant bits of the QEMU command line are not generated yet,
but that will come in a later commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Fri, 21 Nov 2025 18:32:31 +0000 (19:32 +0100)]
qemu: Validate presence of uefi-vars device
The use of varstore requires the uefi-vars device to be present
in the QEMU binary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This capability indicates the availability of the uefi-vars
device.
The actual name of the QEMU device varies slightly depending on
the architecture: it's uefi-vars-x64 on x86_64, uefi-vars-sysbus
on other UEFI architectures (aarch64, riscv64, loongarch64).
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Thu, 22 Jan 2026 18:27:03 +0000 (19:27 +0100)]
conf: Update validation to consider varstore element
The code is reworked quite significantly, but most of the
existing checks are preserved. Those that aren't, notably the
one that allowed pflash as the only acceptable non-stateless
firmware type, are intentionally removed because they will no
longer reflect reality once support for the uefi-vars QEMU
device is introduced.
As a side effect, reworking the function in this fashion
resolves a subtle bug: due to the early exits that were being
performed when the loader element was missing, the checks at
the bottom of the function (related to the shim and kernel
elements) were effectively never performed. This is no longer
the case.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 19 Jan 2026 13:20:06 +0000 (14:20 +0100)]
conf: Parse and format varstore element
This will be used to configure the backing storage used by the
uefi-vars QEMU device.
Dealing with the element itself is trivial, however we have to
refactor the existing code which deals with the loader and nvram
elements slightly: in particular, we can no longer perform an
early exit if those elements are absent.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 23 Feb 2026 12:57:32 +0000 (13:57 +0100)]
schema: Introduce osnvram define
This moves the definition of the <nvram> element out of the
fairly complex oshvm define and will make it easier to later
add the <varstore> element without making things unmanageable.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Fri, 23 Jan 2026 13:34:05 +0000 (14:34 +0100)]
tests: Rename custom JSON firmware descriptors
Most of the JSON firmware descriptors in our test suite come from
the Fedora package for edk2, but there are a few additional ones
that we have created ourselves to ensure coverage of uncommon or
problematic scenarios.
In order to make sure that such descriptors are clearly marked as
custom, rename them to include the string "libvirt" in the path.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Right now we set this default in the common parsing code, which
is not a big problem per se but would get in the way of some
upcoming changes.
Leave this choice to individual drivers instead. Only the QEMU
and Xen drivers use the value for anything, so we can limit the
amount of code duplication this change causes.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
qemu_firmware: Only set format for custom loader if path is present
We only set the template format if the template path is present,
and we should be consistent with that. The format on its own is
not very interesting anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 23 Feb 2026 13:58:15 +0000 (14:58 +0100)]
docs: Improvement related to firmware selection
Recommend that users take advantage of firmware autoselection
and discourage providing paths manually.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 23 Feb 2026 13:55:20 +0000 (14:55 +0100)]
docs: Rename "BIOS bootloader" section to "guest firmware"
The new name is much more accurate since the documentation is
applicable to firmware other than BIOS, notably UEFI.
An empty container is used to keep old links working.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
hyperv: Add basic domainGetBlockInfo() API implementation
This adds initial support for virDomainGetBlockInfo() for the hyperv
driver. It currently supports:
- physical disk drives that are assigned to a vm
- virtual disk drives backed by a .VHD file that are local to the host
- other drives backed by local files (e.g. cdrom with a .iso)
It will fail to get allocation and physical values for any drives backed
by files that are not local to the host (e.g. on network shares)
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
conf: support windows paths in virDomainDiskByName()
With the hyperv driver, disks might have windows paths like
"c:\path\to\disk.vhdx". Currently, this function supports paths, but
only if they're in unix format.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 17 Feb 2026 13:38:37 +0000 (14:38 +0100)]
qemu: saveimage: Use 'virFileWrapperFd' when loading non-sparse saveimage
Always instantiate a 'virFileWrapperFd' (iohelper) to wrap the saveimage
file descriptor of a non-'sparse' format saveimage.
For 'sparse' images we also need to ensure that the FD returned when
opening the save image is an actual file FD (thus not the FD from the
helper process used to bypass root-squashed NFS) as qemu requires an
actual file in those cases.
This patch reworks 'qemuSaveImageOpen' to create the wrapper process
based on whether the 'wrapperFd' variable is non-NULL rather than
based on a combination of 'sparse' and 'bypass_cache' flags. The caller
will then based on the image format and the need for the wrapper use the
appropriate settings.
As with this patch all non-sparse images will always pass a pipe instead
of a file to qemu it also fixes problems with qemu-11.0 where the 'fd'
migration protocol rejects FDs which point to a file.
Resolves: https://issues.redhat.com/browse/RHEL-76301 Closes: https://gitlab.com/libvirt/libvirt/-/issues/850 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 17 Feb 2026 12:22:44 +0000 (13:22 +0100)]
qemu: driver: Merge 'qemuDomainRestoreInternal' and 'qemuDomainObjRestore'
The two functions are for reverting a save image. They differ only on
what domain object is used (new one vs existing one). Merge the code
paths for existing VMs (for managed save restore) into
'qemuDomainRestoreInternal' and reuse it instead of
'qemuDomainObjRestore'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 11 Feb 2026 16:31:56 +0000 (17:31 +0100)]
qemuSaveImageCreateFd: Handle case when 'virQEMUFileOpenAs' doesn't return a file fd for 'sparse' format
The 'sparse' uses a mode in qemu which requires direct access to the
file descriptior of the file itself. If we reside on root-squashed NFS
the FD from 'virQEMUFileOpenAs' may not actually be a file which would
not work with qemu.
Reject such a config with a better error message and add documentation
outlining the quirk.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virpci: Report an error if virPCIGetVirtualFunctionIndex() fails
Either an error should be returned in all error paths in a
function or in none (leaving it up to caller). Well,
virPCIGetVirtualFunctionIndex() breaks this pattern. Fix it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
Implement domainGetVcpuPinInfo for querying vcpu pinning information.
Also, implement a couple of other APIs this one depends on:
domainGetVcpusFlags and domainGetMaxVcpus.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Bhyve supports vcpu pinning using the `-p vcpu:hostcpu`
argument. This argument can be specified multiple times for the same
vcpu to pin it to multiple hostcpu's.
Bhyve currently does not allow to change vcpu pinning configuration for
the VM that is already running.
Use this to support domain's vcpupin configuration such as:
When virDomainAbortJob is called with VIR_DOMAIN_ABORT_JOB_POSTCOPY flag
and the post-copy migration of the domain is already stopped (either
because of a failure or previous call to virDomainAbortJob), the
migrate-pause QMP command fails with "migrate-pause is currently only
supported during postcopy-active or postcopy-recover state". Such error
might be confusing to end users especially when we mark it as an
internal error. Let's not call the QMP command at all and report a
clear error message instead.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Mon, 16 Feb 2026 09:42:07 +0000 (10:42 +0100)]
virstorageobj: Make virStoragePoolObjAddVol() report an error on failure
Adding a storage volume into a pool is done by calling
virStoragePoolObjAddVol(). This function may fail if another
volume already exists with the same key/name/target. In some
cases the storage driver does check for duplicates before calling
the function. But in some cases (e.g. when refreshing an RBD pool
in virStorageBackendRBDRefreshPool()) it doesn't.
The problem here is that the function reports no error upon
failure and leaves it as an exercise for caller. Well, no caller
does that.
Therefore, make the function report an error. The advantage of
this approach is - the function can report more accurate error
message than any caller ever could.
NB¸ this stems from a discussion on the users list [1], and while
this does NOT solve the original issue, it fixes one of the
symptoms.
1: https://lists.libvirt.org/archives/list/users@lists.libvirt.org/message/BALVNCRQM4KBKGV4RQ7BMKSX7UIJKLQH/ Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Lucas Amaral [Mon, 16 Feb 2026 15:50:06 +0000 (12:50 -0300)]
virsh: report "unknown" for autostart when API query fails
When virStoragePoolGetAutostart(), virNetworkGetAutostart(), or
virNodeDeviceGetAutostart() fails, the respective info commands
report "no autostart". This is incorrect: the API failure means
we cannot determine the autostart state, not that autostart is
disabled.
The persistent field in the same functions already correctly
reports "unknown" on API failure. Apply the same pattern to the
autostart field for consistency and correctness.
Signed-off-by: Lucas Amaral <lucaaamaral@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Lucas Amaral [Mon, 16 Feb 2026 14:48:17 +0000 (11:48 -0300)]
virsh: return failure exit code when UUID fetch fails
The domuuid, net-uuid, and pool-uuid commands call vshError() when
GetUUIDString() fails, but unconditionally return true, which
vshCommandRun() maps to EXIT_SUCCESS. This means scripts checking
$? see success despite the error.
Return false on failure so the exit code correctly reflects the
error, consistent with other virsh commands.
Signed-off-by: Lucas Amaral <lucaaamaral@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
qemu: Fill in firmwareFeature element for domaincaps
On architectures that support neither UEFI nor BIOS as firmware,
such as ppc64 and s390x, the enums end up empty. This correctly
indicates that filtering by firmware feature is not possible, and
is consistent with the fact that the existing "firmware" enum is
also empty in those cases, meaning that firmware autoselection
itself is just not applicable.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
projects / thirdparty / libvirt.git / log
