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>
Pavel Hrdina [Sun, 15 Feb 2026 18:13:19 +0000 (19:13 +0100)]
qemu_process: Fix FD leak with multiple host devices using IOMMUFD
We would open IOMMU device for each host device with IOMMUFD backend
leaking FD except for the last one. Since we are adding only single
iommufd object we need to open it only once.
Fixes: 2f0999a161910e3992458902ce90d37f8b8f2642 Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Fri, 23 Jan 2026 16:18:14 +0000 (17:18 +0100)]
qemu: Setup disk latency histograms on startup/hotplug/update
Setup the histograms on startup and hotplug of devices via
'qemuProcessSetupDiskPropsRuntime' and facilitate update/reset/disable
of histogram collection via 'qemuDomainChangeDiskLive'.
The latter allows to use the update device API to either clear the bins
or select new bin configuration or disable the histogram altogether
without the need for a specific API.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 29 Jan 2026 13:08:18 +0000 (14:08 +0100)]
qemu: monitor: Extract block latency histogram stats into 'qemuBlockStats'
Extract the 'rd_latency_histogram', 'wr_latency_histogram',
'zone_append_latency_histogram', and 'flush_latency_histogram' stats
objects into our internal data.
Rather than storing 'boundaries' between bins we store them as start
points.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Wed, 11 Feb 2026 09:16:34 +0000 (10:16 +0100)]
qemu: Wire up new hyperv host-model mode behavior
Since some hyperv features might be already enabled/disabled when
entering qemuProcessEnableDomainFeatures() only those which are
not set in domain XML (i.e. are VIR_TRISTATE_SWITCH_ABSENT)
should be modified. Furthermore, some features are not a simple
on/off switch, but a number or a string even. Well, that doesn't
matter really as the logic for setting them is the same: only set
their value iff they are not already set.
Resolves: https://issues.redhat.com/browse/RHEL-148219 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 11 Feb 2026 09:16:28 +0000 (10:16 +0100)]
conf: Parse hyperv features even for host-model
As it turns out, some users of the hyperv "host-model" mode might
want to override the hypervisor defaults. For instance disable a
feature that's on by default, or vice versa. Currently, this is
not possible because as soon as our XML parser sees the
"host-model" mode it exits early and skips parsing of individual
features (for "custom" mode). Well, do not return early and parse
the rest.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Bhyve on arm64 does not have the bhyveload(8) tool.
That means that it cannot be used as a default if the loader is not
configured for the domain.
To prevent users from getting unusable configurations, handle loader
configuration on arm64 like that:
- if loader is specified in the domain XML, just use it
- if not specified, try to check whether the default uboot loader
is available on the system. In case it is, set is as the loader,
otherwise fail with the error.
Additionally, the loader could be configured in bhyve.conf.
By default, it uses the loader installed by the
sysutils/u-boot-bhyve-arm64 port or a corresponding package.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Erik Huelsmann [Wed, 11 Feb 2026 17:36:06 +0000 (18:36 +0100)]
In virFDStreamRead(), fill buffer from this and next messages
Before this change, buffers returned from virFDStreamRead() would
alternate in size (262120 and 24), because it only consumed the
bytes remaining from the current background thread message.
As the background thread reads 262144 bytes (256kB) of data in
each chunk, where the maximum size returned from virFDStreamRead()
to be transferred over the remote protocol is only 262120, 24 bytes
would be left in the buffer on each iteration. The next iteration
leaves 24 bytes, which used to be returned without considering
messages waiting in the queue.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Erik Huelsmann <ehuels@gmail.com>
With that, ACPI tables are always generated. As this change is
relatively new and there are likely systems that have bhyve(8) that
requires using the '-A' flag, add a capability probing for that, and
use this flag if it's supported.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
util: remove duplicate logging of firewall command
The vircommand.c code will always log the argv about to
be run, so logging it again in virfirewall.c is redundant.
Removing the dupe avoids the repeated memory allocation
from the array -> string conversion.
The minor difference is the downgrade from INFO to DEBUG
level, but the use of INFO level was out of character for
libvirt to begin with.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Arun Menon [Tue, 10 Feb 2026 17:56:42 +0000 (23:26 +0530)]
secret: Add functionality to load and save secrets in encrypted format
Now that we have the functionality to provide the secrets driver
with an encryption key through a configuration file or using system
credentials, and the newly introduced array to iterate over the
encryption schemes, we can use the key to save and load secrets.
Encrypt all secrets that are going to be saved on the disk if the
'secrets_encryption_key' path is set in the secret.conf file OR
if a valid systemd generated credential exists.
While loading secrets, identify the decryption method by matching the file
extension of the stored secret against the known array values.
If no matching scheme is found, the secret is skipped. If the encryption
key is changed across restarts, then also the secret driver will fail to load
the secrets from the disk that were encrypted with the former key.
Signed-off-by: Arun Menon <armenon@redhat.com> Co-authored-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Arun Menon [Tue, 10 Feb 2026 17:56:41 +0000 (23:26 +0530)]
secret: Rename virSecretObj structure attribute from base64File to secretValueFile
Change the attribute name of _virSecretObj because we want it to have a generic
name to indicate that secret values can be stored in it in both base64 and
encrypted formats.
Signed-off-by: Arun Menon <armenon@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Arun Menon [Tue, 10 Feb 2026 17:56:40 +0000 (23:26 +0530)]
secret: Add secret.conf configuration file and parse it
A new configuration file called secret.conf is introduced to
let the user configure the path to the secrets encryption key.
This key will be used to encrypt/decrypt the secrets in libvirt.
By default the path is set to the runtime directory
/run/libvirt/secrets, and it is commented in the config file.
After parsing the file, the virtsecretd driver checks if an
encryption key is present in the path and is valid.
If no encryption key is present in the path, then
the service will by default use the encryption key stored in the
CREDENTIALS_DIRECTORY.
Add logic to parse the encryption key file and store the key.
It also checks for the encrypt_data attribute in the config file.
The encryption and decryption logic will be added in the subsequent patches.
Signed-off-by: Arun Menon <armenon@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Arun Menon [Tue, 10 Feb 2026 17:56:39 +0000 (23:26 +0530)]
secret: Set up default encryption secret key for the virtsecretd service
This commit sets the foundation for encrypting the libvirt secrets by providing a
secure way to pass a secret encryption key to the virtsecretd service.
A random secret key is generated using the new virt-secret-init-encryption
service. This key can be consumed by the virtsecretd service.
By using the "Before=" directive in the new virt-secret-init-encryption
service and using "Requires=" directive in the virtsecretd service,
we make sure that the daemon is run only after we have an encrypted
secret key file generated and placed in /var/lib/libvirt/secrets.
The virtsecretd service can then read the key from CREDENTIALS_DIRECTORY. [1]
This setup therefore provides a default key out-of-the-box for initial use.
A subsequent commit will introduce the logic for virtsecretd
to access and use this key via the $CREDENTIALS_DIRECTORY environment variable. [2]
Arun Menon [Tue, 10 Feb 2026 17:56:38 +0000 (23:26 +0530)]
util: Add support for GnuTLS decryption
Adds `virCryptoDecryptDataAESgnutls` and `virCryptoDecryptData`
as wrapper functions for GnuTLS decryption.
These functions are the inverse of the existing GnuTLS encryption wrappers.
This commit also includes a corresponding test case to validate data decryption.
Signed-off-by: Arun Menon <armenon@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Thu, 5 Feb 2026 14:10:36 +0000 (15:10 +0100)]
qemuProcessRefreshDisks: Don't bother to refresh disks on cold boot
The only thing that 'qemuProcessRefreshDisks' currently does is to
update tray state for disks. This makes no sense on cold boot since only
cdroms have tray and the tray is closed.
Avoid the extra call to 'query-block' on cold boot and just assume CDROM
has a closed tray.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 5 Feb 2026 13:31:41 +0000 (14:31 +0100)]
qemu: Refactor tray_status handling
Modify the monitor code to directly return values from 'virDomainDiskTray'
enum instead of two bools.
This allows simplification of the other code:
- qemuProcessRefreshDiskProps just assigns the value, thus can be deleted
- old_tray_status is no longer needed as we can directly access the
disk status instead and assign later
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 5 Feb 2026 13:18:46 +0000 (14:18 +0100)]
qemuDomainAttachDiskGeneric: Avoid unneeded disk property refresh after hotplug
The only thing the call to 'qemuProcessRefreshDiskProps' would update
from data gathered from a 'query-block' QMP call would be the state of
the tray of the device. We know that only CDROM devices have a tray and
after hotplug it's closed.
Remove the unneeded code and adjust tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 3 Feb 2026 14:14:14 +0000 (15:14 +0100)]
conf: domain: Add VIR_DOMAIN_DISK_TRAY_NONE state for devices without tray
Currently the default state was VIR_DOMAIN_DISK_TRAY_CLOSED. Not all
disks have a tray so add another state as the default and adjust code
which was based on the assumption that the tray is always present.
This change also removes the need for the 'tray' field in the disk
private data which was used inconsistently.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 4 Feb 2026 10:35:57 +0000 (11:35 +0100)]
qemu: monitor: Add test validating that 'eventHandlers' are properly sorted
The monitor code uses 'bsearch' to look up the event handler so the
event names must be properly listed. Until now only a comment reminded
us to do it. Add a test to verify that it is actually sorted properly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
projects / thirdparty / libvirt.git / log
