- Devel - libvirt List Archives

[PATCH] NEWS: document new bhyve features for 12.3.0
by Roman Bogorodskiy 27 Apr '26

27 Apr '26

Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- NEWS.rst | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 478cc6e925..ce9ada942d 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -17,6 +17,27 @@ v12.3.0 (unreleased) * **New features** + * bhyve: Add blkiotune support + + The bhyve driver now supports guest I/O throttling configuration:: + + <blkiotune> + <device> + <path>*</path> + <read_iops_sec>20000</read_iops_sec> + <write_iops_sec>20000</write_iops_sec> + <read_bytes_sec>10000</read_bytes_sec> + <write_bytes_sec>10000</write_bytes_sec> + </device> + </blkiotune> + + It uses the ``rctl(4)`` framework to apply these limits. + + * bhyve: Implement ``virDomainInterfaceAddresses()`` and ``virDomainGetHostname()`` + + The bhyve driver now implements the ``virDomainInterfaceAddresses()`` API (``virsh domifaddr``) + and the ``virDomainGetHostname()`` API (``virsh domhostname``). + * **Improvements** * **Bug fixes** -- 2.52.0

2 1

[PATCH] bhyve: fix virBhyveProcessStop()
by Roman Bogorodskiy 24 Apr '26

24 Apr '26

Currently, there are two (at least) issues in virBhyveProcessStop(). Before going into details, a quick overview of the bhyve shutdown process. It is a two stage process*: first, the main bhyve process gets destroyed (either via an external command or within the guest), then the resources need to be cleaned up using the bhyvectl(8) tool. The first issue is that if virCommandRun() for bhyvectl(8) fails, virBhyveProcessStop() jumps to the 'cleanup' label and misses cleaning of some resources. The second issue is more serious. Currently, monitor is closed only after running of the bhyvectl(8) command. That means that the monitor could catch the domain destroy event and try to run virBhyveProcessStop() on the same domain again, resulting in trying to release already released resources, such as the monitor itself. Address by: * Making virCommandRun() on bhyvectl(8) non-critical. Even if it fails, we try to clean up all resources. We consider the function failed (return value 1) though. * Close monitor before running bhyvectl(8) Additionally, do not verify that virBhyveProcessBuildDestroyCmd() returns non-NULL, there could be only allocation errors. Reported-by: Peter Krempa <pkrempa(a)redhat.com> Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/bhyve/bhyve_process.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/src/bhyve/bhyve_process.c b/src/bhyve/bhyve_process.c index 26320200c5..842ff0d6fc 100644 --- a/src/bhyve/bhyve_process.c +++ b/src/bhyve/bhyve_process.c @@ -515,7 +515,7 @@ virBhyveProcessStop(struct _bhyveConn *driver, virDomainObj *vm, virDomainShutoffReason reason) { - int ret = -1; + int ret = 0; g_autoptr(virCommand) cmd = NULL; bhyveDomainObjPrivate *priv = vm->privateData; @@ -531,15 +531,19 @@ virBhyveProcessStop(struct _bhyveConn *driver, return -1; } - if (!(cmd = virBhyveProcessBuildDestroyCmd(driver, vm->def))) - return -1; - - if (virCommandRun(cmd, NULL) < 0) - goto cleanup; - + /* Destroy monitor before running the actual destroy command to prevent + * it from detecting VM shutdown and entering this cleanup routine again */ if ((priv != NULL) && (priv->mon != NULL)) bhyveMonitorClose(priv->mon); + cmd = virBhyveProcessBuildDestroyCmd(driver, vm->def); + if (virCommandRun(cmd, NULL) < 0) { + /* Only failure of the actual destroy command warrants unsuccessful return code, + * other failures are not considered critical */ + ret = -1; + VIR_WARN("Failed to run the domain destroy command"); + } + bhyveProcessStopHook(driver, vm, VIR_HOOK_BHYVE_OP_STOPPED); /* Cleanup network interfaces */ @@ -554,8 +558,6 @@ virBhyveProcessStop(struct _bhyveConn *driver, } } - ret = 0; - virCloseCallbacksDomainRemove(vm, NULL, bhyveProcessAutoDestroy); virDomainObjSetState(vm, VIR_DOMAIN_SHUTOFF, reason); @@ -563,8 +565,6 @@ virBhyveProcessStop(struct _bhyveConn *driver, vm->def->id = -1; bhyveProcessStopHook(driver, vm, VIR_HOOK_BHYVE_OP_RELEASE); - - cleanup: virPidFileDelete(BHYVE_STATE_DIR, vm->def->name); bhyveProcessRemoveDomainStatus(BHYVE_STATE_DIR, vm->def->name); -- 2.52.0

2 2

[PATCH 0/4] Implement freezer for CGroupsV2
by Michal Privoznik 24 Apr '26

24 Apr '26

*** BLURB HERE *** Michal Prívozník (4): src: Introduce virCgroupFreezerState enum vircgroupv2: Freezer controller is implicit vircgroupv2: Implement freezer controller virt-host-validate: Suggest different resolution for 'devices' and non-root user src/lxc/lxc_driver.c | 15 +++-- src/lxc/lxc_process.c | 3 +- src/util/vircgroup.c | 10 ++-- src/util/vircgroup.h | 12 +++- src/util/vircgroupbackend.h | 4 +- src/util/vircgroupv1.c | 38 +++++++++++-- src/util/vircgroupv2.c | 92 +++++++++++++++++++++++++++++++ tests/vircgroupdata/hybrid.parsed | 2 +- tests/vircgrouptest.c | 5 +- tools/virt-host-validate-common.c | 14 ++++- 10 files changed, 168 insertions(+), 27 deletions(-) -- 2.53.0

2 6

[PATCH] util: Allow for PCI root buses not numbered "0"
by Laine Stump 24 Apr '26

24 Apr '26

From: ehanoc via Devel <devel(a)lists.libvirt.org> virPCIDeviceReset() and virPCIDeviceIsBehindSwitchLackingACS() both used a hardcoded check for bus != 0 to determine if a device is attached directly to a "root bus". This breaks on systems with more than one root bus, where at least one of the buses is necessarily not 0! (for example Intel Arrow Lake based systems where the CPU's root complex is bus 0x00 and the PCH root complex is bus 0x80). Update both functions to use virPCIDeviceIsOnRootBus(), which detects root bus attachment via the canonicalized sysfs device link in /sys/devices/*, making it work correctly for all root buses, not just those numbered 0. Discussion of the issue here: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/NE62… Resolves: https://github.com/QubesOS/qubes-issues/issues/10393 Signed-off-by: Bruno Martins <ehanoc(a)protonmail.com> Signed-off-by: Laine Stump <laine(a)redhat.com> Reviewed-by: Laine Stump <laine(a)redhat.com> Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Changes from V1: * Editorial changes to comments in code and commit log message * log an error when virPCIDeviceIsOnRootBus() fails * use g_path_get_basename() rather than strrchr(blah, '/') * rename a couple variables I haven't been able to test these changes because I only have QEMU/KVM, and it doesn't call any of this code. Please test and add your Reviewed-by (of my changes) and Tested-by: and I'll push it. src/util/virpci.c | 106 +++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 100 insertions(+), 6 deletions(-) diff --git a/src/util/virpci.c b/src/util/virpci.c index d43fa1ef54..642717d23c 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -1080,6 +1080,87 @@ virPCIDeviceInit(virPCIDevice *dev, int cfgfd) return 0; } +/* + * Check if a PCI device is directly attached to a root bus (no parent bridge). + * + * A PCIe topology can have multiple root buses (a "root" bus is any + * PCI bus that doesn't have yet another higher level PCI bus as its + * parent), so by definition we can't detect a root bus by just + * looking for bus 0. Instead, we can detect if a bus is attached to a + * root bus by examining the *canonical* path of the device's + * directory in sysfs: a device is connected directly to a root bus if + * its canonicalized sysfs path is a direct child of a + * /sys/devices/pciXXXX:YY directory. For example, this device: + * + * /sys/bus/pci/devices/0000:00:14.0 (path in "flat" sysfs pci namespace) + * /sys/devices/pci0000:80/0000:80:14.0). (canonicalized version of above) + + * is connnected to a root bus. Conversely, if the given device's + * canonial path has yet another PCI device as its parent in the + * sys/device's hierarchy, then it *isn't* attached to a root bus, + * e.g.: + * + * /sys/bus/pci/devices/0000:04:00.1 (link in "flat" namespace) + * /sys/devices/pci0000:00/0000:00:1c.4/0000:04:00.0 (canonicalized) + * + * Returns 1 if the given device is directly attached to a root bus, + * 0 if not, -1 on error. + */ +static int +virPCIDeviceIsOnRootBus(virPCIDevice *dev) +{ + unsigned int domain, bus; + g_autofree char *devPath = NULL; + g_autofree char *canonicalPath = NULL; + g_autofree char *parentPath = NULL; + g_autofree char *parentName = NULL; + + /* Get the sysfs symlink path for this device */ + devPath = g_strdup_printf(PCI_SYSFS "devices/%s", dev->name); + + /* Resolve the symlink to get the real path in /sys/devices/... */ + if (virFileResolveLink(devPath, &canonicalPath) < 0) { + virReportSystemError(errno, _("failed to resolve links in PCI device %1$s sysfs path '%2$s'"), + dev->name, devPath); + return -1; + } + + /* get just the final component of the parent directory */ + parentPath = g_path_get_dirname(canonicalPath); + parentName = g_path_get_basename(parentPath); + + /* + * Detect root bus by parsing the parent directory name with sscanf. + * + * PCI root buses in /sys/devices follow the naming convention: + * pci<domain>:<bus> + * + * <domain>: number (0000-ffff, hex) + * <bus>: number within the domain (00-ff, hex) + * + * This format is defined in: + * https://www.kernel.org/doc/html/latest/PCI/sysfs-pci.html + * + * Examples from Intel Arrow Lake systems: + * - pci0000:00 (CPU root bus) + * - pci0000:80 (PCH root bus) + * + * We aren't concerned with the actual values parsed by sscanf, + * only whether or not the parse was successful - if soo, then we + * return 1 indicating this device is attached to a root bus, + * otherwise 0. + */ + if (sscanf(parentName, "pci%x:%x", &domain, &bus) == 2) { + VIR_DEBUG("%s %s: device is on root bus (parent=%s)", + dev->id, dev->name, parentName); + return 1; + } + + VIR_DEBUG("%s %s: device is not on root bus (parent=%s)", + dev->id, dev->name, parentName); + return 0; +} + int virPCIDeviceReset(virPCIDevice *dev, virPCIDeviceList *activeDevs, @@ -1145,9 +1226,18 @@ virPCIDeviceReset(virPCIDevice *dev, if (dev->has_pm_reset) ret = virPCIDeviceTryPowerManagementReset(dev, fd); - /* Bus reset is not an option with the root bus */ - if (ret < 0 && dev->address.bus != 0) - ret = virPCIDeviceTrySecondaryBusReset(dev, fd, inactiveDevs); + /* If power management reset isn't available (or if it failed), + * and the bus we're attached to isn't a root bus, try a secondary + * bus reset. (This is not an option if we are attached directly + * to a root bus). + */ + if (ret < 0) { + int onRootBus = virPCIDeviceIsOnRootBus(dev); + if (onRootBus < 0) + goto cleanup; + if (!onRootBus) + ret = virPCIDeviceTrySecondaryBusReset(dev, fd, inactiveDevs); + } if (ret < 0) { virErrorPtr err = virGetLastError(); @@ -2531,15 +2621,19 @@ static int virPCIDeviceIsBehindSwitchLackingACS(virPCIDevice *dev) { g_autoptr(virPCIDevice) parent = NULL; + int onRootBus; if (virPCIDeviceGetParent(dev, &parent) < 0) return -1; if (!parent) { - /* if we have no parent, and this is the root bus, ACS doesn't come - * into play since devices on the root bus can't P2P without going + /* if we have no parent, and this is a root bus, ACS doesn't come + * into play since devices on root buses can't P2P without going * through the root IOMMU. */ - if (dev->address.bus == 0) { + onRootBus = virPCIDeviceIsOnRootBus(dev); + if (onRootBus < 0) + return -1; + if (onRootBus) { return 0; } else { virReportError(VIR_ERR_INTERNAL_ERROR, -- 2.53.0

4 9

[PATCH] vmx: Add support for NVRAM configuration
by Surya Gupta 24 Apr '26

24 Apr '26

Some VMware guests specify NVRAM storage using the 'nvram' parameter. If found, parse it and store it in the domain's os.loader.nvram field, which gets formatted as: <os> <type arch='x86_64'>hvm</type> <nvram>[datastore] directory/dokuwiki.nvram</nvram> </os> The NVRAM path uses the same transformation functions as disk paths (ctx->parseFileName and ctx->formatFileName) to ensure consistent handling of datastore-qualified paths. The NVRAM is stored as a virStorageSource with type VIR_STORAGE_TYPE_FILE to ensure compatibility with libvirt's existing firmware handling infrastructure. Fixes: https://redhat.atlassian.net/browse/RHELMISC-29421 Signed-off-by: Surya Gupta <surygupt(a)redhat.com> --- src/vmx/vmx.c | 32 ++++++++++++++++++++++++ tests/vmx2xmldata/case-insensitive-1.xml | 1 + tests/vmx2xmldata/case-insensitive-2.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-1.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-10.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-11.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-12.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-13.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-14.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-15.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-16.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-17.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-2.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-3.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-4.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-5.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-6.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-7.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-8.xml | 1 + tests/vmx2xmldata/esx-in-the-wild-9.xml | 1 + tests/vmx2xmldata/gsx-in-the-wild-1.xml | 1 + tests/vmx2xmldata/gsx-in-the-wild-2.xml | 1 + tests/vmx2xmldata/gsx-in-the-wild-3.xml | 1 + tests/vmx2xmldata/gsx-in-the-wild-4.xml | 1 + 24 files changed, 55 insertions(+) diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c index 57dfd57cfc..c42b030dd6 100644 --- a/src/vmx/vmx.c +++ b/src/vmx/vmx.c @@ -1415,6 +1415,7 @@ virVMXParseConfig(virVMXContext *ctx, long long coresPerSocket = 0; virCPUDef *cpu = NULL; char *firmware = NULL; + char *nvram = NULL; size_t saved_ndisks = 0; if (ctx->parseFileName == NULL) { @@ -2022,6 +2023,26 @@ virVMXParseConfig(virVMXContext *ctx, VIR_TRISTATE_BOOL_YES; } + /* vmx:nvram */ + if (virVMXGetConfigString(conf, "nvram", &nvram, true) < 0) { + goto cleanup; + } + + if (nvram != NULL) { + g_autoptr(virStorageSource) n = virStorageSourceNew(); + char *tmp = NULL; + + if (!def->os.loader) { + def->os.loader = virDomainLoaderDefNew(); + } + + n->type = VIR_STORAGE_TYPE_FILE; + if (ctx->parseFileName(nvram, ctx->opaque, &tmp, false) < 0) + goto cleanup; + n->path = tmp; + def->os.loader->nvram = g_steal_pointer(&n); + } + if (virDomainDefPostParse(def, VIR_DOMAIN_DEF_PARSE_ABI_UPDATE, xmlopt, NULL) < 0) goto cleanup; @@ -2035,6 +2056,7 @@ virVMXParseConfig(virVMXContext *ctx, VIR_FREE(guestOS); virCPUDefFree(cpu); VIR_FREE(firmware); + VIR_FREE(nvram); if (!success) return NULL; @@ -3738,6 +3760,16 @@ virVMXFormatConfig(virVMXContext *ctx, virDomainXMLOption *xmlopt, virDomainDef if (def->os.firmware == VIR_DOMAIN_OS_DEF_FIRMWARE_EFI) virBufferAddLit(&buffer, "firmware = \"efi\"\n"); + /* vmx:nvram */ + if (def->os.loader && def->os.loader->nvram && def->os.loader->nvram->path) { + g_autofree char *nvramPath = NULL; + + nvramPath = ctx->formatFileName(def->os.loader->nvram->path, ctx->opaque); + if (nvramPath != NULL) { + virBufferAsprintf(&buffer, "nvram = \"%s\"\n", nvramPath); + } + } + if (virtualHW_version >= 7) { if (hasSCSI) { virBufferAddLit(&buffer, "pciBridge0.present = \"true\"\n"); diff --git a/tests/vmx2xmldata/case-insensitive-1.xml b/tests/vmx2xmldata/case-insensitive-1.xml index 7cb6413941..e854cc37cb 100644 --- a/tests/vmx2xmldata/case-insensitive-1.xml +++ b/tests/vmx2xmldata/case-insensitive-1.xml @@ -9,6 +9,7 @@ </cputune> <os> <type arch='i686'>hvm</type> + <nvram>[datastore] directory/FEDORA11.NVRAM</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/case-insensitive-2.xml b/tests/vmx2xmldata/case-insensitive-2.xml index 188c3f3cd5..f5c4446ab5 100644 --- a/tests/vmx2xmldata/case-insensitive-2.xml +++ b/tests/vmx2xmldata/case-insensitive-2.xml @@ -9,6 +9,7 @@ </cputune> <os> <type arch='i686'>hvm</type> + <nvram>[datastore] directory/fedora11.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-1.xml b/tests/vmx2xmldata/esx-in-the-wild-1.xml index c15275ccb9..9ae28c8497 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-1.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-1.xml @@ -9,6 +9,7 @@ </cputune> <os> <type arch='i686'>hvm</type> + <nvram>[datastore] directory/Fedora11.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-10.xml b/tests/vmx2xmldata/esx-in-the-wild-10.xml index 78129682bd..1b1fdf0662 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-10.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-10.xml @@ -10,6 +10,7 @@ </cputune> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/windows2019biosvmware.nvram</nvram> </os> <cpu> <topology sockets='1' dies='1' clusters='1' cores='2' threads='1'/> diff --git a/tests/vmx2xmldata/esx-in-the-wild-11.xml b/tests/vmx2xmldata/esx-in-the-wild-11.xml index 8807a057d7..a0c1e05e90 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-11.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-11.xml @@ -9,6 +9,7 @@ </cputune> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/esx6.7-rhel7.7-x86_64.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-12.xml b/tests/vmx2xmldata/esx-in-the-wild-12.xml index c5aad90677..ac83982b9b 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-12.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-12.xml @@ -13,6 +13,7 @@ <feature enabled='yes' name='enrolled-keys'/> <feature enabled='yes' name='secure-boot'/> </firmware> + <nvram>[datastore] directory/Auto-esx8.0-rhell9.3-efi-with-empty-cdrom.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-13.xml b/tests/vmx2xmldata/esx-in-the-wild-13.xml index e6ef947d50..cef9fd4e48 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-13.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-13.xml @@ -23,6 +23,7 @@ package:20.6.2 </cputune> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/Test-Mig-VM-1 (01ce57d0-4e20-41a5-8b6c-bcbf49a032ec).nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-14.xml b/tests/vmx2xmldata/esx-in-the-wild-14.xml index dd5c2434ee..f10707d1d4 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-14.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-14.xml @@ -7,6 +7,7 @@ <vcpu placement='static'>12</vcpu> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/wild14.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-15.xml b/tests/vmx2xmldata/esx-in-the-wild-15.xml index 77b094e9d5..78d15e1538 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-15.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-15.xml @@ -9,6 +9,7 @@ </cputune> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/dokuwiki.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-16.xml b/tests/vmx2xmldata/esx-in-the-wild-16.xml index 147bc0825a..51746dd77e 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-16.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-16.xml @@ -13,6 +13,7 @@ <feature enabled='yes' name='enrolled-keys'/> <feature enabled='yes' name='secure-boot'/> </firmware> + <nvram>[datastore] directory/Auto-esx8.0-rhel9.4-efi-nvme-disk.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-17.xml b/tests/vmx2xmldata/esx-in-the-wild-17.xml index ae66de7431..725f21bdf6 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-17.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-17.xml @@ -10,6 +10,7 @@ </cputune> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/esx8.0-win11-with-second-disk-in-subfolder.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-2.xml b/tests/vmx2xmldata/esx-in-the-wild-2.xml index 59071b5d3a..59c7087300 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-2.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-2.xml @@ -6,6 +6,7 @@ <vcpu placement='static' cpuset='0-2,5-7'>4</vcpu> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/Debian1.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-3.xml b/tests/vmx2xmldata/esx-in-the-wild-3.xml index cbe8eceb37..29c63d8d6b 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-3.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-3.xml @@ -6,6 +6,7 @@ <vcpu placement='static' cpuset='0,3-5'>2</vcpu> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/Debian2.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-4.xml b/tests/vmx2xmldata/esx-in-the-wild-4.xml index a8a2ac6f97..82eccca1c4 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-4.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-4.xml @@ -9,6 +9,7 @@ </cputune> <os> <type arch='i686'>hvm</type> + <nvram>[datastore] directory/virtMonServ1.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-5.xml b/tests/vmx2xmldata/esx-in-the-wild-5.xml index 9eb975afe9..c88e60bdc0 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-5.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-5.xml @@ -13,6 +13,7 @@ </cputune> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/vmtest.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-6.xml b/tests/vmx2xmldata/esx-in-the-wild-6.xml index 51c74dd8a1..805f033561 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-6.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-6.xml @@ -6,6 +6,7 @@ <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/el6-test.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-7.xml b/tests/vmx2xmldata/esx-in-the-wild-7.xml index c117bd62e5..b641574776 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-7.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-7.xml @@ -6,6 +6,7 @@ <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/esx-rhel6-mini.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/esx-in-the-wild-8.xml b/tests/vmx2xmldata/esx-in-the-wild-8.xml index 47d22ced2a..f13e6f7448 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-8.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-8.xml @@ -9,6 +9,7 @@ </cputune> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/RHEL7_6.nvram</nvram> </os> <cpu> <topology sockets='4' dies='1' clusters='1' cores='2' threads='1'/> diff --git a/tests/vmx2xmldata/esx-in-the-wild-9.xml b/tests/vmx2xmldata/esx-in-the-wild-9.xml index ee6be2527f..6b4d878ab1 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-9.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-9.xml @@ -10,6 +10,7 @@ </cputune> <os> <type arch='x86_64'>hvm</type> + <nvram>[datastore] directory/v2v-windows-kkulkarn.nvram</nvram> </os> <cpu> <topology sockets='4' dies='1' clusters='1' cores='4' threads='1'/> diff --git a/tests/vmx2xmldata/gsx-in-the-wild-1.xml b/tests/vmx2xmldata/gsx-in-the-wild-1.xml index 62ec191c82..f189ff79e4 100644 --- a/tests/vmx2xmldata/gsx-in-the-wild-1.xml +++ b/tests/vmx2xmldata/gsx-in-the-wild-1.xml @@ -6,6 +6,7 @@ <vcpu placement='static'>1</vcpu> <os> <type arch='i686'>hvm</type> + <nvram>[datastore] directory/Debian-System1.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/gsx-in-the-wild-2.xml b/tests/vmx2xmldata/gsx-in-the-wild-2.xml index 906e4657ca..d1c1bf39df 100644 --- a/tests/vmx2xmldata/gsx-in-the-wild-2.xml +++ b/tests/vmx2xmldata/gsx-in-the-wild-2.xml @@ -6,6 +6,7 @@ <vcpu placement='static'>1</vcpu> <os> <type arch='i686'>hvm</type> + <nvram>[datastore] directory/Server2.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/gsx-in-the-wild-3.xml b/tests/vmx2xmldata/gsx-in-the-wild-3.xml index 61812851e1..acc9d6ba5d 100644 --- a/tests/vmx2xmldata/gsx-in-the-wild-3.xml +++ b/tests/vmx2xmldata/gsx-in-the-wild-3.xml @@ -6,6 +6,7 @@ <vcpu placement='static'>1</vcpu> <os> <type arch='i686'>hvm</type> + <nvram>[datastore] directory/Debian-System3.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/vmx2xmldata/gsx-in-the-wild-4.xml b/tests/vmx2xmldata/gsx-in-the-wild-4.xml index a65a7d137f..8c73224846 100644 --- a/tests/vmx2xmldata/gsx-in-the-wild-4.xml +++ b/tests/vmx2xmldata/gsx-in-the-wild-4.xml @@ -6,6 +6,7 @@ <vcpu placement='static'>1</vcpu> <os> <type arch='i686'>hvm</type> + <nvram>[datastore] directory/Debian-System4.nvram</nvram> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> -- 2.53.0

3 3

[PATCH v3 1/1] qemu: fix potential hang in qemuMigrationSrcCancelUnattended during reconnect
by Denis V. Lunev 24 Apr '26

24 Apr '26

When libvirtd reconnects to a running QEMU process that had an in-progress migration, qemuProcessReconnect first connects the monitor and only later recovers the migration job. During this window the async job is VIR_ASYNC_JOB_NONE, so any MIGRATION status events from QEMU are silently dropped by qemuProcessHandleMigrationStatus. If the migration was already cancelled or completed by QEMU during this window, no further events will be emitted. When qemuMigrationSrcCancelUnattended later restores the async job and calls qemuMigrationSrcCancel with wait=true, the wait loop calls qemuDomainObjWait (virCondWait with no timeout) and blocks forever waiting for an event that will never arrive. qemuProcessRecoverMigration already queries QEMU for the current migration state via qemuMigrationAnyRefreshStatus and passes the result to qemuProcessRecoverMigrationOut as migStatus. Plumb that value one level further into qemuMigrationSrcCancelUnattended and, when it indicates the migration has already reached a terminal state (VIR_DOMAIN_JOB_STATUS_CANCELED), skip restoring the async job and the qemuMigrationSrcCancel/virDomainObjEndAsyncJob pair entirely. Signed-off-by: Denis V. Lunev <den(a)openvz.org> Suggested-by: Jiri Denemark <jdenemar(a)redhat.com> CC: Peter Krempa <pkrempa(a)redhat.com> CC: Michal Privoznik <mprivozn(a)redhat.com> --- Changes from v2: * passed status from the called to qemuMigrationSrcCancelUnattended by the suggestion from Jiri Changed from v1: * moved status checking to qemuMigrationSrcCancelUnattended src/qemu/qemu_migration.c | 47 ++++++++++++++++++++++++--------------- src/qemu/qemu_migration.h | 3 ++- src/qemu/qemu_process.c | 2 +- 3 files changed, 32 insertions(+), 20 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 33cc0f0ffe..ffffeea75c 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -7390,7 +7390,8 @@ qemuMigrationSrcToFile(virDomainObj *vm, */ int qemuMigrationSrcCancelUnattended(virDomainObj *vm, - virDomainJobObj *oldJob) + virDomainJobObj *oldJob, + virDomainJobStatus migStatus) { bool storage = false; size_t i; @@ -7398,25 +7399,35 @@ qemuMigrationSrcCancelUnattended(virDomainObj *vm, VIR_DEBUG("Canceling unfinished outgoing migration of domain %s", vm->def->name); - /* Make sure MIGRATION event handler can store the current migration state - * in the job. + /* If QEMU has already reached a terminal state during the reconnect + * gap, skip restoring the async job and issuing migrate_cancel: QEMU + * won't emit any further MIGRATION events, so the wait loop in + * qemuMigrationSrcCancel would block forever. The migStatus passed in + * comes from the query-migrate call in qemuProcessRecoverMigration, + * which is authoritative for the state QEMU reached while no libvirtd + * was attached. */ - if (!vm->job->current) { - qemuDomainObjRestoreAsyncJob(vm, VIR_ASYNC_JOB_MIGRATION_OUT, - oldJob->phase, oldJob->asyncStarted, - VIR_DOMAIN_JOB_OPERATION_MIGRATION_OUT, - QEMU_DOMAIN_JOB_STATS_TYPE_MIGRATION, - VIR_DOMAIN_JOB_STATUS_FAILED, - VIR_JOB_NONE); - } - - /* We're inside a MODIFY job and the restored MIGRATION_OUT async job is - * used only for processing migration events from QEMU. Thus we don't want - * to start a nested job for talking to QEMU. - */ - qemuMigrationSrcCancel(vm, VIR_ASYNC_JOB_NONE, true); + if (migStatus != VIR_DOMAIN_JOB_STATUS_CANCELED) { + /* Make sure MIGRATION event handler can store the current migration + * state in the job. + */ + if (!vm->job->current) { + qemuDomainObjRestoreAsyncJob(vm, VIR_ASYNC_JOB_MIGRATION_OUT, + oldJob->phase, oldJob->asyncStarted, + VIR_DOMAIN_JOB_OPERATION_MIGRATION_OUT, + QEMU_DOMAIN_JOB_STATS_TYPE_MIGRATION, + VIR_DOMAIN_JOB_STATUS_FAILED, + VIR_JOB_NONE); + } + + /* We're inside a MODIFY job and the restored MIGRATION_OUT async job is + * used only for processing migration events from QEMU. Thus we don't + * want to start a nested job for talking to QEMU. + */ + qemuMigrationSrcCancel(vm, VIR_ASYNC_JOB_NONE, true); - virDomainObjEndAsyncJob(vm); + virDomainObjEndAsyncJob(vm); + } for (i = 0; i < vm->def->ndisks; i++) { virDomainDiskDef *disk = vm->def->disks[i]; diff --git a/src/qemu/qemu_migration.h b/src/qemu/qemu_migration.h index ef6a1563a0..59f32d2ebf 100644 --- a/src/qemu/qemu_migration.h +++ b/src/qemu/qemu_migration.h @@ -253,7 +253,8 @@ qemuMigrationSrcToFile(virDomainObj *vm, int qemuMigrationSrcCancelUnattended(virDomainObj *vm, - virDomainJobObj *oldJob); + virDomainJobObj *oldJob, + virDomainJobStatus migStatus); int qemuMigrationSrcCancel(virDomainObj *vm, diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 7ebc038e54..a6d33f6746 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -3798,7 +3798,7 @@ qemuProcessRecoverMigrationOut(virQEMUDriver *driver, */ VIR_DEBUG("Cancelling unfinished migration of domain %s", vm->def->name); - if (qemuMigrationSrcCancelUnattended(vm, job) < 0) { + if (qemuMigrationSrcCancelUnattended(vm, job, migStatus) < 0) { VIR_WARN("Could not cancel ongoing migration of domain %s", vm->def->name); } -- 2.51.0

2 1

[PATCH 0/2] qemucapabilitiestest: Update data for qemu-11.0 release
by Peter Krempa 24 Apr '26

24 Apr '26

qemu-11.0 was released yesterday, bump the test data. Peter Krempa (2): qemucapabilitiestest: Update capabilities for release of qemu-11.0 on x86_64 qemucapabilitiestest: Update capabilities for release of qemu-11.0 on aarch64 .../caps_11.0.0_aarch64.replies | 2410 ++++++++-------- .../caps_11.0.0_aarch64.xml | 4 +- .../caps_11.0.0_x86_64.replies | 2547 +++++++++-------- .../caps_11.0.0_x86_64.xml | 54 +- 4 files changed, 2519 insertions(+), 2496 deletions(-) -- 2.53.0

2 3

[PATCH 0/2] Fix support for monolithic kernels (no module support)
by Baptiste Daroussin 24 Apr '26

24 Apr '26

Hi all, This series fixes libvirt compilation and runtime on systems using a monolithic kernel compiled without module support (CONFIG_MODULES=n). Currently, libvirt assumes kernel module support is always available, which causes build failures or runtime errors on such systems. Changes: - virpci: don't fail VFIO passthrough when modules.alias is missing - virpci: don"t fail VFIO passthrough when /sys/module/*/drivers is inaccessible. Tested on kernel 6.18 with grsecurity and a custom monolithic kernel. Note this issue has previously been reported there: https://gitlab.com/libvirt/libvirt/-/work_items/591 Thanks, Baptiste Daroussin

2 3

[PATCH v2 0/2] add virtio-console support
by Roman Bogorodskiy 24 Apr '26

24 Apr '26

Changes since v1: - Added ',' validation in port name and UNIX socket path, as it would brake the bhyve command line parsing - Minor formatting/style fixes - Added a separate patch to report ISA controller validation error Roman Bogorodskiy (2): bhyve: add virtio-console support bhyve: improve ISA controller validation error reporting src/bhyve/bhyve_command.c | 42 +++++- src/bhyve/bhyve_device.c | 42 +++++- src/bhyve/bhyve_domain.c | 72 ++++++++-- src/bhyve/bhyve_process.c | 14 ++ ...exml2argv-2-virtio-console-mixed-addr.args | 10 ++ ...ml2argv-2-virtio-console-mixed-addr.ldargs | 4 + ...vexml2argv-2-virtio-console-mixed-addr.xml | 26 ++++ .../bhyvexml2argv-virtio-console-addr.args | 10 ++ .../bhyvexml2argv-virtio-console-addr.ldargs | 4 + .../bhyvexml2argv-virtio-console-addr.xml | 25 ++++ ...vexml2argv-virtio-console-controllers.args | 11 ++ ...xml2argv-virtio-console-controllers.ldargs | 4 + ...yvexml2argv-virtio-console-controllers.xml | 31 +++++ ...vexml2argv-virtio-console-invalid-name.xml | 21 +++ ...vexml2argv-virtio-console-invalid-path.xml | 21 +++ ...v-virtio-console-multiple-controllers.args | 11 ++ ...virtio-console-multiple-controllers.ldargs | 4 + ...gv-virtio-console-multiple-controllers.xml | 89 +++++++++++++ ...xml2argv-virtio-console-too-many-ports.xml | 25 ++++ .../x86_64/bhyvexml2argv-virtio-console.args | 10 ++ .../bhyvexml2argv-virtio-console.ldargs | 4 + .../x86_64/bhyvexml2argv-virtio-console.xml | 21 +++ tests/bhyvexml2argvtest.c | 8 ++ ...xml2xmlout-2-virtio-console-mixed-addr.xml | 40 ++++++ .../bhyvexml2xmlout-virtio-console-addr.xml | 35 +++++ ...exml2xmlout-virtio-console-controllers.xml | 43 ++++++ ...ut-virtio-console-multiple-controllers.xml | 123 ++++++++++++++++++ .../x86_64/bhyvexml2xmlout-virtio-console.xml | 35 +++++ tests/bhyvexml2xmltest.c | 8 ++ 29 files changed, 782 insertions(+), 11 deletions(-) create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-2-virtio-console-mixed-addr.args create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-2-virtio-console-mixed-addr.ldargs create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-2-virtio-console-mixed-addr.xml create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-addr.args create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-addr.ldargs create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-addr.xml create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-controllers.args create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-controllers.ldargs create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-controllers.xml create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-invalid-name.xml create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-invalid-path.xml create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-multiple-controllers.args create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-multiple-controllers.ldargs create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-multiple-controllers.xml create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console-too-many-ports.xml create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console.args create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console.ldargs create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-virtio-console.xml create mode 100644 tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-2-virtio-console-mixed-addr.xml create mode 100644 tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-virtio-console-addr.xml create mode 100644 tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-virtio-console-controllers.xml create mode 100644 tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-virtio-console-multiple-controllers.xml create mode 100644 tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-virtio-console.xml -- 2.52.0

2 4

[PATCH] qemu: block core dump for TDX guests
by Jun Miao 24 Apr '26

24 Apr '26

TDX guests use encrypted memory that cannot be meaningfully dumped by the hypervisor. Attempting a core dump on a TDX guest would produce unusable output since the memory contents are encrypted. And dump will make TDVM crash. Block the core dump operation for TDX guests early with a clear error message instead of letting it proceed and abort the Qemu. Signed-off-by: Jun Miao <jun.miao(a)intel.com> --- src/qemu/qemu_driver.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index b3e60471a8..555a6b6fb3 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -3249,6 +3249,13 @@ qemuDomainCoreDumpWithFormat(virDomainPtr dom, if (virDomainObjCheckActive(vm) < 0) goto endjob; + if (vm->def->sec && + vm->def->sec->sectype == VIR_DOMAIN_LAUNCH_SECURITY_TDX) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("core dump is not supported for TDX guests")); + goto endjob; + } + priv = vm->privateData; qemuDomainJobSetStatsType(vm->job->current, QEMU_DOMAIN_JOB_STATS_TYPE_SAVEDUMP); -- 2.47.1

3 2