- Devel - libvirt List Archives

[PATCH 0/9] qemu: Move config validation out of qemu_process.c
by Peter Krempa 27 May '25

27 May '25

Some more cleanups for misplaced validation of config that I've noticed when I was looking for the code validating floppies in my previous series. Peter Krempa (9): qemuDomainValidateStorageSource: Rework protocol validation into a switch statement qemu: Move disk backend validation checks from qemuProcessStartValidateDisks to qemuDomainValidateStorageSource qemu: block: Drop code for 'vxhs' storage protocol qemu.conf: Document options for VxHS block network protocol TLS config as ignored qemu: conf: Drop handling of 'vxhs' config options qemu: Move logic from qemuProcessStartValidateShmem to qemuValidateDomainDeviceDefShmem qemu: Move checks for number of listening sockets of graphics to validation code qemuProcessStartValidateGraphics: Remove redundant checks for RDP protocol features qemuProcessStartValidateGraphics: Move RDP validation logic to qemu_validate.c src/qemu/libvirtd_qemu.aug | 2 + src/qemu/qemu.conf.in | 42 +----------- src/qemu/qemu_block.c | 41 +----------- src/qemu/qemu_conf.c | 17 ----- src/qemu/qemu_conf.h | 4 -- src/qemu/qemu_domain.c | 112 +++++++++++++++---------------- src/qemu/qemu_process.c | 132 ------------------------------------- src/qemu/qemu_validate.c | 45 ++++++++++++- tests/qemuxmlconftest.c | 4 -- tests/testutilsqemu.c | 2 - 10 files changed, 101 insertions(+), 300 deletions(-) -- 2.49.0

2 10

[PATCH v2 0/3] CH: Add support for a configuration file and log level configuration
by Stefan Kober 27 May '25

27 May '25

Similar to the qemu.conf file that allows QEMU specific configurations we add the possibility to specify a ch.conf file for Cloud Hypervisor configuration. The initial single config option is the log level, which sets the verbosity of the Cloud Hypervisor process. This allows for simpler debugging when using Cloud Hypervisor via libvirt. Stefan Kober (3): ch: Add config file support ch: add log level configuration option NEWS: ch: announce log_level config option NEWS.rst | 5 +++++ src/ch/ch.conf | 11 ++++++++++ src/ch/ch_conf.c | 31 ++++++++++++++++++++++++++ src/ch/ch_conf.h | 18 +++++++++++++++ src/ch/ch_driver.c | 6 +++++ src/ch/ch_monitor.c | 6 +++++ src/ch/libvirtd_ch.aug | 40 ++++++++++++++++++++++++++++++++++ src/ch/meson.build | 12 ++++++++++ src/ch/test_libvirtd_ch.aug.in | 5 +++++ 9 files changed, 134 insertions(+) create mode 100644 src/ch/ch.conf create mode 100644 src/ch/libvirtd_ch.aug create mode 100644 src/ch/test_libvirtd_ch.aug.in -- 2.49.0

1 3

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

26 May '25

Changelog v3 - added qemu caps check to avoid breaking s390 guests trying to default deprecated_features='off' on QEMU versions that do not support reporting these features 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 | 32 ++++++++++++++----- ...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, 110 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

3 9

[PATCH 0/4] qemu: Reflect support of floppy devices in capabilities XML
by Peter Krempa 26 May '25

26 May '25

Probe if qemu actually supports floppy controllers which can be compiled out with custom configs and reflect that in the capability XML. Peter Krempa (4): qemu: domain: Introduce qemuDomainMachineSupportsFloppy qemu: Move floppy device support validation to validation code qemu: capabilities: Introduce QEMU_CAPS_BUS_FLOPPY qemuDomainMachineSupportsFloppy: Check for QEMU_CAPS_BUS_FLOPPY src/qemu/qemu_capabilities.c | 6 ++- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain.c | 15 +++++++ src/qemu/qemu_domain.h | 4 ++ src/qemu/qemu_process.c | 8 ---- src/qemu/qemu_validate.c | 7 +++ .../qemu_10.0.0-virt.aarch64.xml | 2 - tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 2 - tests/domaincapsdata/qemu_10.0.0.s390x.xml | 2 - tests/domaincapsdata/qemu_8.1.0.s390x.xml | 2 - .../qemu_8.2.0-tcg-virt.loongarch64.xml | 2 - .../qemu_8.2.0-virt.aarch64.xml | 2 - .../qemu_8.2.0-virt.loongarch64.xml | 2 - tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 2 - tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 2 - tests/domaincapsdata/qemu_8.2.0.s390x.xml | 2 - .../qemu_9.1.0-tcg-virt.riscv64.xml | 2 - .../qemu_9.1.0-virt.riscv64.xml | 2 - tests/domaincapsdata/qemu_9.1.0.s390x.xml | 2 - .../qemu_9.2.0-hvf.aarch64+hvf.xml | 2 - tests/domaincapsdata/qemu_9.2.0.s390x.xml | 2 - .../caps_10.0.0_ppc64.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 1 + .../caps_6.2.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 1 + .../caps_7.0.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 1 + .../caps_7.1.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 1 + .../caps_7.2.0_x86_64+hvf.xml | 1 + .../caps_7.2.0_x86_64.xml | 1 + .../caps_8.0.0_x86_64.xml | 1 + .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_9.0.0_sparc.xml | 1 + .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.xml | 1 + .../disk-floppy-pseries.ppc64-latest.err | 2 +- .../disk-floppy-pseries.ppc64-latest.xml | 44 ------------------- tests/qemuxmlconftest.c | 2 +- 44 files changed, 53 insertions(+), 86 deletions(-) delete mode 100644 tests/qemuxmlconfdata/disk-floppy-pseries.ppc64-latest.xml -- 2.49.0

2 8

[RFC PATCH 0/2] schemas: path types refactor
by Kirill Shchetiniuk 26 May '25

26 May '25

This series of patches aims to introduce unification for path attributes in schema definitions. Previously defined types used for schema definitions are now unified into two main types: absolutePath and relativePath. This change addresses previous inconsistencies where types were sometimes used incorrectly (e.g., filePath for directory attributes). Due to prior inconsistencies, some locations now accept relative paths even if they were not explicitly intended to. To avoid such inconsistencies in the future, better names for the path types have been selected. Moreover, I suggest deprecating (with future patches) the use of relative paths in places where they are not explicitly meant to be used. This will make the schemas more consistent and, as a result, encourage users to write more deterministic XML definitions. For now the relativePath is used in such places to remain backward compatibility. Kirill Shchetiniuk (2): schemas: path types unification / refactor schemas: path attributes type refactor src/conf/schemas/basictypes.rng | 18 +--- src/conf/schemas/capability.rng | 4 +- src/conf/schemas/domainbackup.rng | 10 +- src/conf/schemas/domaincaps.rng | 2 +- src/conf/schemas/domaincheckpoint.rng | 2 +- src/conf/schemas/domaincommon.rng | 132 +++++++++++++------------- src/conf/schemas/domainsnapshot.rng | 8 +- src/conf/schemas/network.rng | 4 +- src/conf/schemas/nodedev.rng | 4 +- src/conf/schemas/secret.rng | 2 +- src/conf/schemas/storagecommon.rng | 2 +- src/conf/schemas/storagepool.rng | 10 +- src/conf/schemas/storagevol.rng | 6 +- 13 files changed, 96 insertions(+), 108 deletions(-) -- 2.49.0

1 2

[PATCH 0/2] CH: Add support for a configuration file and log level configuration
by Stefan Kober 26 May '25

26 May '25

Similar to the qemu.conf file that allows QEMU specific configurations we add the possibility to specify a ch.conf file for Cloud Hypervisor configuration. The initial single config option is the log level, which sets the verbosity of the Cloud Hypervisor process. This allows for simpler debugging when using Cloud Hypervisor via libvirt. Stefan Kober (2): ch: Add config file support ch: add log level configuration option src/ch/ch_conf.c | 32 ++++++++++++++++++++++++++++++++ src/ch/ch_conf.h | 18 ++++++++++++++++++ src/ch/ch_driver.c | 6 ++++++ src/ch/ch_monitor.c | 6 ++++++ 4 files changed, 62 insertions(+) -- 2.49.0

2 5

[PATCH v2 0/4] domain_capabilities: add console capabilities
by Roman Bogorodskiy 26 May '25

26 May '25

Main change since v1 is adding console capabilities reporting for the libxl driver. There's also a minor cosmetic change in the qemu part to alphabetically sort VIR_DOMAIN_CHR_TYPE_* arguments for VIR_DOMAIN_CAPS_ENUM_SET(). Apparently, the only other driver reporting domain capabilities is the test driver, so it looks like all drivers are covered by this series. Roman Bogorodskiy (4): domain_capabilities: add console capabilities bhyve: capabilities: report NMDM console qemu: capabilities: report supported console types libxl: capabilities: report supported console types src/bhyve/bhyve_capabilities.c | 5 +++ src/conf/domain_capabilities.c | 12 +++++++ src/conf/domain_capabilities.h | 8 +++++ src/conf/schemas/domaincaps.rng | 10 ++++++ src/libxl/libxl_capabilities.c | 23 ++++++++++++- src/qemu/qemu_capabilities.c | 32 +++++++++++++++++++ src/qemu/qemu_capabilities.h | 3 ++ tests/domaincapsdata/bhyve_basic.x86_64.xml | 5 +++ tests/domaincapsdata/bhyve_fbuf.x86_64.xml | 5 +++ tests/domaincapsdata/bhyve_uefi.x86_64.xml | 5 +++ tests/domaincapsdata/libxl-xenfv.xml | 13 ++++++++ tests/domaincapsdata/libxl-xenpv.xml | 13 ++++++++ .../qemu_10.0.0-q35.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 18 +++++++++++ .../qemu_10.0.0-virt.aarch64.xml | 15 +++++++++ tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 15 +++++++++ tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_10.0.0.s390x.xml | 15 +++++++++ .../qemu_10.0.0.x86_64+amdsev.xml | 18 +++++++++++ tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 15 +++++++++ tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.1.0.ppc64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 18 +++++++++++ .../qemu_7.2.0-hvf.x86_64+hvf.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_7.2.0-tcg.x86_64+hvf.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.2.0.ppc.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.1.0.s390x.xml | 15 +++++++++ tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_8.2.0-tcg-virt.loongarch64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 18 +++++++++++ .../qemu_8.2.0-virt.aarch64.xml | 16 ++++++++++ .../qemu_8.2.0-virt.loongarch64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.2.0.s390x.xml | 15 +++++++++ tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.0.0.sparc.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_9.1.0-tcg-virt.riscv64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 18 +++++++++++ .../qemu_9.1.0-virt.riscv64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.1.0.s390x.xml | 15 +++++++++ tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 18 +++++++++++ .../qemu_9.2.0-hvf.aarch64+hvf.xml | 16 ++++++++++ .../qemu_9.2.0-q35.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.2.0.s390x.xml | 15 +++++++++ .../qemu_9.2.0.x86_64+amdsev.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 18 +++++++++++ 74 files changed, 1213 insertions(+), 1 deletion(-) -- 2.49.0

2 5

[PATCH v3 0/2] Fix virtio console port assignment issue
by Aaron M. Brown 22 May '25

22 May '25

Changelog: --- v3: - Added Reviewed-By - Included CI Results Link --- v2: - Split patch into two commits - Added fixes tag --- This libvirt patch does the following: 1. fixes an issue with virtio console device port assignment on vioserial buses 2. updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity Currently in libvirt, a virtio console device cannot be assigned a port number greater than zero on a vioserial bus. This leads to port collision errors when adding more than 1 virtio console device on a single vioserial bus. After applying this patch, one can add multiple console ports under a single vioserial bus. Here is a link to CI results for this series: https://gitlab.com/aaronbmalik/libvirt/-/pipelines/1831901334 Aaron M. Brown (2): Fix virtio console port assignment on vioserial bus Updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity src/conf/domain_addr.c | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) -- 2.39.5 (Apple Git-154)

1 2

[PATCH 0/7] nss: Couple of fixes and small improvements
by Michal Privoznik 22 May '25

22 May '25

I've noticed most of these after I've turned on debugging for the NSS plugin: diff --git i/tools/nss/libvirt_nss.h w/tools/nss/libvirt_nss.h index 54a0216013..f9c3136985 100644 --- i/tools/nss/libvirt_nss.h +++ w/tools/nss/libvirt_nss.h @@ -35 +35 @@ -#if 0 +#if 1 Michal Prívozník (7): libvirt_nss_macs: Fix type of @len in findMACsFromJSON() nss: Add missing includes for gai_strerror() nss: Declare g_autofree and g_steal_pointer() macros libvirt_nss: Use automatic memory freeing libvirt_nss: Drop needless cleanup labels libvirt_nss: Allocate buffer in ERROR() dynamically libvirt_nss: Allocate buffer in aiforaf() dynamically build-aux/syntax-check.mk | 2 +- tools/nss/libvirt_nss.c | 52 +++++++++++++--------------------- tools/nss/libvirt_nss.h | 33 +++++++++++++++++++-- tools/nss/libvirt_nss_leases.c | 3 ++ tools/nss/libvirt_nss_macs.c | 2 +- 5 files changed, 55 insertions(+), 37 deletions(-) -- 2.49.0

6 16

[PATCH] virsh: Do not print warnings with "error:" prefix
by Jiri Denemark 22 May '25

22 May '25

From: Jiri Denemark <jdenemar(a)redhat.com> Both vshWarn and vshError are just wrappers around vshPrintStderr which properly propagates the message level to the log, but fails to honor it when printing on stderr. https://issues.redhat.com/browse/RHEL-79460 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- tools/vsh.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/vsh.c b/tools/vsh.c index 05845e2c1e..e892cbca22 100644 --- a/tools/vsh.c +++ b/tools/vsh.c @@ -2123,7 +2123,11 @@ vshPrintStderr(vshControl *ctl, * printing to stderr will not interleave correctly with stdout * unless we flush between every transition between streams. */ fflush(stdout); - fprintf(stderr, _("error: %1$s\n"), NULLSTR(str)); + + if (level == VSH_ERR_WARNING) + fprintf(stderr, _("warning: %1$s\n"), NULLSTR(str)); + else + fprintf(stderr, _("error: %1$s\n"), NULLSTR(str)); fflush(stderr); } -- 2.49.0

2 1