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>
This test case demonstrates that it's possible to associate a
custom NVRAM template to a well-known firmware binary, specifying
its format, and libvirt will behave correctly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Wed, 26 Nov 2025 17:18:06 +0000 (18:18 +0100)]
schemas: Allow templateFormat without template path
Similarly to how we allow the format for the loader and the NVRAM
file to be specified without the corresponding path being present,
we should allow that to happen for the NVRAM template too.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Mon, 24 Nov 2025 16:57:25 +0000 (17:57 +0100)]
qemu_firmware: Drop fallback for absent nvramTemplateFormat
If this information is missing, the parsing code will consider
the firmware descriptor to be invalid and matching against it will
not even be attempted. So we can safely drop this redundant
fallback.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Wed, 26 Nov 2025 18:01:12 +0000 (19:01 +0100)]
qemu_firmware: Ignore stateless/combined when NVRAM is configured
For combined firmware builds, the variable storage is part of the
same image as the executable code, whereas stateless builds don't
support variable storage at all.
In both cases, the use of a separate NVRAM storage area is not
supported, so if attributes connected to one are present in the
domain XML, firmware descriptors for stateless/combined builds
should be ignored.
ROM firmware builds are stateless by definition, so the same
handling applies to them as well.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates a flaw in the XML validation process.
Read/write firmware images already contain an area dedicated to
variable storage, which they use, so attempting to use a separate
NVRAM file together with them should have resulted in the domain
XML being rejected.
The issue will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Thu, 27 Nov 2025 18:05:17 +0000 (19:05 +0100)]
qemu_firmware: Move copying of nvram.format to loader.format
As explained in the comment that comes along with it, this code
ensures that the user's preference is taken into account when
nvram.format is the only information that's provided. Currently
it lives in the parser, but it makes more sense for it to be
together with the rest of the firmware selection code instead.
Note that this move is not completely seamless: once the code
is moved outside of the parser, it can no longer reliably know
whether the <loader> element actually existed in the domain
XML. The difference is subtle enough that the test suite is
completely unaffected, and we are going to rework the handling
of this scenario in a way that restores the original behavior
later anyway, so it ultimately doesn't matter.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Thu, 27 Nov 2025 17:25:07 +0000 (18:25 +0100)]
qemu_firmware: Move format=raw compat exception
We currently apply this exception, which is critical to ensure
that the correct firmware is selected when working with older VMs,
in the postparse callback.
Move it to the firmware selection process instead, where it should
have been added in the first place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Sun, 28 Dec 2025 17:31:38 +0000 (18:31 +0100)]
qemu_firmware: Drop 'nvram' local variable
We access the NVRAM information via the 'loader' local variable
throughout the file, and this is the only spot where the 'nvram'
local variable exists. It makes things inconsistent and opens up
the possibility of the values for 'loader' and 'nvram' going out
of sync, especially after a future commit will introduce the
need to set the former. Just get rid of the additional variable.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Thu, 27 Nov 2025 19:14:46 +0000 (20:14 +0100)]
qemu_firmware: Drop support for kernel descriptors
I have been able to find exactly zero evidence of this type of
firmware descriptor actually existing in the wild, so this is
essentialy dead code. Dropping it simplifies the task of further
tweaking the firmware selection code.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'rdseed' CPU features stopped to be presented after updating my host
despite building the same qemu. Re-generate the dump separately from the
update to shield out this difference.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Per our coding style, function shall be separated by either a
single line or two lines. But in esx_util.c functions are
separated by three or even four blank lines. Drop excessive
spacing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
While discouraged by a KB article to use special characters in
inventory object names [1], ESX won't stop you. And thus users
can end up with a datastore named "datastore2+", for instance.
The datastore name (and datacenter path) are important when
fetching/uploading a .vmx file (used in APIs like
virDomainGetXMLDesc() or virDomainDefineXML()). And while we do
URI encode both (dcPath and dsName), encoding them once is not
enough. Cole Robinson discovered [2] that they need to be
URI-encoded twice. Use newly introduced
esxUtil_EscapeInventoryObject() helper to encode them twice.
1: https://knowledge.broadcom.com/external/article/386368/vcenter-inventory-object-name-with-speci.html
2: https://issues.redhat.com/browse/RHEL-133729#comment-28604072
Resolves: https://issues.redhat.com/browse/RHEL-134127 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
The aim of this helper function is to URI-encode given string
twice. There's a bug (fixed in next commit) in which we're unable
to fetch .vmx file for a domain if corresponding datastore
contains some special characters (like +). Cole Robinson
discovered that encoding datastore twice enables libvirt to work
around the issue [2]. Well, this function does exactly that.
It was tested with the following inputs and all worked
flawlessly: "datastore", "datastore2", "datastore2+",
"datastore3+-@", "data store2+".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Thomas Prescher [Wed, 7 Jan 2026 14:38:37 +0000 (15:38 +0100)]
qemu: fix locking in qemuProcessHandleMemoryFailure
Fix locking in qemuProcessHandleMemoryFailure. We use a lock guard
now because we can directly return from the default switch cases.
Issue has been discovered by johannes.kulik@sap.com
On-behalf-of: SAP thomas.prescher@sap.com Signed-off-by: Thomas Prescher <thomas.prescher@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This was triggered in my experiments with the `virsh net-*` command
family.
On-behalf-of: SAP philipp.schuster@sap.com Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, guest capabilities have VIR_ARCH_X86_64 hard-coded
for supported guest. As bhyve supports amd64 and arm64 hosts,
and guests' arch must match host's arch, reporting VIR_ARCH_X86_64
for arm64 is wrong.
Set supported guest arch to the same value as the host arch.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
qemu: snapshot: Check earlier if memory snapshot is possible
Don't unnecessarily pause the VM if the snapshot can't be taken.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu: snapshot: Don't overwrite 'ret' in qemuSnapshotCreateActiveExternal
Both qemuSaveImageCreate and qemuSnapshotCreateActiveExternalDisks
follow the usual convention of returning 0 on success and -1 on error so
there's no need store the values in 'ret'.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Where /dev/cam/ctl is a ctl(4) device path.
The optional "scsi-device-options" include "iid" (Initiator ID)
and "bootindex", which are currently not used by libvirt.
CTL stands for CAM Target Layer, and CAM stands for
Common Access Method Storage subsystem, and is available
on FreeBSD.
Quoting the ctl(4) manual page:
The ctl subsystem provides SCSI target devices emulation. It supports
features such as:
• Disk, CD-ROM and processor device emulation
• Tagged queueing
• SCSI task attribute support (ordered, head of queue, simple tags)
• SCSI implicit command ordering support
• Full task management support (abort, query, reset, etc.)
• Support for multiple ports, initiators, targets and backing stores
• Support for VMWare VAAI and Microsoft ODX offload (COMPARE AND WRITE,
XCOPY, POPULATE TOKEN/WRITE USING TOKEN, WRITE SAME and UNMAP)
• Persistent reservation support
• Extensive VPD/mode/log pages support
• Featured error reporting, error injection and basic SMART support
• High Availability clustering support with ALUA
• All I/O handled in-kernel, no userland context switch overhead
This is a preparation for implementing virtio-scsi support for the bhyve
driver.
Co-authored-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
qemu_validate: Drop VIR_DOMAIN_HYPERV_STIMER dependency on VIR_DOMAIN_HYPERV_VPINDEX
The original commit (v11.9.0-rc1~84) added a dependency checking
of VIR_DOMAIN_HYPERV_STIMER on VIR_DOMAIN_HYPERV_VPINDEX
(meaning, if stimer is on then vpindex must also be on). It
justified this by citing QEMU documentation:
Per QEMU documentation (docs/system/i386/hyperv.rst):
While the documentation is almost correct (see previous commit
when it's incorrect), the code express no dependency on vpindex
(kvm_hyperv_properties[] array from target/i386/kvm/kvm.c):
If transitivity is taken into account then the documentation is
of course correct (minus that one aforementioned special case).
Well, there's no need for us to implement transitional checks.
VIR_DOMAIN_HYPERV_STIMER requires VIR_DOMAIN_HYPERV_SYNIC and
whether that requires VIR_DOMAIN_HYPERV_VPINDEX is another
question.
Just drop the transitive check.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/837
Resolves: https://issues.redhat.com/browse/RHEL-138689 Fixes: da261327ea94300d1aa2d3b76ba9dcd4de6160f6 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
qemu_validate: Drop VIR_DOMAIN_HYPERV_SYNIC dependency on VIR_DOMAIN_HYPERV_VPINDEX
Turns out, that synic hyperv enlightenment not always requires
vpindex. Some (older) machine types (e.g. pc-i440fx-3.0,
pc-q35-3.0, pc-i440fx-rhel7.6.0) can run with synic enabled and vpindex
disabled. This is because they did enable 'x-hv-synic-kvm-only'
CPU property, but starting from QEMU commit v3.1.0-rc0~44^2~9 the
property is disabled by default.
To avoid parsing machine type version, let's just drop this
dependency validation and rely on QEMU to report sensible error
message.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/837
Resolves: https://issues.redhat.com/browse/RHEL-138689 Fixes: 1822d030c32d9857020ee8385b0a8808a29a472f Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Antonio Terceiro [Mon, 22 Dec 2025 17:46:33 +0000 (14:46 -0300)]
libvirt-guests.service: use Type=exec
Type=oneshot means that the service is only considered started after the
main process exits. In setups where libvirt-guests is configured to be
used and imposes a delay on the startup of guests, this will cause
systemd to report a quite high boot time as it will wait until all
guests have booted, plus all the delay between them. High boot times are
often reported as issues in monitoring systems, and require operator
attention, while in this case there is not really an issue with the
system, it's just doing what it was configured to do.
With Type=exec, the service is considered started right after the main
process is *started*, but the boot process will not wait for it.
Having other units depend on libvirt-guests.service finishing was
already not reliable because one cannot know how long the OS inside each
guest takes to boot, and libvirt-guests already does not wait for them
to be in any particular state.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Antonio Terceiro <terceiro@debian.org>
tools: check for failure decoding secret base64 value
The g_base64_decode function will return a valid pointer, but with
length of zero when it fails to decode data. Report an error in that
scenario, so avoid a later more obsecure error.
eg old behaviour
# virsh secret-set-value f52a81b2-424e-490c-823d-6bd4235bc507 foo
warning: Passing secret value as command-line argument is insecure!
error: Failed to set secret value
error: value in virSecretSetValue must not be NULL
new behaviour
# /home/berrange/virsh secret-set-value f52a81b2-424e-490c-823d-6bd4235bc507 foo
warning: Passing secret value as command-line argument is insecure!
error: Secret value is not valid base64
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The UUID had only 11 characters in the last component, instead of the
required 12. Add the missing trailing '2' which is present in all the
other matching example UUIDs.
Reviewed-by: Arun Menon <armenon@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Mon, 5 Jan 2026 14:00:18 +0000 (15:00 +0100)]
virjsontest: Add test for nesting depth
Add an example of 250 layer deep nested JSON to make sure the parser
supports it. This is in order to maintain compatibility with external
snapshots in qemu, where such a deeply nested document is returned with
a 'query-block' QMP call.
I've used a fake JSON as a real reply from qemu is around 1.4MiB for a
200 deep image chain.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 11 Dec 2025 08:39:03 +0000 (09:39 +0100)]
util: json: Increase JSON nesting limit when parsing to 300
The default in json-c is 32 which is too low to accomodate the 200
snapshot layers we supported historically in the qemu driver (200 is
picked based on the 256 layer limit in libxml).
The response to 'query-block' is otherwise too low and we fail to start
the VM when there's around 26 images in a backing chain.
'json_tokener_new_ex' is supported since json-c 0.11 and we require at
least 0.14.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, to probe PCI devices, for each device libvirt
calls "bhyve -s 0,<device_type>" and parses the error message to check
if this specific device is supported.
For quite some time, bhyve reports the list of devices using:
bhyve -s help
where it prints all supported devices, one device per line.
Update the code to use this command:
* It is more accurate as we don't need to rely on the error message
parsing.
* It's faster as we get all the devices in one run instead of
running bhyve for every device type.
* The code is simpler.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This partially reverts commit 3caa28dc50df which changed the DST times
to start at Jan 2 due to an issue that is already solved in GLib that we
require for almost a year now.
This also fixes the test failures that would go away on Jan 2 11:00
UTC (less than two hours from writing this commit message) due to the
timezone definitions (the last failing test case has a timezone which is
UTC+11:00), but because of the change from '0/' to '1/' it did occur on
a day which is not caught by isNearYearEnd() which exists solely for
this purpose.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Thu, 18 Dec 2025 08:59:31 +0000 (09:59 +0100)]
network: Propagate DNS forwarder port into dnsmasq config
If a DNS forwarder has port specified then we ought to format it
into dnsmasq config. The correct syntax is
server=/domain/ip-address#port
Closes: https://gitlab.com/libvirt/libvirt/-/issues/833 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
Michal Privoznik [Wed, 17 Dec 2025 08:35:40 +0000 (09:35 +0100)]
network: Introduce port for DNS forwarder
In the <dns/> section of network configuration users can set up
forwarding of DNS requests to custom DNS servers. These are
specified using 'addr' attribute. But configuring port wasn't
possible, until now. New 'port' attribute is introduced, which
allows overriding the default DNS port for given address.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
Bhyve supports SLIRP networking using the following syntax:
-s 12:0,e1000,slirp,mac=<macaddr>,open
Where "e1000" is a NIC model, "slirp" is the SLIRP backend and "open"
specifies open mode where external network is available to the guest.
The "open" mode is a recent addition in FreeBSD -CURRENT.
Unfortunately, bhyve does not provide a way to probe whether
the open mode is supported, so users will have to make sure
it's supported on their own.
For the reference, without the "open" mode, the guest will have no
outside network connectivity. To make this mode useful,
it is possible to configure forwarding from the host to the guest,
but it is not covered by this patch.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
Jiri Denemark [Fri, 5 Dec 2025 15:52:32 +0000 (16:52 +0100)]
util: Rework virFileIsSharedFSOverride using virFileCheckParents
The newly introduced virFileCheckParents is generic enough to be used
for checking whether a specific path or any of its parents is included
in the overrides array.
Jiri Denemark [Fri, 5 Dec 2025 15:51:25 +0000 (16:51 +0100)]
util: Fix race condition in virFileIsSharedFSOverride
Switch virFileIsSharedFSOverride to use virFileCheckParents to avoid a
race which could result in virFileCanonicalizePath to be called on a
path that does not exist anymore.
projects / thirdparty / libvirt.git / log
