July 2022 - Devel - libvirt List Archives

[PATCH V2 0/4] Handle physical address bits
by Jim Fehlig 04 Aug '22

04 Aug '22

Hi All, This is a V2 of Dario's old patches adding support for specifying the virtual CPU address size in bits https://listman.redhat.com/archives/libvir-list/2020-October/210901.html I've rebased those patches to latest master and tweaked them a bit. E.g. I removed the qemucaps code since phys-bits and host-phys-bits have been around before the minimum qemu version supported by libvirt. I also added patches to expose the number of host address bits and ensure ABI stability as requested in the old review comments. Dario Faggioli (2): conf: Add support for specifying CPU max physical address size qemu: Add support for max physical address size Jim Fehlig (2): capabilities: Report number of host CPU physical address bits cpu conf: Check ABI stability of CPU maxphysaddr config docs/formatdomain.rst | 23 +++++++ src/conf/cpu_conf.c | 63 +++++++++++++++++++ src/conf/cpu_conf.h | 17 +++++ src/conf/schemas/cputypes.rng | 19 ++++++ src/cpu/cpu_x86.c | 8 +++ src/libvirt_private.syms | 2 + src/qemu/qemu_command.c | 21 +++++++ src/qemu/qemu_domain.c | 46 ++++++++++++++ src/qemu/qemu_validate.c | 12 ++++ src/util/virhostcpu.c | 55 ++++++++++++++++ src/util/virhostcpu.h | 3 + .../cpu-phys-bits-emulate.xml | 20 ++++++ .../cpu-phys-bits-passthrough.xml | 20 ++++++ tests/genericxml2xmltest.c | 3 + .../cpu-phys-bits-emulate.args | 32 ++++++++++ .../cpu-phys-bits-emulate.xml | 20 ++++++ .../cpu-phys-bits-emulate2.args | 32 ++++++++++ .../cpu-phys-bits-emulate2.xml | 20 ++++++ .../cpu-phys-bits-emulate3.err | 1 + .../cpu-phys-bits-emulate3.xml | 20 ++++++ .../cpu-phys-bits-passthrough.args | 32 ++++++++++ .../cpu-phys-bits-passthrough.xml | 20 ++++++ .../cpu-phys-bits-passthrough2.err | 1 + .../cpu-phys-bits-passthrough2.xml | 20 ++++++ .../cpu-phys-bits-passthrough3.err | 1 + .../cpu-phys-bits-passthrough3.xml | 20 ++++++ tests/qemuxml2argvtest.c | 7 +++ 27 files changed, 538 insertions(+) create mode 100644 tests/genericxml2xmlindata/cpu-phys-bits-emulate.xml create mode 100644 tests/genericxml2xmlindata/cpu-phys-bits-passthrough.xml create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate.args create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate.xml create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate2.args create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate2.xml create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate3.err create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate3.xml create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough.args create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough.xml create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.err create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.xml create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.err create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.xml -- 2.36.1

2 10

[libvirt PATCH 0/2] fix console device access in ch driver
by Praveen K Paladugu 03 Aug '22

03 Aug '22

Patch1: Drops the check to only have a console/serial device configured for ch VMs. This is no longer needed. Patch2: Addresses https://gitlab.com/libvirt/libvirt/-/issues/344. Libvirt adds compat console devices for "hvm" VMs. The added console/serial device type is initialized to VIR_DOMAIN_CHR_TYPE_NULL, when in fact the device added is a pty device. This patch modifies the default console device type to "pty". I looked at NOT adding Compat Console devices for ch VMs. But this looked like a better fix. Praveen K Paladugu (2): ch: drop the check to have a single console/serial conf: set the default chr device type to pty src/ch/ch_domain.c | 9 +-------- src/conf/domain_conf.c | 1 + 2 files changed, 2 insertions(+), 8 deletions(-) -- 2.27.0

2 5

[PATCH 0/3] testutilsqemu: Fake TPM versions
by Michal Privoznik 02 Aug '22

02 Aug '22

I thought I've sent these before the freeze but as I tried to ping them, I realize I didn't. I'm not sure how critical these are to get into the release (after all we see no test failing), but they make at least VIR_TEST_DEBUG output of domcapabilities cleaner. Michal Prívozník (3): virtpm: Use corresponding type for argument for virTPM*CapsGet() testutilsqemu: Mock virTPMSwtpmSetupCapsGet() testutilsqemu: Fake TPM versions src/util/virtpm.c | 4 ++-- src/util/virtpm.h | 6 +++--- .../domaincapsdata/qemu_3.1.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_3.1.0-tcg.x86_64.xml | 4 ++++ tests/domaincapsdata/qemu_3.1.0.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_4.0.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_4.0.0-tcg.x86_64.xml | 4 ++++ tests/domaincapsdata/qemu_4.0.0.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_4.1.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_4.1.0-tcg.x86_64.xml | 4 ++++ tests/domaincapsdata/qemu_4.1.0.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 4 ++++ tests/domaincapsdata/qemu_4.2.0.ppc64.xml | 4 ++++ tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 4 ++++ .../qemu_5.0.0-virt.aarch64.xml | 4 ++++ tests/domaincapsdata/qemu_5.0.0.aarch64.xml | 4 ++++ tests/domaincapsdata/qemu_5.0.0.ppc64.xml | 4 ++++ tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 4 ++++ tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 4 ++++ .../qemu_5.2.0-virt.aarch64.xml | 4 ++++ tests/domaincapsdata/qemu_5.2.0.aarch64.xml | 4 ++++ tests/domaincapsdata/qemu_5.2.0.ppc64.xml | 4 ++++ tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 4 ++++ .../qemu_6.0.0-virt.aarch64.xml | 4 ++++ tests/domaincapsdata/qemu_6.0.0.aarch64.xml | 4 ++++ tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 4 ++++ tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 4 ++++ .../qemu_6.2.0-virt.aarch64.xml | 4 ++++ tests/domaincapsdata/qemu_6.2.0.aarch64.xml | 4 ++++ tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 4 ++++ tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 4 ++++ .../qemu_7.0.0-virt.aarch64.xml | 4 ++++ tests/domaincapsdata/qemu_7.0.0.aarch64.xml | 4 ++++ tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 4 ++++ tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 4 ++++ .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 4 ++++ tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 4 ++++ tests/testutilsqemu.c | 19 +++++++++++++++++++ 54 files changed, 228 insertions(+), 5 deletions(-) -- 2.35.1

3 8

[PATCH 0/8] conf: Don't lose <active_pcr_banks/> when no TPM version is provided
by Michal Privoznik 02 Aug '22

02 Aug '22

*** BLURB HERE *** Michal Prívozník (8): conf: Report an error when default TPM model is provided conf: Report error when default TPM version is provided conf: Drop needless setting of VIR_DOMAIN_TPM_VERSION_DEFAULT conf: Move _virDomainTPMDef::version into _virDomainTPMDef::data::emulator conf: Use virXMLPropEnum more when parsing TPM qemu_domain: Move TPM post parse code into qemuDomainTPMDefPostParse() qemu: Move TPMs validation out of PostParse conf: Don't lose <active_pcr_banks/> when no TPM version is provided src/conf/domain_conf.c | 81 +++++++++++++------------------- src/conf/domain_conf.h | 10 ++-- src/conf/domain_validate.c | 28 ++++++++++- src/qemu/qemu_command.c | 2 +- src/qemu/qemu_domain.c | 63 ++++++------------------- src/qemu/qemu_tpm.c | 10 ++-- src/qemu/qemu_validate.c | 87 ++++++++++++++++++++++++----------- src/security/virt-aa-helper.c | 2 +- 8 files changed, 147 insertions(+), 136 deletions(-) -- 2.35.1

3 23

Can RHEL7 VM run remote libvirt commands to Fedora36 host?
by Carol Bouchard 01 Aug '22

01 Aug '22

I have a test environment that use to work but no longer does. My laptop is Fedora36 (libvirt version 8.1.0.2) while the VMs it spawns are RHEL7 (max libvirt version is 4.5.0). The source of my problem seems to be that RHEL7 libvirt needs rw socket /var/run/libvirt/libvirt-sock which no longer exists in fedora36. The following is successful from RHEL7 VM to laptop: virsh -d0 --connect 'qemu+ssh://192.168.120.1/system?*socket*=/var/run/libvirt/libvirt-sock-ro' domstate beaker-test-vm1.beaker If I change the action from domstate to start, it fails on error: Failed to start domain beaker-test-vm1.beaker error: operation forbidden: read only access prevents virDomainCreate which made me realize ro stands for read-only; however, there is no libvirt-sock. I tried some of the other socket files without success. Is there a work-around? Carol

2 3

[PATCH] spec: Remove duplicate check of libvirtd status
by Jim Fehlig 01 Aug '22

01 Aug '22

The %posttrans scriptlet checks if libvirtd is active within a condition that is only executed if libvirtd is active. Remove the duplicate check. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- This patch contains an improvement Martin suggested while reviewing another patch to the posttrans scriptlet https://listman.redhat.com/archives/libvir-list/2022-July/232947.html The problem of not restarting socket units if libvird is inactive persists, but it is not clear if socket units need restarted on package update. libvirt.spec.in | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 9d788b790f..a238edf2aa 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1365,18 +1365,12 @@ then # own the sockets again when it comes back up. Thus we must # do this particular ordering, so that we get libvirtd # running with socket activation in use - /bin/systemctl is-active libvirtd.service 1>/dev/null 2>&1 - if test $? = 0 - then - /bin/systemctl stop libvirtd.service >/dev/null 2>&1 || : - - /bin/systemctl try-restart \ - libvirtd.socket \ - libvirtd-ro.socket \ - libvirtd-admin.socket >/dev/null 2>&1 || : - - /bin/systemctl start libvirtd.service >/dev/null 2>&1 || : - fi + /bin/systemctl stop libvirtd.service >/dev/null 2>&1 || : + /bin/systemctl try-restart \ + libvirtd.socket \ + libvirtd-ro.socket \ + libvirtd-admin.socket >/dev/null 2>&1 || : + /bin/systemctl start libvirtd.service >/dev/null 2>&1 || : fi fi -- 2.36.1

2 2

[libvirt] Semantic change in v4.3 slows down image creation and snapshots (on ZFS)
by Christian Ehrhardt 31 Jul '22

31 Jul '22

Hi, when discussing bug [1] triggered by [2] Daniel and I have found that the change [3] which is in since v4.3 was a semantic change to the behavior of libvirt. virt-manager used and still does issue a volume XML like: <volume> <name>disk.qcow2</name> <capacity>16106127360</capacity> <allocation>16106127360</allocation> <target> <format type="qcow2"/> <features> <lazy_refcounts/> </features> </target> </volume> Up until the commit above that was using preallocation=metadata, but now uses preallocation=falloc. In many cases (read: Fileystems) that won't be very user-visible, but if you are running on ZFS (or anything else that can't fallocate well) this is made worse by [4] slowing down these operations a lot. After the POV for virt-manager seems to have settled on the bug [1] referenced the remaining question is if libvirt should revert/modify the change [3] - and that we agreed required a wider discussion to be had here, hence this mail. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1759454 [2]: https://bugs.launchpad.net/virt-manager/+bug/1847105 [3]: https://libvirt.org/git/?p=libvirt.git;a=commit;h=c9ec7088c7a3f4cd26bb471f1… [4]: https://github.com/zfsonlinux/zfs/issues/326 -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd

4 3

Feature proposal: support setting block I/O throttling for vhostuser disk
by jlwang 30 Jul '22

30 Jul '22

Hi, blkdeviotune command don't support setting I/O throttlig for vhostuser disk. We propose to commit patch to support the feature. Are there any issues that would prevent this feature from being accepted? Thanks, Wang Jinlei

1 0

[libvirt PATCH 0/2] qemu: support stateless UEFI firmware
by Daniel P. Berrangé 29 Jul '22

29 Jul '22

This is to enable SEV builds of UEFI which provide only a single CODE.fd file, with not VARS.fd. Daniel P. Berrangé (2): conf: support stateless UEFI firmware qemu: support use of stateless EFI firmware docs/formatdomain.rst | 9 +++- src/conf/domain_conf.c | 9 ++++ src/conf/domain_conf.h | 1 + src/conf/domain_validate.c | 26 ++++++++++ src/conf/schemas/domaincommon.rng | 5 ++ src/qemu/qemu_domain.c | 3 +- src/qemu/qemu_firmware.c | 48 +++++++++++-------- ...-auto-bios-not-stateless.x86_64-latest.err | 1 + .../firmware-auto-bios-not-stateless.xml | 18 +++++++ ...are-auto-bios-stateless.x86_64-latest.args | 32 +++++++++++++ .../firmware-auto-bios-stateless.xml | 18 +++++++ ...ware-auto-efi-stateless.x86_64-latest.args | 33 +++++++++++++ .../firmware-auto-efi-stateless.xml | 18 +++++++ .../firmware-manual-bios-not-stateless.err | 1 + .../firmware-manual-bios-not-stateless.xml | 15 ++++++ .../firmware-manual-bios-stateless.args | 30 ++++++++++++ .../firmware-manual-bios-stateless.xml | 15 ++++++ ...nual-efi-nvram-stateless.x86_64-latest.err | 1 + .../firmware-manual-efi-nvram-stateless.xml | 21 ++++++++ ...nvram-template-stateless.x86_64-latest.err | 1 + ...re-manual-efi-nvram-template-stateless.xml | 19 ++++++++ ...re-manual-efi-stateless.x86_64-latest.args | 33 +++++++++++++ .../firmware-manual-efi-stateless.xml | 18 +++++++ tests/qemuxml2argvtest.c | 10 ++++ ...ware-auto-bios-stateless.x86_64-latest.xml | 34 +++++++++++++ .../firmware-manual-bios-stateless.xml | 25 ++++++++++ .../firmware-manual-bios.xml | 25 ++++++++++ tests/qemuxml2xmltest.c | 3 ++ 28 files changed, 451 insertions(+), 21 deletions(-) create mode 100644 tests/qemuxml2argvdata/firmware-auto-bios-not-stateless.x86_64-latest.err create mode 100644 tests/qemuxml2argvdata/firmware-auto-bios-not-stateless.xml create mode 100644 tests/qemuxml2argvdata/firmware-auto-bios-stateless.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/firmware-auto-bios-stateless.xml create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-stateless.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-stateless.xml create mode 100644 tests/qemuxml2argvdata/firmware-manual-bios-not-stateless.err create mode 100644 tests/qemuxml2argvdata/firmware-manual-bios-not-stateless.xml create mode 100644 tests/qemuxml2argvdata/firmware-manual-bios-stateless.args create mode 100644 tests/qemuxml2argvdata/firmware-manual-bios-stateless.xml create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-nvram-stateless.x86_64-latest.err create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-nvram-stateless.xml create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-nvram-template-stateless.x86_64-latest.err create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-nvram-template-stateless.xml create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-stateless.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-stateless.xml create mode 100644 tests/qemuxml2xmloutdata/firmware-auto-bios-stateless.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/firmware-manual-bios-stateless.xml create mode 100644 tests/qemuxml2xmloutdata/firmware-manual-bios.xml -- 2.36.1

3 9

Entering freeze for libvirt-8.6.0
by Jiri Denemark 29 Jul '22

29 Jul '22

I have just tagged v8.6.0-rc1 in the repository and pushed signed tarballs and source RPMs to https://libvirt.org/sources/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Thanks, Jirka

1 1