July 2025 - Devel - libvirt List Archives

[PATCH 0/5] qemu: Fixes to firmware selection
by Andrea Bolognani 28 Aug '25

28 Aug '25

See [1] for the discussion motivating these changes. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/U33U… Andrea Bolognani (5): tests: Tweak descriptor for combined firmware tests: Add firmware-auto-efi-sev-snp qemu: Fix matching for stateless/combined firmware qemu: Fix matching for read/write firmware news: Update for firmware selection fixes NEWS.rst | 6 +++ src/qemu/qemu_firmware.c | 39 +++++++++++++------ .../usr/share/qemu/firmware/90-combined.json | 4 +- tests/qemufirmwaretest.c | 2 +- ...ware-auto-efi-rw-pflash.x86_64-latest.args | 36 +++++++++++++++++ ...mware-auto-efi-rw-pflash.x86_64-latest.err | 1 - ...mware-auto-efi-rw-pflash.x86_64-latest.xml | 6 ++- .../firmware-auto-efi-rw.x86_64-latest.args | 36 +++++++++++++++++ .../firmware-auto-efi-rw.x86_64-latest.err | 1 - .../firmware-auto-efi-rw.x86_64-latest.xml | 6 ++- ...auto-efi-sev-snp.x86_64-latest+amdsev.args | 37 ++++++++++++++++++ ...auto-efi-sev-snp.x86_64-latest+amdsev.xml} | 9 ++++- .../firmware-auto-efi-sev-snp.xml | 20 ++++++++++ tests/qemuxmlconftest.c | 8 +++- 14 files changed, 190 insertions(+), 21 deletions(-) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.args copy tests/qemuxmlconfdata/{firmware-auto-efi-rw-pflash.x86_64-latest.xml => firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml} (76%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.xml -- 2.50.1

4 31

[PATCH v2 0/1] docs : add doc on cpu model and features
by Hector CAO 21 Aug '25

21 Aug '25

Hello, This is a follow-up of the submission: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/EZBL… Based on Jiri's feedback, it is better to tackle this situation by documentation. You can find here a proposal for the documentation. The section will be rendered at : https://libvirt.org/formatcaps.html Best regards, Hector v2: - wrap lines at 80 characters Hector Cao (1): docs : add doc on cpu model and features docs/formatcaps.rst | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) -- 2.34.1

3 3

[PATCH v2 00/11] Enabling logging for ch guests
by Praveen K Paladugu 19 Aug '25

19 Aug '25

LogContext management is now moved from Qemu driver to hypervisor. After migrating Qemu to use domain_logcontext, I extended ch driver to use also use domain_logcontext to capture early boot failures within domain specific log files. Changes in V2: * refactored the patches to ensure all of them build. * ch driver will use virtlogd to consolidate logs from hypervisor and its domains. Praveen K Paladugu (11): hypervisor: copy qemu log context mgmt to hypervisor hypervisor: rename reference to qemu in domain_logcontext hypervisor: drop qemu specific args in domainLogContextNew hypervisor: Build domain_logcontext libvirt_private: export symbols from domain_logcontext qemu: Modify qemu driver to use domainLogContext qemu: delete qemu_logcontext files ch: Enable logging for ch domains ch: move curl_data and curl_callback definitions ch: Enable logging curl responses from ch ch: configure ch driver to use virlogd po/POTFILES | 2 +- src/ch/ch_conf.c | 1 + src/ch/ch_conf.h | 2 + src/ch/ch_monitor.c | 84 ++++++++++++------- src/ch/ch_monitor.h | 6 +- src/ch/ch_process.c | 36 ++++++-- .../domain_logcontext.c} | 78 +++++++++-------- src/hypervisor/domain_logcontext.h | 45 ++++++++++ src/hypervisor/meson.build | 1 + src/libvirt_private.syms | 6 ++ src/qemu/meson.build | 1 - src/qemu/qemu_domain.c | 28 +++---- src/qemu/qemu_domain.h | 12 +-- src/qemu/qemu_logcontext.h | 41 --------- src/qemu/qemu_nbdkit.c | 12 ++- src/qemu/qemu_process.c | 45 +++++----- 16 files changed, 236 insertions(+), 164 deletions(-) rename src/{qemu/qemu_logcontext.c => hypervisor/domain_logcontext.c} (79%) create mode 100644 src/hypervisor/domain_logcontext.h delete mode 100644 src/qemu/qemu_logcontext.h -- 2.47.0

4 16

[PATCH v2 0/4] bhyve: implement domain{Block,Interface,Memory}Stats
by Roman Bogorodskiy 18 Aug '25

18 Aug '25

Changes since v1: - Added "bhyve: implement domainInterfaceStats" patch PS It was temping to factor out obtaining struct kinfo_proc using sysctlnametomib() + sysctl(), but I have to make it visible to use outside of virprocess, e.g. in bhyve_driver.c, so it doesn't look like it's worth the effort for now. Probably it'll make sense to implement a FreeBSD version of virProcessGetStat() once there are more users of this code. Roman Bogorodskiy (4): bhyve: implement domainInterfaceStats virprocess: implement virProcessGetStatInfo() for FreeBSD bhyve: implement domainMemoryStats bhyve: implement domainBlockStats src/bhyve/bhyve_driver.c | 140 +++++++++++++++++++++++++++++++++++++++ src/util/virprocess.c | 104 +++++++++++++++++++++-------- 2 files changed, 218 insertions(+), 26 deletions(-) -- 2.49.0

2 8

[PATCH v2 18/24] qapi/migration: Deprecate capabilities commands
by Fabiano Rosas 14 Aug '25

14 Aug '25

The concept of capabilities is being merged into the concept of parameters. From now on, the commands that handle capabilities are deprecated in favor of the commands that handle parameters. Affected commands: - migrate-set-capabilities - query-migrate-capabilities Signed-off-by: Fabiano Rosas <farosas(a)suse.de> --- docs/about/deprecated.rst | 12 ++++++++++++ migration/migration-hmp-cmds.c | 6 ++++++ qapi/migration.json | 16 ++++++++++++++-- 3 files changed, 32 insertions(+), 2 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 42037131de..15474833ea 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -605,3 +605,15 @@ command documentation for details on the ``fdset`` usage. The ``zero-blocks`` capability was part of the block migration which doesn't exist anymore since it was removed in QEMU v9.1. + +``migrate-set-capabilities`` command (since 10.1) +''''''''''''''''''''''''''''''''''''''''''''''''' + +This command was deprecated. Use ``migrate-set-parameters`` instead +which now supports setting capabilities. + +``query-migrate-capabilities`` command (since 10.1) +''''''''''''''''''''''''''''''''''''''''''''''''''' + +This command was deprecated. Use ``query-migrate-parameters`` instead +which now supports querying capabilities. diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c index 8615340a6b..7f234d5aa8 100644 --- a/migration/migration-hmp-cmds.c +++ b/migration/migration-hmp-cmds.c @@ -229,6 +229,9 @@ void hmp_info_migrate_capabilities(Monitor *mon, const QDict *qdict) { MigrationCapabilityStatusList *caps, *cap; + warn_report("info migrate_capabilities is deprecated;" + " use info migrate_parameters instead"); + caps = qmp_query_migrate_capabilities(NULL); if (caps) { @@ -616,6 +619,9 @@ void hmp_migrate_set_capability(Monitor *mon, const QDict *qdict) MigrationCapabilityStatus *value; int val; + warn_report("migrate_set_capability is deprecated;" + " use migrate_set_parameter instead"); + val = qapi_enum_parse(&MigrationCapability_lookup, cap, -1, &err); if (val < 0) { goto end; diff --git a/qapi/migration.json b/qapi/migration.json index 3d3f5624c5..c5e6ea1a2d 100644 --- a/qapi/migration.json +++ b/qapi/migration.json @@ -521,6 +521,11 @@ # # @capabilities: json array of capability modifications to make # +# Features: +# +# @deprecated: This command is deprecated in favor of +# migrate-set-parameters. +# # Since: 1.2 # # .. qmp-example:: @@ -530,7 +535,8 @@ # <- { "return": {} } ## { 'command': 'migrate-set-capabilities', - 'data': { 'capabilities': ['MigrationCapabilityStatus'] } } + 'data': { 'capabilities': ['MigrationCapabilityStatus'] }, + 'features': ['deprecated'] } ## # @query-migrate-capabilities: @@ -539,6 +545,11 @@ # # Returns: @MigrationCapabilityStatus # +# Features: +# +# @deprecated: This command is deprecated in favor of +# query-migrate-parameters. +# # Since: 1.2 # # .. qmp-example:: @@ -554,7 +565,8 @@ # {"state": false, "capability": "x-colo"} # ]} ## -{ 'command': 'query-migrate-capabilities', 'returns': ['MigrationCapabilityStatus']} +{ 'command': 'query-migrate-capabilities', 'returns': ['MigrationCapabilityStatus'], + 'features': ['deprecated'] } ## # @MultiFDCompression: -- 2.35.3

6 5

[PATCH] qemu: don't warn about missing SMM for CVM firmware
by Daniel P. Berrangé 12 Aug '25

12 Aug '25

From: Daniel P. Berrangé <berrange(a)redhat.com> Neither Intel TDX / AMD SEV(SNP) allow use of SMM, but the EDK2 firmware none the less supports secureboot. Libvirt currently issues bogus warnings about Fedora firmware warning : qemuFirmwareSanityCheck:1575 : Firmware description '/usr/share/qemu/firmware/60-edk2-ovmf-x64-inteltdx.json' has invalid set of features: requires-smm = 0, secure-boot = 1, enrolled-keys = 1 This removes the warning if the firmware descriptor indicates use of any confidential VM technology. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/qemu/qemu_firmware.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c index f10137144e..dbec068738 100644 --- a/src/qemu/qemu_firmware.c +++ b/src/qemu/qemu_firmware.c @@ -1540,6 +1540,7 @@ qemuFirmwareSanityCheck(const qemuFirmware *fw, bool requiresSMM = false; bool supportsSecureBoot = false; bool hasEnrolledKeys = false; + bool cvm = false; for (i = 0; i < fw->nfeatures; i++) { switch (fw->features[i]) { @@ -1552,13 +1553,15 @@ qemuFirmwareSanityCheck(const qemuFirmware *fw, case QEMU_FIRMWARE_FEATURE_ENROLLED_KEYS: hasEnrolledKeys = true; break; - case QEMU_FIRMWARE_FEATURE_NONE: - case QEMU_FIRMWARE_FEATURE_ACPI_S3: - case QEMU_FIRMWARE_FEATURE_ACPI_S4: case QEMU_FIRMWARE_FEATURE_AMD_SEV: case QEMU_FIRMWARE_FEATURE_AMD_SEV_ES: case QEMU_FIRMWARE_FEATURE_AMD_SEV_SNP: case QEMU_FIRMWARE_FEATURE_INTEL_TDX: + cvm = true; + break; + case QEMU_FIRMWARE_FEATURE_NONE: + case QEMU_FIRMWARE_FEATURE_ACPI_S3: + case QEMU_FIRMWARE_FEATURE_ACPI_S4: case QEMU_FIRMWARE_FEATURE_VERBOSE_DYNAMIC: case QEMU_FIRMWARE_FEATURE_VERBOSE_STATIC: case QEMU_FIRMWARE_FEATURE_LAST: @@ -1566,7 +1569,8 @@ qemuFirmwareSanityCheck(const qemuFirmware *fw, } } - if ((supportsSecureBoot != requiresSMM) || + if ((!cvm && + (supportsSecureBoot != requiresSMM)) || (hasEnrolledKeys && !supportsSecureBoot)) { VIR_WARN("Firmware description '%s' has invalid set of features: " "%s = %d, %s = %d, %s = %d", -- 2.50.1

3 4

[PATCH] Storage: ZFS: implement `resizeVol` method to support native resize
by George Melikov 12 Aug '25

12 Aug '25

From: George Melikov <mail(a)gmelikov.ru> ZFS doesn't have thick allocations, every allocation is thin-provisioned, so resize operation is essentially a zvol size limit change (`zfs set volsize=X pool/zvol_name`). Shrink is allowed too (which leads to data destruction), but shrink restriction is already implemented in libvirt, so this function doesn't need to check anything. This patch is posted via PR too and has green test runs https://gitlab.com/libvirt/libvirt/-/merge_requests/495 Signed-off-by: George Melikov <mail(a)gmelikov.ru> --- src/storage/storage_backend_zfs.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/src/storage/storage_backend_zfs.c b/src/storage/storage_backend_zfs.c index 178b505e92..33434d0cac 100644 --- a/src/storage/storage_backend_zfs.c +++ b/src/storage/storage_backend_zfs.c @@ -439,6 +439,25 @@ virStorageBackendZFSDeletePool(virStoragePoolObj *pool, return virCommandRun(cmd, NULL); } +static int +virStorageBackendZFSResizeVol(virStoragePoolObj *pool, + virStorageVolDef *vol, + unsigned long long capacity, + unsigned int flags) +{ + virStoragePoolDef *def = virStoragePoolObjGetDef(pool); + g_autoptr(virCommand) resize_cmd = NULL; + + virCheckFlags(0, -1); + + resize_cmd = virCommandNewArgList(ZFS, "set", NULL); + virCommandAddArgFormat(resize_cmd, "volsize=%llu", capacity); + virCommandAddArgFormat(resize_cmd, "%s/%s", + def->source.name, vol->name); + + return virCommandRun(resize_cmd, NULL); +} + virStorageBackend virStorageBackendZFS = { .type = VIR_STORAGE_POOL_ZFS, @@ -450,6 +469,7 @@ virStorageBackend virStorageBackendZFS = { .deletePool = virStorageBackendZFSDeletePool, .uploadVol = virStorageBackendVolUploadLocal, .downloadVol = virStorageBackendVolDownloadLocal, + .resizeVol = virStorageBackendZFSResizeVol, }; -- 2.47.2

2 1

[PATCH 0/5] Cleanup of callers of virDomainDefGetVcpu
by Peter Krempa 12 Aug '25

12 Aug '25

Fix few issues with how virDomainDefGetVcpu is called and in related code. Peter Krempa (5): Unexport virCHProcessSetupVcpu virDomainVcpuDefPostParse: Remove impossible check qemu: domain: Remove unused qemuDomainGetVcpuHalted virCHDomainRefreshThreadInfo: Don't trust vcpu ID returned by hypervisor virCHDomainRefreshThreadInfo: Remove illusion that caller cares about return value src/ch/ch_domain.c | 17 ++++++++++------- src/ch/ch_domain.h | 2 +- src/ch/ch_process.c | 2 +- src/ch/ch_process.h | 3 --- src/conf/domain_postparse.c | 4 ---- src/qemu/qemu_domain.c | 15 --------------- src/qemu/qemu_domain.h | 1 - 7 files changed, 12 insertions(+), 32 deletions(-) -- 2.50.1

2 7

[RFC] x86 Host CPU features detection by MSRs
by Hector Cao 12 Aug '25

12 Aug '25

Hello, This mail is a Request for Comment. On recent Intel CPUs, some of the CPU features (mostly vmx-* subfeatures) are listed and controlled via the MSRs (Model Specific Registers) instead of the traditional CPUID instruction method. Right now, libvirt reads the MSR's values via /dev/cpu/*/cpu populated by the msr kernel module. src/cpu/cpu_x86.c: ... /* This is best effort since there might be no way to read the MSR * when we are not running as root. */ for (i = 0; i < nmsrs; i++) { if (virHostCPUGetMSR(msrs[i], &msr) == 0) { virCPUx86DataItem item = { .type = VIR_CPU_X86_DATA_MSR, .data.msr = { ... There are 2 potential issues: 1) As stated in the source code comment above, MSR values read might fail when libvirt is not run as root. 2) MSR values read might fail if the MSR kernel module is not loaded, this is still the case in some of the Linux distros. The issue 2) has been brought up in Ubuntu/Debian : https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/271 but the feedback was to try to fix the issue in the libvirt source code itself. Indeed, libvirt already loads some kernel modules it depends on. For example the NBD kernel module in src/util/virtfile.c ... static bool virFileNBDLoadDriver(void) { if (virKModIsProhibited(NBD_DRIVER)) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Failed to load nbd module: administratively prohibited")); return false; } else { g_autofree char *errbuf = NULL; if ((errbuf = virKModLoad(NBD_DRIVER))) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Failed to load nbd module")); ... Andrea Bolognani's proposal of an approach that could work: 1. try using the unprivileged KVM API is available (or maybe the necessary information is exposed via QMP too?) like how QEMU does; 2. if that fails, try using the privileged /dev API; 3. if that fails too, load the msr module and try again; I would like to have some feedback from the libvirt community about if that is worth tackling these issues and the right way to do that. If we can end up with an agreement in this mail thread, I can work on the solution implementation and send it in a separate submission. Best regards, Hector

3 15

[PATCH v2 0/2] Introduce hardware UUID (hwuuid) element
by Mark Cave-Ayland 04 Aug '25

04 Aug '25

Following on from the discussions at [1] and more recently [2], this series introduces a new hardware UUID (hwuuid) element that allows an external UUID to be provided to the guest, as opposed to the libvirt domain UUID. The use case for this feature is to allow a domain to cloned and then restarted without changing its guest-visible UUID e.g. via dmidecode. Patch 1 introduces the new hardware UUID (hwuuid) element along with an implementation for the QEMU driver, whilst patch 2 adds additional tests to ensure the hwuuid functionality is working as expected. Note that from reading the source it doesn't appear as if all virtualisation platforms will support this feature: I've included the relevant changes for the QEMU driver since that is what we use here at Nutanix. Signed-off-by: Mark Cave-Ayland <mark.caveayland(a)nutanix.com> [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/YXN2… [2] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/HGFT… v2: - Rebase onto master - Rework if() logic in virSysinfoSystemParseXML() in patch 1 as suggested by Daniel - Add R-B tag from Daniel to patch 2 Mark Cave-Ayland (2): conf: introduce hardware UUID (hwuuid) element qemuxmlconftest: add tests for new hardware UUID (hwuuid) element docs/formatdomain.rst | 7 +++ src/conf/domain_conf.c | 43 ++++++++++++++++--- src/conf/domain_conf.h | 1 + src/conf/schemas/domaincommon.rng | 5 +++ src/qemu/qemu_command.c | 6 ++- ...hwuuid-smbios-uuid-match.x86_64-latest.err | 1 + .../hwuuid-smbios-uuid-match.xml | 36 ++++++++++++++++ .../qemuxmlconfdata/hwuuid.x86_64-latest.args | 35 +++++++++++++++ .../qemuxmlconfdata/hwuuid.x86_64-latest.xml | 41 ++++++++++++++++++ tests/qemuxmlconfdata/hwuuid.xml | 30 +++++++++++++ tests/qemuxmlconftest.c | 3 ++ 11 files changed, 202 insertions(+), 6 deletions(-) create mode 100644 tests/qemuxmlconfdata/hwuuid-smbios-uuid-match.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/hwuuid-smbios-uuid-match.xml create mode 100644 tests/qemuxmlconfdata/hwuuid.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/hwuuid.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/hwuuid.xml -- 2.43.0

2 5