- Devel - libvirt List Archives

[PATCH] docs: domain: Explain supported options of 'error_policy'
by Peter Krempa 22 May '25

22 May '25

From: Peter Krempa <pkrempa(a)redhat.com> Explain what the individual settings actually result in. The changes are based on the paraprhase of qemu documentation which in 'qemu-options.hx' states: ``werror=action,rerror=action`` Specify which action to take on write and read errors. Valid actions are: "ignore" (ignore the error and try to continue), "stop" (pause QEMU), "report" (report the error to the guest), "enospc" (pause QEMU only if the host disk is full; report the error to the guest otherwise). The default setting is ``werror=enospc`` and ``rerror=report``. Closes: https://gitlab.com/libvirt/libvirt/-/issues/138 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/formatdomain.rst | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index c7c75ae219..a23a746229 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -3451,8 +3451,12 @@ paravirtualized driver is specified via the ``disk`` element. and sync requests from guest are ignored). :since:`Since 0.6.0` - The optional ``error_policy`` attribute controls how the hypervisor will - behave on a disk read or write error, possible values are "stop", - "report" (:since:`since 0.9.7`), "ignore", and "enospace". + behave on a disk read or write error, possible values are ``stop`` ( + suspend/pause the domain on error), ``report`` (report the error to the + guest OS; :since:`since 0.9.7`), ``ignore`` (ignore the error and try to + continue), and ``enospace`` (suspend/pause the domain only if host storage + is full; report the error to the guest OS otherwise). + The default is left to the discretion of the hypervisor. :since:`Since 0.8.0`. - The optional ``rerror_policy`` attribute controls behavior for read -- 2.49.0

2 1

[PATCH v2 0/3] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling 22 May '25

22 May '25

Changelog v2 - changed behavior from disabling features on the host model to instead flagging the guest CPU to disable deprecated features - removed disabling deprecated features on host model in virQEMUCapsInitCPUModelS390 - added flagging deprecated_feats in qemuProcessUpdateGuestCPU - added tests for deprecated_features='on' - split virQEMUCapsUpdateCPUDeprecatedFeatures update and qemuProcessUpdateGuestCPU changes 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 (3): qemu: caps: add virCPUFeaturePolicy param to virQEMUCapsUpdateCPUDeprecatedFeatures qemu: process: refactor deprecated features code qemu: process: disable deprecated features for s390 models by default src/qemu/qemu_capabilities.c | 6 ++-- src/qemu/qemu_capabilities.h | 3 +- src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_process.c | 30 ++++++++++++----- ...l-deprecated-features-on.s390x-latest.args | 32 +++++++++++++++++++ ...el-deprecated-features-on.s390x-latest.xml | 25 +++++++++++++++ .../cpu-model-deprecated-features-on.xml | 15 +++++++++ ...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 +- tests/qemuxmlconftest.c | 1 + 14 files changed, 108 insertions(+), 19 deletions(-) create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.args create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.xml create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.xml -- 2.47.1

1 5

RFC: schemas: resolving path type inconsistency in XML schemas
by Kirill Shchetiniuk 21 May '25

21 May '25

Hello everyone, Sometime ago I sent a patch changing the XML schema to add GTK support for libvirt. As the type for one path argument, I used the <text/> type, simply copying the similar approach from another place in the XML schema definition. I was told that it's not the best way to use the <text/> type for paths and that absFilePath, a defined basic type for paths, should be used instead. After this, I decided to fix this in a place where I had seen the same approach, too. After further investigation, I found a lot more places where the <text/> type is used for paths. Moreover, I found out that we have at least 4 type definitions for paths (files and directories). Some of these types accept simply everything, others paths starting with "/" or even Windows-style disk names. <define name="filePath"> <data type="string"> <param name="pattern">.+</param> </data> </define> <define name="dirPath"> <data type="string"> <param name="pattern">.+</param> </data> </define> <define name="absFilePath"> <data type="string"> <param name="pattern">(/|[a-zA-Z]:\\).+</param> </data> </define> <define name="absDirPath"> <data type="string"> <param name="pattern">/.*</param> </data> </define> According to this, I have the following questions: 1. Do we allow users to use relative paths, or MUST all paths be absolute? 2. Do we have to accept Windows-style paths everywhere? 3. Do we need to have different types for directories? For example, in some places, the filePath type is used for directory parameters. And as a last question, do we want to unify the basic types related to paths to maintain the schemas more consistent? Kirill

2 1

[PATCH 0/2] qemu: monitor: Fix handling of 'detach' for 'migrate' and 'dump-guest-memory' QMP commands
by Peter Krempa 21 May '25

21 May '25

QEMU is deprecating 'detach' argument of 'migrate' as it was never actually used. Drop it in libvirt as we always specify it. The monitor handler of 'dump-guest-memory' allows controlling 'detach' but always passes true. Libvirt doesn't want to block the monitor so hardcode 'true' in the monitor code instead. Peter Krempa (2): qemuMonitorDumpToFd: Drop 'detach' argument qemuMonitorJSONMigrate: Drop 'detach' QMP option src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_monitor.c | 5 ++--- src/qemu/qemu_monitor.h | 3 +-- src/qemu/qemu_monitor_json.c | 6 ++---- src/qemu/qemu_monitor_json.h | 3 +-- tests/qemumonitorjsontest.c | 3 +-- 6 files changed, 8 insertions(+), 14 deletions(-) -- 2.49.0

2 3

[PATCH] build-aux: simplify grep detection on FreeBSD
by Roman Bogorodskiy 21 May '25

21 May '25

From: Alexey Dokuchaev <danfe(a)FreeBSD.org> For quite some time now FreeBSD provides its own version of the grep(1) tool, and the GNU grep from the ports collection is available as ggrep(1). So remove the detection code and just request ggrep. Signed-off-by: Alexey Dokuchaev <danfe(a)FreeBSD.org> --- build-aux/meson.build | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/build-aux/meson.build b/build-aux/meson.build index bcd10e89f2..56c91971cf 100644 --- a/build-aux/meson.build +++ b/build-aux/meson.build @@ -13,23 +13,10 @@ if git and tests_enabled[0] if host_machine.system() == 'freebsd' or host_machine.system() == 'darwin' make_prog = find_program('gmake') sed_prog = find_program('gsed') + grep_prog = find_program('ggrep') else make_prog = find_program('make') sed_prog = find_program('sed') - endif - - if host_machine.system() == 'freebsd' - grep_prog = find_program('grep') - grep_cmd = run_command(grep_prog, '--version', check: true) - if grep_cmd.stdout().startswith('grep (BSD grep') - grep_prog = find_program('/usr/local/bin/grep', required: false) - if not grep_prog.found() - error('GNU grep not found') - endif - endif - elif host_machine.system() == 'darwin' - grep_prog = find_program('ggrep') - else grep_prog = find_program('grep') endif -- 2.49.0

2 1

[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