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>
Peter Krempa [Tue, 3 Feb 2026 17:01:15 +0000 (18:01 +0100)]
qemu: Drop 'removable' field from 'qemuDomainDiskInfo'
The only real use was in 'qemuProcessRefreshDiskProps' where it guarded
assignment of 'tray' status. Since qemu doesn't actually report any tray
status for devices which don't have a tray there's no need for the extra
guard.
Remove the field completely.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 3 Feb 2026 16:46:10 +0000 (17:46 +0100)]
qemuMigrationSrcBegin: Drop disk refresh step
Since 'qemuProcessRefreshDiskProps' doesn't remove the source since we
switched to blockdev mode, we don't need to update disk state at the
beginning of migration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 3 Feb 2026 16:41:21 +0000 (17:41 +0100)]
qemuProcessRefreshDiskProps: Drop code to remove disk source
In blockdev mode, the guest OS can't force the drive to become empty
(opening cdrom tray doesn't remove media; floppies can't be ejected from
guest OS), so the check if a drive is empty is dead code at this point.
Remove it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 11 Dec 2025 18:47:16 +0000 (19:47 +0100)]
qemu: Implement support for persistent reservation migration control
The 'migration' attribute for the '<reservations>' element allows to
control the persistent reservation migration feature independently of
the machine type default.
Add the XML plumbing and qemu support.
We consider it ABI for now since it influences qemu migration protocol.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
network: add comment to table that it belongs to libvirt
The result looks like
$ nft list ruleset
...snip...
table ip6 libvirt_network {
comment "Managed by libvirt for virtual networks: https://libvirt.org/firewall.html#the-virtual-network-driver"
chain forward {
...snip...
This should reduce the number of people wondering why
these rules exists.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virDomainInterfaceAddresses() API accepts @source argument,
but since this is hyperv, we can't really use _SRC_LEASE (we
didn't spawn any dnsmasq there), not _SRC_ARP. The only source
that's more or less usable is _SRC_AGENT. Okay, there's no QEMU
guest agent running, but hyperv has its own guest agent. In my
testing (with Linux guest) I had to install 'hyperv' package and
then enable 'hv_kvp_daemon.service'. After that,
Msvm_GuestNetworkAdapterConfiguration struct [1] contained guest
IP addresses.
There's one caveat though: the interface name
(virDomainInterface::name). We don't fetch that one even for
hypervDomainGetXMLDesc() case. And there's no <target dev=''/>
either nor device alias (v12.0.0-43-g4009126f17). So just put
InstanceID there for now, which is this long path, with some
UUIDs, e.g.:
When constructing a domain definition, NICs are fetched from WMI
and their MAC addresses are then parsed. Move this code into a
separate function so that it can be reused later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The aim of this helper is to convert subnet mask to prefix. For
instance for input "255.0.0.0" to return 8. Additionally, if the
input string is already a prefix (with optional leading slash
character) just return that number parsed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
datatypes: Declare autofree func for virDomainInterface type
The virDomainInterface type (struct _virDomainInterface) is
defined in our public header and even has a public free function
(virDomainInterfaceFree()). But in our code we will want to use
automatic memory freeing for it. Hence, make appropriate
declaration in datatypes.h.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Dion Bosschieter [Tue, 10 Feb 2026 10:16:26 +0000 (11:16 +0100)]
nwfilter: move shared nwfilter driver functions into nwfilter_tech_driver.c
Introduce nwfilter_tech_driver.c which holds shared non driver specific
methods.
The following logic can be reused by new nwfilter drivers, which are not
ebiptables specific:
- data type print logic, used for constructing ascii cli arguments out
of nwfilter data;
- chain jump proto type l3_proto_idx logic;
- virNWFilterRule sorting.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
[DB: moved virstring.h include to source file & added to POTFILES] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Dion Bosschieter [Thu, 12 Feb 2026 12:17:49 +0000 (12:17 +0000)]
nwfilter: remove redundant sys/utsname.h include
There are no calls to uname() in the ebiptables driver code.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
[DB: split from larger patch] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Dion Bosschieter [Tue, 10 Feb 2026 10:16:25 +0000 (11:16 +0100)]
nwfilter: rename generic names to virNWFilter* and CamelCase
Rename generic nwfilter data types and functions to virNWFilter prefix
and convert them to CamelCase. These data types and functions are quite
common to any nwfilter driver implementation. Prior to moving them out
of the nwfilter_ebiptables_driver.c file, we'll first rename them.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
Adds documentation for the new USB bus/port addressing.
The new "port" attribute is explained.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/513
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
tests: validate an XML config with USB bus/port set
USB bus/port addressing is translated into a bus/device addressing
at startup using the hostdev logic. This test covers XML parsing
and CLI formatting for bus/port addressing.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
This patch implements USB bus/port matching in the XML schema.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
[DB: split host USB search parts out into previous patches] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
util: implement support for finding host USB devices by port
Extend the API for finding host USB devices, to allow requesting
a search based on the port.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
[DB: split out of bigger patch] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for adding the ability to find host USB devices based
on their port, by generalizing the APIs for device searching
into one all-purpose API
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
[DB: split out of bigger patch] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
virusb test data: add devpath files for port addressing
This patch adds devpath files to the virusb test data.
These files are mockups for the USB sysfs files that
contain the port of a USB device in dotted notation.
They are used for testing of USB bus/port matching.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
Since commit 99a637a8 in qemu 10.0, the way the cmp_legacy flag is
reported changed. The same way as happend with the 'ht' flag in commit c6bd2dd634208, which was fixed in libvirt since commit ba16113c.
This causes migrations from a hypervisor running a qemu version before
that commit to a hypervisor running qemu after that commit fails
with the following error:
guest CPU doesn't match specification: extra features: cmp_legacy
We can just ignore this flag, just like we did with the 'ht' flag.
The aim of cmdDomIfAddr() is to obtain IP addresses for given
domain and then print (ifName, MAC, type, IP Address) tuple.
Preferably in an aligned table. This is hard to do with printf
style of spacing ("%-NNs") since the interface name (ifName) can
vary a lot in length. Fortunately, we have vshTable which is
designed to handle this case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 21 Jan 2026 12:00:39 +0000 (13:00 +0100)]
qemu_command: Generate granule prop for virtio-iommu
Resolves: https://issues.redhat.com/browse/RHEL-76269 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 21 Jan 2026 11:54:17 +0000 (12:54 +0100)]
qemu_validate: Check whether granule of virtio-iommu is supported
Just like with other features, check whether QEMU supports them
based on capabilities. Now, instead of inventing a new QEMU
capability, an existing one can be used:
QEMU_CAPS_VIRTIO_IOMMU_AW_BITS.
This is because the aw-bits and granule attributes were
introduced into QEMU in close succession (v9.0.0-rc0~9^2~7
v9.0.0-rc0~9^2~11), neither can be disabled at compile time and
backporting just one without the other makes almost no sense.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 21 Jan 2026 11:51:20 +0000 (12:51 +0100)]
conf: Introduce granule attribute for virtio-iommu
In PCI assignment scenario the virtio-iommu needs to know the
guest page size also known as granule. Expose it as an attribute
to the <driver/> element of a virtio-iommu.
This is possibly interesting only for aarch64 since it supports
virtio-iommu and also supports running guests with different page
size than the host.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 21 Jan 2026 11:56:06 +0000 (12:56 +0100)]
qemu_command: Generate aw_bits prop for virtio-iommu
Resolves: https://issues.redhat.com/browse/RHEL-76269 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 21 Jan 2026 09:46:43 +0000 (10:46 +0100)]
conf: Allow aw_bits for virtio-iommu
Introduced in QEMU commit of v9.0.0-rc0~9^2~7 the virtio-iommu
device is also capable of using different addres width. The
corresponding attribute is also called 'aw-bits', just like in
case of intel-iommu. Wire up the missing pieces.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Fri, 23 Jan 2026 09:09:15 +0000 (10:09 +0100)]
conf: Teach virDomainParseMemory() new retval
So far, virDomainParseMemory() returns either 0 or -1. While this
allows callers to distinguish a success case from an error it
doesn't allow them to differentiate the case when no value was
provided in the XML, thus nothing was parsed and nothing was
required. Therefore, make virDomainParseMemory() return 1 on
success, 0 in case nothing was parsed and nothing was required,
and -1 on failure.
Arguably, no caller needs this distinction currently, but that is
about to change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
hyperv: Avoid memleak in hypervDomainDefParsePhysicalDisk
When parsing a physical disk, the @hostResouce is escaped once
with the retval being stored into @hostEscaped. Then, it's
escaped again, but the retval is stored into the very same
variable, leading to a leak where intermediate value is lost.
256 bytes in 1 blocks are definitely lost in loss record 469 of 483
at 0x49543A0: realloc (vg_replace_malloc.c:1804)
by 0x516C251: g_realloc (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x518BB7E: g_string_expand (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x518BFF9: g_string_insert_len (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x4A58B5F: g_string_append_len_inline (gstring.h:247)
by 0x4A58B5F: virBufferAdd (virbuffer.c:164)
by 0x4AFDA71: virStringReplace (virstring.c:708)
by 0x4DA4381: hypervDomainDefParsePhysicalDisk (hyperv_driver.c:1375)
by 0x4DA4A18: hypervDomainDefParseStorage (hyperv_driver.c:1487)
by 0x4DA9E31: hypervDomainGetXMLDesc (hyperv_driver.c:2761)
by 0x4DFB3E5: virDomainGetXMLDesc (libvirt-domain.c:2898)
by 0x406D39B: cmdDumpXML (virsh-domain.c:10787)
by 0x40B13B1: vshCommandRun (vsh.c:1383)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Libvirt vpx:// and esx:// URIs are quite obscure. In particular it is
very difficult to construct a correct path to a VMware resource.
Basically you are iterating over VMware structures blindly with no way
to know what your choices are at each level in the path.
This commit doesn't directly address this. It's still difficult. But
at least let's add the true path choices to the debug output so
someone could in theory use 'LIBVIRT_DEBUG=1' to find out what
possible choices exist at a path level.
For example this command fails because the label (which looks like an
IPv6 address, but is really a label) should use "::" instead of ":0:":
2026-02-05 10:58:25.421+0000: 1528876: debug : esxVI_LookupManagedObjectHelper:4956 : comparing path element 'aaaa:52:0:49e0:2eea:7fff:fee6:eca0' with candidate name 'aaaa:52::49e0:2eea:7fff:fee6:eca0'
2026-02-05 10:58:25.421+0000: 1528876: error : esxVI_Context_LookupManagedObjectsByPath:1098 : internal error: Could not find compute resource specified in '/data/aaaa:52:0:49e0:2eea:7fff:fee6:eca0/'
In an ideal world we should improve the error message to show the
possible choices, but the way the code is structured makes that
prohibitive.
Related: https://issues.redhat.com/browse/RHEL-145080 Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Driver capabilities are allocated at the beginning of mymain(),
but roughly in the middle the architecture is switched to aarch64
and capabilities are constructed again. Without freeing the old
ones.
704 (288 direct, 416 indirect) bytes in 1 blocks are definitely lost in loss record 328 of 332
at 0x4885098: calloc (vg_replace_malloc.c:1682)
by 0x4EE35CA: g_malloc0 (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x53314B8: g_type_create_instance (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x531A263: ??? (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x531975E: g_object_new (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x4AA9AB6: virObjectNew (virobject.c:252)
by 0x4AF0BBA: virCapabilitiesNew (capabilities.c:87)
by 0x401797B: virBhyveCapsBuild (bhyve_capabilities.c:51)
by 0x4012F57: mymain (bhyvexml2xmltest.c:60)
by 0x4016872: virTestMain (testutils.c:913)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
The firmwareDir member of driver config is set at the beginning
of mymain(). But then, roughly in the middle of test cases it is
overwritten to fakefirmwareemptydir. But this means the old value
must be freed. Or reassigned back to its original variable which
is freed automatically.
16 bytes in 1 blocks are definitely lost in loss record 190 of 505
at 0x4883224: malloc (vg_replace_malloc.c:451)
by 0x4EE6562: g_malloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F0100F: g_strdup (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4013E26: g_strdup_inline (gstrfuncs.h:321)
by 0x4013E26: mymain (bhyvexml2argvtest.c:151)
by 0x40189A2: virTestMain (testutils.c:913)
by 0x4013DE6: main (bhyvexml2argvtest.c:354)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
bhyvexml2argvtest: Don't leak parts of driver config
At the beginning of mymain() the virBhyveDriverConfigNew() is
called which inits driver config with some paths. These are
then overwritten to produce stable test output. Well, the old
ones should be freed first.
128 bytes in 1 blocks are definitely lost in loss record 453 of 508
at 0x4883224: malloc (vg_replace_malloc.c:451)
by 0x506BD16: vasprintf_l (in /lib/libc.so.7)
by 0x4F39073: g_vasprintf (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F01288: g_strdup_printf (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x401F75B: virBhyveDriverConfigNew (bhyve_conf.c:62)
by 0x4013FAA: mymain (bhyvexml2argvtest.c:164)
by 0x4018892: virTestMain (testutils.c:913)
by 0x4013DC6: main (bhyvexml2argvtest.c:352)
25 bytes in 1 blocks are definitely lost in loss record 206 of 508
at 0x4883224: malloc (vg_replace_malloc.c:451)
by 0x4EE6562: g_malloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F0100F: g_strdup (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x401F715: g_strdup_inline (gstrfuncs.h:321)
by 0x401F715: virBhyveDriverConfigNew (bhyve_conf.c:60)
by 0x4013FAA: mymain (bhyvexml2argvtest.c:164)
by 0x4018892: virTestMain (testutils.c:913)
by 0x4013DC6: main (bhyvexml2argvtest.c:352)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
projects / thirdparty / libvirt.git / log
