May 2025 - Devel - libvirt List Archives

[PATCH 1/2] NEWS: bhyve: document NVRAM support
by Roman Bogorodskiy 21 May '25

21 May '25

Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- NEWS.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index e924c08fbf..102e49373a 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -23,6 +23,14 @@ v11.4.0 (unreleased) That option suppresses registration of pkttyagent with polkitd. + * bhyve: support NVRAM configuration for UEFI firmwares + + The bhyve driver now supports specifying NVRAM store file, such as :: + + <os firmware='efi'> + <nvram/> + </os> + * **Bug fixes** * qemu: Fix failure when reverting to internal snapshots -- 2.49.0

2 3

[PATCH 0/5] bhyve: introduce NVRAM support
by Roman Bogorodskiy 20 May '25

20 May '25

Roman Bogorodskiy (5): bhyve: conf: introduce nvramDir bhyve: generate NVRAM bhyve arguments bhyve: firmware: try to guess NVRAM settings bhyve: introduce bhyveDomainDefValidate() bhyve: support removing NVRAM on domain undefine src/bhyve/bhyve_command.c | 8 +- src/bhyve/bhyve_conf.c | 4 + src/bhyve/bhyve_domain.c | 43 ++++++ src/bhyve/bhyve_driver.c | 32 ++++- src/bhyve/bhyve_firmware.c | 119 ++++++++++++++-- src/bhyve/bhyve_process.c | 132 ++++++++++++++++++ src/bhyve/bhyve_process.h | 8 ++ src/bhyve/bhyve_utils.h | 2 + src/bhyve/meson.build | 5 + ...gv-uefi-nvram-template-and-source-set.args | 12 ++ ...-uefi-nvram-template-and-source-set.ldargs | 1 + ...rgv-uefi-nvram-template-and-source-set.xml | 24 ++++ ...bhyvexml2argv-uefi-nvram-template-set.args | 12 ++ ...yvexml2argv-uefi-nvram-template-set.ldargs | 1 + .../bhyvexml2argv-uefi-nvram-template-set.xml | 24 ++++ .../bhyvexml2argv-uefi-nvram.args | 12 ++ .../bhyvexml2argv-uefi-nvram.ldargs | 1 + .../bhyvexml2argv-uefi-nvram.xml | 24 ++++ tests/bhyvexml2argvtest.c | 5 + 19 files changed, 452 insertions(+), 17 deletions(-) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.xml -- 2.49.0

2 7

[PATCH 0/4] virsh completer cleanups
by Peter Krempa 20 May '25

20 May '25

Make the core completer code common in all virt shells and annotate few arguments with the existing empty and local-file completers. Peter Krempa (4): virsh: completer: Extract common completer methods from virsh to vsh vsh: Apply empty/local completers to global commands virsh: Apply empty completer to arguments where completion doesn't make sense virsh: domain: Annotate rest of arguments taking local existing file tools/meson.build | 2 +- tools/virsh-backup.c | 6 +- tools/virsh-checkpoint.c | 8 +- tools/virsh-completer-domain.c | 70 ++++++------ tools/virsh-completer-host.c | 12 +- tools/virsh-completer-nodedev.c | 10 +- tools/virsh-completer-pool.c | 6 +- tools/virsh-completer-volume.c | 4 +- tools/virsh-completer.h | 19 +--- tools/virsh-domain.c | 112 ++++++++++--------- tools/virsh-host.c | 6 +- tools/virsh-interface.c | 2 +- tools/virsh-network.c | 9 +- tools/virsh-nodedev.c | 2 +- tools/virsh-nwfilter.c | 4 +- tools/virsh-pool.c | 18 +-- tools/virsh-secret.c | 6 +- tools/virsh-snapshot.c | 8 +- tools/virsh-volume.c | 12 +- tools/virsh.c | 2 +- tools/virsh.h | 2 +- tools/{virsh-completer.c => vsh-completer.c} | 34 +++--- tools/vsh-completer.h | 41 +++++++ tools/vsh.c | 6 + 24 files changed, 222 insertions(+), 179 deletions(-) rename tools/{virsh-completer.c => vsh-completer.c} (85%) create mode 100644 tools/vsh-completer.h -- 2.49.0

2 5

[PATCH] cputest: Skip more tests requiring JSON_MODELS if QEMU is disabled
by Jaroslav Suchanek 20 May '25

20 May '25

From: Jaroslav Suchanek <jsuchane(a)redhat.com> Marking more tests with JSON_MODELS_REQUIRED as these tests fail if QEMU is disabled, typically when running tests on FreeBSD or macOS systems. Signed-off-by: Jaroslav Suchanek <jsuchane(a)redhat.com> --- tests/cputest.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tests/cputest.c b/tests/cputest.c index de313f6102..bb471d2ae7 100644 --- a/tests/cputest.c +++ b/tests/cputest.c @@ -1183,14 +1183,14 @@ mymain(void) DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-D510", JSON_NONE); DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-N450", JSON_NONE); DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-P5362", JSON_MODELS_REQUIRED); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-P5362-2", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-P5362-2", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-650", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-2500", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-2540M", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-4670T", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-6600", JSON_HOST); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1270P", JSON_MODELS); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1365U", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1270P", JSON_MODELS_REQUIRED); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1365U", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-2600", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-2600-xsaveopt", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-3520M", JSON_NONE); @@ -1225,7 +1225,7 @@ mymain(void) DO_TEST_CPUID(VIR_ARCH_X86_64, "Ryzen-9-3900X-12-Core", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-5110", JSON_NONE); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-6731E", JSON_MODELS); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Bronze-3408U", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Bronze-3408U", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E3-1225-v5", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E3-1245-v5", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E3-1270-v5", JSON_MODELS); @@ -1244,12 +1244,12 @@ mymain(void) DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6130", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6148", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6152", JSON_MODELS); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6530", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6530", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Platinum-8268", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Platinum-9242", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Silver-4214R", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-W3520", JSON_HOST); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-w7-3465X", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-w7-3465X", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-X5460", JSON_NONE); DO_TEST_CPUID(VIR_ARCH_X86_64, "Ice-Lake-Server", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Cooperlake", JSON_MODELS); -- 2.49.0

2 1

[libvirt PATCH] qemu: forbid readonly attribute for externally launched virtiofsd
by Ján Tomko 20 May '25

20 May '25

From: Ján Tomko <jtomko(a)redhat.com> In that case, libvirtd cannot set it on the command line because virtiofsd is not launched by libvirt. https://issues.redhat.com/browse/RHEL-87522 Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- src/qemu/qemu_validate.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c index 87588024ce..013ff14d75 100644 --- a/src/qemu/qemu_validate.c +++ b/src/qemu/qemu_validate.c @@ -4684,6 +4684,11 @@ qemuValidateDomainDeviceDefFS(virDomainFSDef *fs, _("virtiofs does not support wrpolicy")); return -1; } + if (fs->readonly) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("readonly mode cannot be set for extrenally started virtiofsd")); + return -1; + } } if (fs->model != VIR_DOMAIN_FS_MODEL_DEFAULT) { -- 2.49.0

3 2

libvirt TLS certificates letsencrypt
by Jani Heikkinen 20 May '25

20 May '25

Hello! I am part of infrastructure team at BFH and we are building an openstack installation. A couple of months ago I was experimenting with setting up noVNC consoles with encryption. Connecting until the novncproxy service with TLS can be done with no issues, but the connection between libvirt and the proxy turned out to be problematic. We would really love to use letsencrypt certificates which are generated for each server/container, instead of relying on creating own CA and generate certificates. With libvirt, using letsencrypt is impossible, since the code does bunch of checks for properties of the TLS certificates, see: https://github.com/libvirt/libvirt/blob/bf79a021a6437b4f85469a53f650bff62db… Does anybody know, why these checks exist? They de facto prevent using anything else than self-generated certificates for securing vnc console traffic. Is using my own self-created CA somehow more trustworthy than LetsEncrypt root CA? Best, Jani Heikkinen -- Berner Fachhochschule / Bern University of Applied Sciences IT-Services / Team Linux & Infrastructure Services Jani Heikkinen IT Linux Engineer ___________________________________________________________ Dammweg 3, CH-3013 Bern Telefon direkt +41 31 848 68 14 Telefon Servicedesk +41 31 848 48 48 jani.heikkinen(a)bfh.ch

2 1

[PATCH 0/3] qemu: fix validation of 'fd' passing for backup job and improve debugability of passed FDs
by Peter Krempa 19 May '25

19 May '25

Peter Krempa (3): qemuBackupPrepare: Actually allow 'VIR_STORAGE_NET_HOST_TRANS_FD' docs: backup: Hint at proper selinux labelling of the FD-passed NBD socket qemu: fd: Log information about passed file descriptor docs/formatbackup.rst | 4 +++ src/qemu/qemu_backup.c | 4 ++- src/qemu/qemu_fd.c | 62 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 69 insertions(+), 1 deletion(-) -- 2.49.0

2 8

[PATCH v1 0/2] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling 19 May '25

19 May '25

The intention of reporting deprecated features and modifying the guest CPU model was to alleviate the user from the burden of preparing a guest with the necessary amendments to assure migration to newer hardware. While that goal was met by way of the "deprecated_features='on|off'" attribute, it still adds an extra step that the user must be aware to prepare a guest for migration and the errors that stem from an unsuccessful migration (due to feature incompatibility) is not always clear how to resolve. These patches make s390 CPU host models migration ready from the get-go by disabling deprecated features by default. They may still be disabled for other model types via the respective attribute, or reenabled if desired. Collin Walling (2): qemu: caps: add virCPUFeaturePolicy param to virQEMUCapsUpdateCPUDeprecatedFeatures qemu: caps: disable deprecated features for s390 models by default src/qemu/qemu_capabilities.c | 10 +++++++--- src/qemu/qemu_capabilities.h | 3 ++- src/qemu/qemu_driver.c | 3 ++- src/qemu/qemu_process.c | 19 ++++++++++++------- tests/domaincapsdata/qemu_10.0.0.s390x.xml | 8 ++++---- tests/domaincapsdata/qemu_9.1.0.s390x.xml | 8 ++++---- tests/domaincapsdata/qemu_9.2.0.s390x.xml | 8 ++++---- ...default-video-type-s390x.s390x-latest.args | 2 +- ...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +- .../launch-security-s390-pv.s390x-latest.args | 2 +- ...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +- .../s390-defaultconsole.s390x-latest.args | 2 +- .../s390-panic.s390x-latest.args | 2 +- 13 files changed, 41 insertions(+), 30 deletions(-) -- 2.47.1

2 5

[libvirt PATCH 0/2] Remove 'inline' keyword from C files
by Ján Tomko 19 May '25

19 May '25

2 3

[PATCH 0/1] virsh: Add option '--no-pkttyagent'
by Jens Schmidt 19 May '25

19 May '25

As discussed in https://gitlab.com/libvirt/libvirt/-/issues/757. I'm not quite sure about using a long-only-option, since that's a first in virsh. But OTOH this option seems too insignificant to also use one of the precious short option characters for it. Please check and let me know what you think. Thanks! Jens Schmidt (1): virsh: Add option '--no-pkttyagent' NEWS.rst | 4 ++++ docs/manpages/virsh.rst | 8 ++++++++ tools/virsh.c | 13 ++++++++++++- tools/vsh.h | 1 + 4 files changed, 25 insertions(+), 1 deletion(-) -- 2.39.5

3 8