October 2022 - Devel - libvirt List Archives

Entering freeze for libvirt-8.9.0
by Jiri Denemark 28 Oct '22

28 Oct '22

I have just tagged v8.9.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

[PATCH] tests: Fix libxlxml2domconfigtest with latest xen
by Cole Robinson 28 Oct '22

28 Oct '22

shadow_memkb is populated from a libxl API call, and the value can change. For example: https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2c992810854a15b41be920… Mock libxl_get_required_shadow_memory to give consistent output Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- tests/libxlmock.c | 11 +++++++++++ tests/libxlxml2domconfigdata/basic-hvm.json | 2 +- tests/libxlxml2domconfigdata/basic-pv.json | 2 +- tests/libxlxml2domconfigdata/basic-pvh.json | 2 +- tests/libxlxml2domconfigdata/cpu-shares-hvm.json | 2 +- tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json | 2 +- .../fullvirt-cpuid-legacy-nest.json | 2 +- tests/libxlxml2domconfigdata/fullvirt-cpuid.json | 2 +- .../libxlxml2domconfigdata/max-eventchannels-hvm.json | 2 +- tests/libxlxml2domconfigdata/max-gntframes-hvm.json | 2 +- tests/libxlxml2domconfigdata/moredevs-hvm.json | 2 +- tests/libxlxml2domconfigdata/multiple-ip.json | 2 +- tests/libxlxml2domconfigdata/variable-clock-hvm.json | 2 +- .../libxlxml2domconfigdata/vnuma-hvm-legacy-nest.json | 2 +- tests/libxlxml2domconfigdata/vnuma-hvm.json | 2 +- 15 files changed, 25 insertions(+), 14 deletions(-) diff --git a/tests/libxlmock.c b/tests/libxlmock.c index 0e4bf7df52..4754597e5b 100644 --- a/tests/libxlmock.c +++ b/tests/libxlmock.c @@ -109,6 +109,17 @@ VIR_MOCK_STUB_RET_ARGS(bind, const struct sockaddr *, addr, socklen_t, addrlen) +VIR_MOCK_IMPL_RET_ARGS(libxl_get_required_shadow_memory, + unsigned long, + unsigned long, maxmem_kb, + unsigned int, smp_cpus) +{ + /* silence gcc warning about unused function */ + if (0) + real_libxl_get_required_shadow_memory(maxmem_kb, smp_cpus); + return 1234; +} + VIR_MOCK_IMPL_RET_ARGS(__xstat, int, int, ver, const char *, path, diff --git a/tests/libxlxml2domconfigdata/basic-hvm.json b/tests/libxlxml2domconfigdata/basic-hvm.json index 87f8cb7d8a..d30875420d 100644 --- a/tests/libxlxml2domconfigdata/basic-hvm.json +++ b/tests/libxlxml2domconfigdata/basic-hvm.json @@ -15,7 +15,7 @@ "max_memkb": 1048576, "target_memkb": 1048576, "video_memkb": 8192, - "shadow_memkb": 12288, + "shadow_memkb": 1234, "device_model_version": "qemu_xen", "device_model": "/bin/true", "sched_params": { diff --git a/tests/libxlxml2domconfigdata/basic-pv.json b/tests/libxlxml2domconfigdata/basic-pv.json index b71c3b0f49..32d188fabd 100644 --- a/tests/libxlxml2domconfigdata/basic-pv.json +++ b/tests/libxlxml2domconfigdata/basic-pv.json @@ -14,7 +14,7 @@ ], "max_memkb": 524288, "target_memkb": 524288, - "shadow_memkb": 8192, + "shadow_memkb": 1234, "sched_params": { }, diff --git a/tests/libxlxml2domconfigdata/basic-pvh.json b/tests/libxlxml2domconfigdata/basic-pvh.json index 48365c9026..f51957aa85 100644 --- a/tests/libxlxml2domconfigdata/basic-pvh.json +++ b/tests/libxlxml2domconfigdata/basic-pvh.json @@ -14,7 +14,7 @@ ], "max_memkb": 524288, "target_memkb": 524288, - "shadow_memkb": 8192, + "shadow_memkb": 1234, "sched_params": { }, diff --git a/tests/libxlxml2domconfigdata/cpu-shares-hvm.json b/tests/libxlxml2domconfigdata/cpu-shares-hvm.json index 2aa97e88c5..15105c83ad 100644 --- a/tests/libxlxml2domconfigdata/cpu-shares-hvm.json +++ b/tests/libxlxml2domconfigdata/cpu-shares-hvm.json @@ -15,7 +15,7 @@ "max_memkb": 1048576, "target_memkb": 1048576, "video_memkb": 8192, - "shadow_memkb": 12288, + "shadow_memkb": 1234, "device_model_version": "qemu_xen", "device_model": "/bin/true", "sched_params": { diff --git a/tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json b/tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json index a2d46797aa..26f5abefee 100644 --- a/tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json +++ b/tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json @@ -11,7 +11,7 @@ ], "max_memkb": 592896, "target_memkb": 403456, - "shadow_memkb": 5656, + "shadow_memkb": 1234, "sched_params": { }, "apic": "True", diff --git a/tests/libxlxml2domconfigdata/fullvirt-cpuid-legacy-nest.json b/tests/libxlxml2domconfigdata/fullvirt-cpuid-legacy-nest.json index 6290655c20..740b82d2e6 100644 --- a/tests/libxlxml2domconfigdata/fullvirt-cpuid-legacy-nest.json +++ b/tests/libxlxml2domconfigdata/fullvirt-cpuid-legacy-nest.json @@ -11,7 +11,7 @@ ], "max_memkb": 592896, "target_memkb": 403456, - "shadow_memkb": 5656, + "shadow_memkb": 1234, "cpuid": [ { "leaf": 1, diff --git a/tests/libxlxml2domconfigdata/fullvirt-cpuid.json b/tests/libxlxml2domconfigdata/fullvirt-cpuid.json index 811a4f0ac7..8bf41894a5 100644 --- a/tests/libxlxml2domconfigdata/fullvirt-cpuid.json +++ b/tests/libxlxml2domconfigdata/fullvirt-cpuid.json @@ -11,7 +11,7 @@ ], "max_memkb": 592896, "target_memkb": 403456, - "shadow_memkb": 5656, + "shadow_memkb": 1234, "cpuid": [ { "leaf": 1, diff --git a/tests/libxlxml2domconfigdata/max-eventchannels-hvm.json b/tests/libxlxml2domconfigdata/max-eventchannels-hvm.json index 4a5b0ca65f..6f0daa065f 100644 --- a/tests/libxlxml2domconfigdata/max-eventchannels-hvm.json +++ b/tests/libxlxml2domconfigdata/max-eventchannels-hvm.json @@ -15,7 +15,7 @@ "max_memkb": 1048576, "target_memkb": 1048576, "video_memkb": 8192, - "shadow_memkb": 12288, + "shadow_memkb": 1234, "event_channels": 2047, "device_model_version": "qemu_xen", "device_model": "/bin/true", diff --git a/tests/libxlxml2domconfigdata/max-gntframes-hvm.json b/tests/libxlxml2domconfigdata/max-gntframes-hvm.json index 2883d057ff..35de588abc 100644 --- a/tests/libxlxml2domconfigdata/max-gntframes-hvm.json +++ b/tests/libxlxml2domconfigdata/max-gntframes-hvm.json @@ -15,7 +15,7 @@ "max_memkb": 1048576, "target_memkb": 1048576, "video_memkb": 8192, - "shadow_memkb": 12288, + "shadow_memkb": 1234, "max_grant_frames": 64, "device_model_version": "qemu_xen", "device_model": "/bin/true", diff --git a/tests/libxlxml2domconfigdata/moredevs-hvm.json b/tests/libxlxml2domconfigdata/moredevs-hvm.json index 58cf32a8d4..bdc9afc29b 100644 --- a/tests/libxlxml2domconfigdata/moredevs-hvm.json +++ b/tests/libxlxml2domconfigdata/moredevs-hvm.json @@ -17,7 +17,7 @@ "max_memkb": 1048576, "target_memkb": 1048576, "video_memkb": 8192, - "shadow_memkb": 12288, + "shadow_memkb": 1234, "device_model_version": "qemu_xen", "device_model": "/bin/true", "sched_params": { diff --git a/tests/libxlxml2domconfigdata/multiple-ip.json b/tests/libxlxml2domconfigdata/multiple-ip.json index 2db98b82f6..e0b37aa795 100644 --- a/tests/libxlxml2domconfigdata/multiple-ip.json +++ b/tests/libxlxml2domconfigdata/multiple-ip.json @@ -14,7 +14,7 @@ ], "max_memkb": 524288, "target_memkb": 524288, - "shadow_memkb": 8192, + "shadow_memkb": 1234, "sched_params": { }, diff --git a/tests/libxlxml2domconfigdata/variable-clock-hvm.json b/tests/libxlxml2domconfigdata/variable-clock-hvm.json index 9a25d51da2..3c131c603c 100644 --- a/tests/libxlxml2domconfigdata/variable-clock-hvm.json +++ b/tests/libxlxml2domconfigdata/variable-clock-hvm.json @@ -15,7 +15,7 @@ "max_memkb": 1048576, "target_memkb": 1048576, "video_memkb": 8192, - "shadow_memkb": 12288, + "shadow_memkb": 1234, "rtc_timeoffset": 3600, "localtime": "True", "device_model_version": "qemu_xen", diff --git a/tests/libxlxml2domconfigdata/vnuma-hvm-legacy-nest.json b/tests/libxlxml2domconfigdata/vnuma-hvm-legacy-nest.json index 6cda8d0252..6725df9112 100644 --- a/tests/libxlxml2domconfigdata/vnuma-hvm-legacy-nest.json +++ b/tests/libxlxml2domconfigdata/vnuma-hvm-legacy-nest.json @@ -103,7 +103,7 @@ "max_memkb": 1048576, "target_memkb": 1048576, "video_memkb": 8192, - "shadow_memkb": 14336, + "shadow_memkb": 1234, "device_model_version": "qemu_xen", "device_model": "/bin/true", "sched_params": { diff --git a/tests/libxlxml2domconfigdata/vnuma-hvm.json b/tests/libxlxml2domconfigdata/vnuma-hvm.json index f578ccd3d3..2556c82d5f 100644 --- a/tests/libxlxml2domconfigdata/vnuma-hvm.json +++ b/tests/libxlxml2domconfigdata/vnuma-hvm.json @@ -103,7 +103,7 @@ "max_memkb": 1048576, "target_memkb": 1048576, "video_memkb": 8192, - "shadow_memkb": 14336, + "shadow_memkb": 1234, "device_model_version": "qemu_xen", "device_model": "/bin/true", "sched_params": { -- 2.37.3

2 1

[PATCH] NEWS: Document my contributions for upcoming release
by Michal Privoznik 28 Oct '22

28 Oct '22

Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- NEWS.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 20541c6c6e..893ad6f370 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -17,6 +17,14 @@ v8.9.0 (unreleased) * **New features** + * qemu: Core Scheduling support + + To avoid side channel attacks, the Linux kernel allows creating groups of + processes that trust each other and thus can be scheduled to run on + hyperthreads of a CPU core at the same time. This is now implemented for + QEMU domains too (see ``sched_core`` knob in qemu.conf), although not + enabled by default, just yet. + * **Improvements** * Add ``vendor`` attribute for CPU models in domain capabilities @@ -37,6 +45,12 @@ v8.9.0 (unreleased) The channel and redirect devices supported by the hypervisor are now reported in domain capabilities. + * meson: Bump minimal required meson version + + Newer meson versions deprecate some functions used. These were replaced + with their newer counterparts and the minimal required mesion version was + bumped to 0.56.0. + * **Bug fixes** * qemu: Disable all blocker features in CPU baseline @@ -54,6 +68,14 @@ v8.9.0 (unreleased) In 8.8.0 release libvirt daemon would crash after it was restarted during an active outgoing migration. + * qemu: Refresh state after restore from a save image + + When a domain is restored from a saved image, libvirt now queries QEMU for + those parts of runtime information that were not part of the save image. + For instance: MAC address of a macvtap NICs, tray state of CD-ROMs, + allocated size of virtio-mem, and others. + + v8.8.0 (2022-10-03) =================== -- 2.37.4

2 1

[PATCH for 8.9.0 0/2] Last service file and manpage fixes
by Martin Kletzander 28 Oct '22

28 Oct '22

See patches for details (duh!). Martin Kletzander (2): Remove Before=libvirt-guests.service from other services docs: Remind users to remove --timeout option without socket activation docs/manpages/libvirtd.rst | 3 +++ src/ch/virtchd.service.in | 1 - src/lxc/virtlxcd.service.in | 1 - src/qemu/virtqemud.service.in | 1 - src/remote/libvirtd.service.in | 1 - 5 files changed, 3 insertions(+), 4 deletions(-) -- 2.38.1

2 3

[virt-manager] Cannot create vm with machine type raspi2b
by Niccolò Belli 27 Oct '22

27 Oct '22

Hi, Please excuse me if this is not the right place to file a bug. Let me know which one is it and I'll be glad to comply. I'm trying to use virt-manager to create a Raspberry Pi 2 virtual machine on my Talos 2 ppc64le workstation. In virt-manager I click on "New", then "Manual install", architecture "arm" and machine type "raspi2b". Next I set either "Generic or unknown OS" or "Debian 11" as operating system, I keep the default 1024 memory and 1 cpu and then I disable storage for this virtual machine (because I want to use an existing image with direct kernel boot, see https://raspi.debian.net/tested-images/) I check "Customize configuration before install" and I click "Finish". Unfortunately I get the following error: Error starting installation: Did not find any UEFI binary path for arch 'armv7l' So I've decided to start from scratch and select "virt" as machine type instead of "raspi2b" and change it back later. With "virt" I manage to reach the configuration overview before the installation begins. At this point I have three options for Firmware: Default UEFI UEFI armv7l:/usr/share/qemu/edk2-arm-code.fd UEFI is the default and if I change the machine type to raspi2b I still have the same three options (/usr/share/qemu/edk2-arm-code.fd does indeed exist in my file system). Unfortunately clicking on "Begin Installation" leads me to yet another error: Unable to complete install: 'internal error: Required option 'modelName' is not set for PCI controller with index '1', model 'pcie-root-port' and modelName 'none'' If I change the machine type back to "virt" I don't get any error. I'm using app-emulation/qemu 7.1.0, app-emulation/libvirt-8.8.0 and virt-manager-4.1.0 on Gentoo Linux ppc64le with a 4K page size kernel. Thanks, Niccolo' Belli

1 0

[libvirt PATCH v2 00/12] tools: provide virt-qemu-sev-validate for SEV(-ES) launch attestation
by Daniel P. Berrangé 27 Oct '22

27 Oct '22

The libvirt QEMU driver provides all the functionality required for launching a guest on AMD SEV(-ES) platforms, with a configuration that enables attestation of the launch measurement. The documentation for how to actually perform an attestation is severely lacking and not suitable for mere mortals to understand. IOW, someone trying to implement attestation is in for a world of pain and suffering. This series doesn't fix the documentation problem, but it does provide a reference implementation of a tool for performing attestation of SEV(-ES) guests in the context of libvirt / KVM. There will be other tools and libraries that implement attestation logic too, but this tool is likely somewhat unique in its usage of libvirt. Now for a attestation to be trustworthy you don't want to perform it on the hypervisor host, since the goal is to prove that the hypervisor has not acted maliciously. None the less it is still beneficial to have libvirt integration to some extent. When running this tool on a remote (trusted) host, it can connect to the libvirt hypervisor and fetch the data provided by the virDomainLaunchSecurityInfo API, which is safe to trust as the key pieces are cryptographically measured. Attestation is a complex problem though and it is very easy to screw up and feed the wrong information and then waste hours trying to figure out what piece was wrong, to cause the hash digest to change. For debugging such problems, you can thus tell the tool to operate insecurely, by querying libvirt for almost all of the configuration information required to determine the expected measurement. By comparing these results,to the results obtained in offline mode it helps narrow down where the mistake lies. So I view this tool as being useful in a number of ways: * Quality assurance engineers needing to test libvirt/QEMU/KVM get a simple and reliable tool for automating tests with. * Users running simple libvirt deployments without any large management stack, get a standalone tool for attestation they can rely on. * Developers writing/integrating attestation support into management stacks above libvirt, get a reference against which they can debug their own tools. * Users wanting to demonstrate the core SEV/SEV-ES functionality get a simple and reliable tool to illustrate the core concepts involved. Since I didn't fancy writing such complex logic in C, this tool is a python3 program. As such, we don't want to include it in the main libvirt-client RPM, nor any other existing RPM. THus, this series puts it in a new libvirt-client-qemu RPM which, through no co-inicidence at all, is the same RPM I invented a few days ago to hold the virt-qemu-qmp-proxy command. Note, people will have already seen an earlier version of this tool I hacked up some months ago. This code is very significantly changed since that earlier version, to make it more maintainable, and simpler to use (especially for SEV-ES) but the general theme is still the same. Changed in v2: - All the suggestions from Cole and Kashyap Daniel P. Berrangé (12): build-aux: only forbid gethostname in C files tools: support validating SEV firmware boot measurements tools: load guest config from libvirt tools: support validating SEV direct kernel boot measurements tools: load direct kernel config from libvirt tools: support validating SEV-ES initial vCPU state measurements tools: support automatically constructing SEV-ES vCPU state tools: load CPU count and CPU SKU from libvirt tools: support generating SEV secret injection tables docs/kbase: describe attestation for SEV guests scripts: add systemtap script for capturing SEV-ES VMSA docs/manpages: add checklist of problems for SEV attestation build-aux/syntax-check.mk | 1 + docs/kbase/launch_security_sev.rst | 105 ++ docs/manpages/meson.build | 1 + docs/manpages/virt-qemu-sev-validate.rst | 647 +++++++++++ examples/systemtap/amd-sev-es-vmsa.stp | 48 + libvirt.spec.in | 2 + tools/meson.build | 5 + tools/virt-qemu-sev-validate | 1292 ++++++++++++++++++++++ 8 files changed, 2101 insertions(+) create mode 100644 docs/manpages/virt-qemu-sev-validate.rst create mode 100644 examples/systemtap/amd-sev-es-vmsa.stp create mode 100755 tools/virt-qemu-sev-validate -- 2.37.3

4 24

[libvirt PATCH] build: drop LINUGAS sorting rule
by Ján Tomko 26 Oct '22

26 Oct '22

A recent merge request from Weblate adding a new file fails syntax-check because it adds a new language at the end of LINGUAS, instead of sorting it alphabetically. Rather than trying to work around it, drop this pointless rule. Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- build-aux/syntax-check.mk | 8 -------- 1 file changed, 8 deletions(-) diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk index e35c2be734..68cd9dff5f 100644 --- a/build-aux/syntax-check.mk +++ b/build-aux/syntax-check.mk @@ -1257,14 +1257,6 @@ sc_po_check: rm -f $@-1 $@-2; \ fi -linguas_file = $(top_srcdir)/po/LINGUAS - -sc_linguas_sorting: - @sort -u $(linguas_file) > $@-1; \ - diff -u -L $(linguas_file) -L $(linguas_file) $(linguas_file) $@-1 \ - || { echo "$(linguas_file) is not sorted correctly" 1>&2; exit 1; }; \ - rm -f $@-1 - # #if WITH_... will evaluate to false for any non numeric string. # That would be flagged by using -Wundef, however gnulib currently # tests many undefined macros, and so we can't enable that option. -- 2.37.3

3 2

[libvirt PATCH v3] cgroup/LXC: Do not condition availability of v2 by controllers
by Eric van Blokland 26 Oct '22

26 Oct '22

systemd in hybrid mode uses v1 hierarchies for controllers and v2 for process tracking. The LXC code uses virCgroupAddMachineProcess() to move processes into appropriate cgroup by manipulating cgroupfs directly. (Note, despite libvirt also supports talking to systemd directly via org.freedesktop.machine1 API.) If this path is taken, libvirt/lxc must convince systemd that processes really belong to new cgroup, i.e. also the tracking v2 hierarchy must undergo migration too. The current check would evaluate v2 backend as unavailable with hybrid mode (because there are no available controllers). Simplify the condition and consider the mounted cgroup2 as sufficient to touch v2 hierarchy. This consequently creates an issue with binding the V2 mount. In hybrid mode the V2 filesystem may be mounted upon the V1 filesystem. By reversing the order in which backends are mounted in virCgroupBindMount this problem is circumvented. Fixes: #182 Signed-off-by: Eric van Blokland <mail(a)ericvanblokland.nl> --- src/util/vircgroup.c | 8 +++++--- src/util/vircgroupv2.c | 12 ------------ 2 files changed, 5 insertions(+), 15 deletions(-) diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c index a6a409af3d..48fbcf625a 100644 --- a/src/util/vircgroup.c +++ b/src/util/vircgroup.c @@ -2924,9 +2924,11 @@ virCgroupBindMount(virCgroup *group, const char *oldroot, size_t i; virCgroup *parent = virCgroupGetNested(group); - for (i = 0; i < VIR_CGROUP_BACKEND_TYPE_LAST; i++) { - if (parent->backends[i] && - parent->backends[i]->bindMount(parent, oldroot, mountopts) < 0) { + /* In hybrid environments, V2 may be mounted over V1. + * Mount the backends in reverse order. */ + for (i = 1; i <= VIR_CGROUP_BACKEND_TYPE_LAST; i++) { + if (parent->backends[VIR_CGROUP_BACKEND_TYPE_LAST - i] && + parent->backends[VIR_CGROUP_BACKEND_TYPE_LAST - i]->bindMount(parent, oldroot, mountopts) < 0) { return -1; } } diff --git a/src/util/vircgroupv2.c b/src/util/vircgroupv2.c index 4c110940cf..0e0c61d466 100644 --- a/src/util/vircgroupv2.c +++ b/src/util/vircgroupv2.c @@ -75,22 +75,10 @@ virCgroupV2Available(void) if (STRNEQ(entry.mnt_type, "cgroup2")) continue; - /* Systemd uses cgroup v2 for process tracking but no controller is - * available. We should consider this configuration as cgroup v2 is - * not available. */ - contFile = g_strdup_printf("%s/cgroup.controllers", entry.mnt_dir); - - if (virFileReadAll(contFile, 1024 * 1024, &contStr) < 0) - goto cleanup; - - if (STREQ(contStr, "")) - continue; - ret = true; break; } - cleanup: VIR_FORCE_FCLOSE(mounts); return ret; } -- 2.35.3

4 8

[PATCH 0/5] node_device: Tiny code cleanups
by Michal Privoznik 26 Oct '22

26 Oct '22

My aim is to move virNodeDeviceDriver declaration into node_device_driver.c, eventually. BUT that's going to be more patches and as I continue my work on that I've noticed couple of almost trivial patches that can be merged regardless. Even during freeze ;-) Michal Prívozník (5): node_device_udev.h: Drop unused macro node_device: Move DMI_DEVPATH into node_device_udev.c node_device_udev.h: Drop include of libudev.h node_device: Move fwd declaration of udevNodeRegister() into correct header file node_device_driver.h: Drop nodeDeviceLock() and nodeDeviceUnlock() fwd declarations src/node_device/node_device_driver.c | 3 +++ src/node_device/node_device_driver.h | 12 ------------ src/node_device/node_device_udev.c | 2 ++ src/node_device/node_device_udev.h | 6 ++---- 4 files changed, 7 insertions(+), 16 deletions(-) -- 2.37.4

2 6

[libvirt RFC 00/24] basic snapshot delete implementation
by Pavel Hrdina 26 Oct '22

26 Oct '22

I'm sending it as RFC even though it's somehow completed and works, it probably needs some documentation and most likely unit testing. This implements virDomainSnapshotDelete API to support external snapshots. The support doesn't include flags VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN and VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY as it would add more complexity and IMHO these flags should not existed at all. The last patch is just here to show how we could support deleting external snapshot if all children are internal only, without this patch the user would have to call children-only and then with another call delete the external snapshot itself. There are some limitation that will be needing the mentioned documentation. If parent snapshot is internal the external snapshot cannot be deleted, workaround is to delete any internal parent snapshots and after that the external can be deleted. Pavel Hrdina (24): qemu_block: extract block commit code to separate function qemu_block: move qemuDomainBlockPivot out of qemu_driver qemu_block: extract qemuBlockCommit impl to separate function qemu_block: add sync option to qemuBlockCommitImpl qemu_monitor: introduce qemuMonitorJobFinalize qemu_monitor: allow setting autofinalize for block commit qemu_block: introduce qemuBlockFinalize qemu_blockjob: process QEMU_MONITOR_JOB_STATUS_PENDING signal qemu_snapshot: refactor qemuSnapshotDelete qemu_snapshot: extract single snapshot deletion to separate function qemu_snapshot: extract children snapshot deletion to separate function qemu_snapshot: rework snapshot children deletion qemu_snapshot: move snapshot discard out of qemu_domain.c qemu_snapshot: introduce qemuSnapshotDiscardMetadata qemu_snapshot: call qemuSnapshotDiscardMetadata from qemuSnapshotDiscard qemu_snapshot: pass update_parent into qemuSnapshotDiscardMetadata qemu_snapshot: move metadata changes to qemuSnapshotDiscardMetadata qemu_snapshot: introduce qemuSnapshotDeleteValidate function qemu_snapshot: refactor validation of snapshot delete qemu_snapshot: prepare data for external snapshot deletion qemu_snapshot: implement deletion of external snapshot qemu_snapshot: update metadata when deleting snapshots qemu_snapshot: when deleting snapshot invalidate parent snapshot qemu_snapshot: allow deletion of external snapshot with internal snapshot children src/conf/snapshot_conf.c | 5 + src/conf/snapshot_conf.h | 1 + src/qemu/qemu_backup.c | 1 + src/qemu/qemu_block.c | 356 ++++++++++++++++ src/qemu/qemu_block.h | 30 ++ src/qemu/qemu_blockjob.c | 13 +- src/qemu/qemu_blockjob.h | 1 + src/qemu/qemu_domain.c | 95 +---- src/qemu/qemu_domain.h | 9 - src/qemu/qemu_driver.c | 306 +------------- src/qemu/qemu_monitor.c | 21 +- src/qemu/qemu_monitor.h | 8 +- src/qemu/qemu_monitor_json.c | 26 +- src/qemu/qemu_monitor_json.h | 8 +- src/qemu/qemu_snapshot.c | 764 +++++++++++++++++++++++++++++++---- src/qemu/qemu_snapshot.h | 4 + tests/qemumonitorjsontest.c | 2 +- 17 files changed, 1151 insertions(+), 499 deletions(-) -- 2.37.2

2 52

[libvirt PATCH v2] Revert "cgroup/LXC: Do not condition availability of v2 by controllers"
by Pavel Hrdina 25 Oct '22

25 Oct '22

This reverts commit e49313b54ed2a149c71f9073659222742ff3ffb0. This reverts commit a0f37232b9c4296ca16955cc625f75eb848ace39. Revert them together to not break build. This fix of the issue is incorrect and breaks usage of other controllers in hybrid mode that systemd creates, specifically usage of devices and cpuacct controllers as they are now assumed to be part of the cgroup v2 topology which is not true. We need to find different solution to the issue. Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/util/vircgroup.c | 6 ++---- src/util/vircgroupv2.c | 15 +++++++++++++++ 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c index 49ebd37ded..a6a409af3d 100644 --- a/src/util/vircgroup.c +++ b/src/util/vircgroup.c @@ -2921,12 +2921,10 @@ int virCgroupBindMount(virCgroup *group, const char *oldroot, const char *mountopts) { - ssize_t i; + size_t i; virCgroup *parent = virCgroupGetNested(group); - /* In hybrid environments, V2 may be mounted over V1. - * Mount the backends in reverse order. */ - for (i = VIR_CGROUP_BACKEND_TYPE_LAST - 1; i >= 0; i--) { + for (i = 0; i < VIR_CGROUP_BACKEND_TYPE_LAST; i++) { if (parent->backends[i] && parent->backends[i]->bindMount(parent, oldroot, mountopts) < 0) { return -1; diff --git a/src/util/vircgroupv2.c b/src/util/vircgroupv2.c index bf6bd11fef..4c110940cf 100644 --- a/src/util/vircgroupv2.c +++ b/src/util/vircgroupv2.c @@ -69,13 +69,28 @@ virCgroupV2Available(void) return false; while (getmntent_r(mounts, &entry, buf, sizeof(buf)) != NULL) { + g_autofree char *contFile = NULL; + g_autofree char *contStr = NULL; + if (STRNEQ(entry.mnt_type, "cgroup2")) continue; + /* Systemd uses cgroup v2 for process tracking but no controller is + * available. We should consider this configuration as cgroup v2 is + * not available. */ + contFile = g_strdup_printf("%s/cgroup.controllers", entry.mnt_dir); + + if (virFileReadAll(contFile, 1024 * 1024, &contStr) < 0) + goto cleanup; + + if (STREQ(contStr, "")) + continue; + ret = true; break; } + cleanup: VIR_FORCE_FCLOSE(mounts); return ret; } -- 2.37.3

3 4

[libvirt PATCH 0/2] revert attempt fixing lxc with hybrid systemd cgroups
by Pavel Hrdina 25 Oct '22

25 Oct '22

Pavel Hrdina (2): Revert "vircgroup: Remove unused variables in virCgroupV2Available" Revert "cgroup/LXC: Do not condition availability of v2 by controllers" src/util/vircgroup.c | 6 ++---- src/util/vircgroupv2.c | 15 +++++++++++++++ 2 files changed, 17 insertions(+), 4 deletions(-) -- 2.37.3

2 3

Interface changed after 'started' event in hook
by Christopher Pereira 25 Oct '22

25 Oct '22

Hi, We have a libvirt-qemu hook script that intercepts the "started" event and configures the virtual network interface (we set a private IP, remove the interface from the virtual bridge and set some custom iptable rules). After upgrading from libvirt 3.2 to 4.5 we noticed that the interface is configured *after* the 'started' event is triggered and thus our custom configuration is overwritten (the IP we set is removed). As a workaround we added a "sleep 5" to our scripts which works, but we wonder what is the correct way to avoid libvirt to change the virtual interface after the 'started' event is triggered to keep our custom configuration. We have currently this setting: <interface type='bridge'> <mac address='*********'/> <source bridge='virbr0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> What would be the correct setting to avoid libvirt to change the interface after the hook is triggered?

2 1

[PATCH] node_device: fix missing return from function nodedevRegister
by jcfaracco＠gmail.com 25 Oct '22

25 Oct '22

From: Julio Faracco <jcfaracco(a)gmail.com> The function nodedevRegister() (or all register functions) requires an integer as a return. That function is not returning a value when UDEV is not set. This commit just adds a generic return for that specific case. Signed-off-by: Julio Faracco <jcfaracco(a)gmail.com> --- src/node_device/node_device_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/node_device/node_device_driver.c b/src/node_device/node_device_driver.c index 8e93b0dd6f..4d51851cfd 100644 --- a/src/node_device/node_device_driver.c +++ b/src/node_device/node_device_driver.c @@ -1584,6 +1584,8 @@ nodedevRegister(void) { #ifdef WITH_UDEV return udevNodeRegister(); +#else + return 0; #endif } -- 2.37.3

3 2

need directions for filling a bug report
by alexandru.iancu＠gmail.com 25 Oct '22

25 Oct '22

Hi everybody, I'm running a KVM linux hypervisor and a Windows guest. I'm passing through the GPU. From time to time, the guest crashes. I'd like to file a bug report. a) I'm aware of the many gitlab projects but I'm not sure which one can address this issue or should have a first look at and dispatch it. b) Windows dump is big(2G). I'm probably going to need to put it somewhere for inspection. Best regards, Alex

2 1

[PATCH v3 0/5] network: firewalld: fix routed network
by Eric Garver 25 Oct '22

25 Oct '22

This series fixes routed networks when a newer firewalld (>= 1.0.0) is present [1]. Firewalld 1.0.0 included a change that disallows implicit forwarding between zones [2]. libvirt was relying on this behavior to allow routed networks to function. Firewalld policies are added. Policies have been supported since firewalld 0.9.0. If the running firewall does not support policies, then it will fallback to the current zone only behavior. My goal is to get libvirt to a fully native firewalld backend; no iptables rules. This series is phase 1 of that effort. The next steps are: 1. introduce a "libvirt-nat" zone and policies - the current "libvirt" zone will become obsolete 2. go full native firewalld, do not use iptables directly - currently a hybrid of iptables + firewalld is used v3: - rebase, retest, resend v2: - keep existing libvirt zone as is - remove "<forward />" in libvirt-routed zone because this feature requires firewalld >= 0.9.0. Has no impact since the added policies allow forwarding libvirt-routed <--> ANY zone (including itself). - add probe for policies: virFirewallDGetPolicies(), virFirewallDPolicyExists() [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2055706 [2]: https://github.com/firewalld/firewalld/issues/177 Eric Garver (5): util: add virFirewallDGetPolicies() util: add virFirewallDPolicyExists() network: firewalld: add zone for routed networks network: firewalld: add policies for routed networks network: firewalld: add support for routed networks src/libvirt_private.syms | 2 + src/network/bridge_driver_linux.c | 11 +++- src/network/libvirt-routed-in.policy | 11 ++++ src/network/libvirt-routed-out.policy | 12 +++++ src/network/libvirt-routed.zone | 10 ++++ src/network/libvirt-to-host.policy | 20 ++++++++ src/network/meson.build | 20 ++++++++ src/util/virfirewalld.c | 72 +++++++++++++++++++++++++++ src/util/virfirewalld.h | 2 + 9 files changed, 159 insertions(+), 1 deletion(-) create mode 100644 src/network/libvirt-routed-in.policy create mode 100644 src/network/libvirt-routed-out.policy create mode 100644 src/network/libvirt-routed.zone create mode 100644 src/network/libvirt-to-host.policy -- 2.35.3

3 7

[libvirt PATCH 00/28] Synchronize x86 cpu features from qemu
by Tim Wiederhake 25 Oct '22

25 Oct '22

libvirt is missing support for some x86 cpu features supported by qemu. This series adds the missing cpu features to libvirt's feature map and adds a script to ease the detection of new features in the future. Support for amx-int8, amx-tile, and amx-bf16 is deliberately not included, as they were already proposed on the list[1]. [1] https://listman.redhat.com/archives/libvir-list/2022-September/234292.html Tim Wiederhake (28): cpu-data.py: Allow for more than child in feature nodes cpu_x86: Ignore alias names cpu: make x86 feature alias names machine readable cpu_map: Add script to sync from QEMU i386 cpu features cpu_map: Rename sync_qemu_i386.py cpu_map: Add missing x86 feature alias names cpu_map: Add missing x86 feature "sgx" cpu_map: Add missing x86 feature "sgxlc" cpu_map: Add missing x86 feature "sgx-exinfo" cpu_map: Add missing x86 feature "sgx1" cpu_map: Add missing x86 feature "sgx2" cpu_map: Add missing x86 feature "sgx-debug" cpu_map: Add missing x86 feature "sgx-mode64" cpu_map: Add missing x86 feature "sgx-provisionkey" cpu_map: Add missing x86 feature "sgx-tokenkey" cpu_map: Add missing x86 feature "sgx-kss" cpu_map: Add missing x86 feature "bus-lock-detect" cpu_map: Add missing x86 feature "pks" cpu_map: Add missing x86 feature "avx512-vp2intersect" cpu_map: Add missing x86 feature "avx512-fp16" cpu_map: Add missing x86 feature "serialize" cpu_map: Add missing x86 feature "tsx-ldtrk" cpu_map: Add missing x86 feature "arch-lbr" cpu_map: Add missing x86 feature "xfd" cpu_map: Add missing x86 feature "intel-pt-lip" cpu_map: Add missing x86 feature "avic" cpu_map: Add missing x86 feature "v-vmsave-vmload" cpu_map: Add missing x86 feature "vgif" src/cpu/cpu_x86.c | 10 +- src/cpu_map/sync_qemu_features_i386.py | 278 ++++++++++++++++++ ..._qemu_i386.py => sync_qemu_models_i386.py} | 0 src/cpu_map/x86_features.xml | 133 +++++++-- tests/cputestdata/cpu-data.py | 11 +- .../x86_64-cpuid-Atom-P5362-disabled.xml | 1 + .../x86_64-cpuid-Atom-P5362-guest.xml | 1 + .../x86_64-cpuid-Atom-P5362-host.xml | 1 + .../x86_64-cpuid-Core-i7-7600U-disabled.xml | 2 +- .../x86_64-cpuid-Core-i7-7600U-guest.xml | 1 + .../x86_64-cpuid-Core-i7-7600U-host.xml | 1 + .../x86_64-cpuid-Core-i7-7700-disabled.xml | 2 +- .../x86_64-cpuid-Core-i7-7700-guest.xml | 1 + .../x86_64-cpuid-Core-i7-7700-host.xml | 1 + .../x86_64-cpuid-Core-i7-8550U-disabled.xml | 2 +- .../x86_64-cpuid-Core-i7-8550U-guest.xml | 1 + .../x86_64-cpuid-Core-i7-8550U-host.xml | 1 + .../x86_64-cpuid-Core-i7-8700-disabled.xml | 2 +- .../x86_64-cpuid-Core-i7-8700-guest.xml | 2 + .../x86_64-cpuid-Core-i7-8700-host.xml | 2 + ...86_64-cpuid-EPYC-7502-32-Core-disabled.xml | 2 +- .../x86_64-cpuid-EPYC-7502-32-Core-guest.xml | 3 + .../x86_64-cpuid-EPYC-7502-32-Core-host.xml | 3 + ...86_64-cpuid-EPYC-7601-32-Core-disabled.xml | 2 +- .../x86_64-cpuid-EPYC-7601-32-Core-guest.xml | 3 + .../x86_64-cpuid-EPYC-7601-32-Core-host.xml | 3 + ...-cpuid-EPYC-7601-32-Core-ibpb-disabled.xml | 2 +- ..._64-cpuid-EPYC-7601-32-Core-ibpb-guest.xml | 3 + ...6_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml | 3 + ...-cpuid-Hygon-C86-7185-32-core-disabled.xml | 2 +- ..._64-cpuid-Hygon-C86-7185-32-core-guest.xml | 3 + ...6_64-cpuid-Hygon-C86-7185-32-core-host.xml | 3 + .../x86_64-cpuid-Ice-Lake-Server-disabled.xml | 2 +- .../x86_64-cpuid-Ice-Lake-Server-guest.xml | 2 + .../x86_64-cpuid-Ice-Lake-Server-host.xml | 2 + ...puid-Ryzen-7-1800X-Eight-Core-disabled.xml | 2 +- ...4-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml | 3 + ...64-cpuid-Ryzen-7-1800X-Eight-Core-host.xml | 3 + ...4-cpuid-Ryzen-9-3900X-12-Core-disabled.xml | 2 +- ...6_64-cpuid-Ryzen-9-3900X-12-Core-guest.xml | 3 + ...86_64-cpuid-Ryzen-9-3900X-12-Core-host.xml | 3 + .../x86_64-cpuid-Xeon-E3-1225-v5-disabled.xml | 2 +- .../x86_64-cpuid-Xeon-E3-1225-v5-guest.xml | 1 + .../x86_64-cpuid-Xeon-E3-1225-v5-host.xml | 1 + .../x86_64-cpuid-Xeon-E3-1245-v5-disabled.xml | 2 +- .../x86_64-cpuid-Xeon-E3-1245-v5-guest.xml | 1 + .../x86_64-cpuid-Xeon-E3-1245-v5-host.xml | 1 + .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 1 + .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 1 + .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 2 + .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 2 + .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 2 + 52 files changed, 487 insertions(+), 36 deletions(-) create mode 100755 src/cpu_map/sync_qemu_features_i386.py rename src/cpu_map/{sync_qemu_i386.py => sync_qemu_models_i386.py} (100%) -- 2.36.1

2 56

[PATCH] qemuAppendDomainMemoryMachineParams: Refactor formatting of 'dump-guest-core'
by Peter Krempa 25 Oct '22

25 Oct '22

Use virTristateSwitchFromBool to fill in the default if user didn't request it explicitly. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_command.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 150824f2e1..bb2a3ea82f 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -6625,15 +6625,13 @@ qemuAppendDomainMemoryMachineParams(virBuffer *buf, const virDomainDef *def, virQEMUCaps *qemuCaps) { + virTristateSwitch dump = def->mem.dump_core; size_t i; - if (def->mem.dump_core) { - virBufferAsprintf(buf, ",dump-guest-core=%s", - virTristateSwitchTypeToString(def->mem.dump_core)); - } else { - virBufferAsprintf(buf, ",dump-guest-core=%s", - cfg->dumpGuestCore ? "on" : "off"); - } + if (dump == VIR_TRISTATE_SWITCH_ABSENT) + dump = virTristateSwitchFromBool(cfg->dumpGuestCore); + + virBufferAsprintf(buf, ",dump-guest-core=%s", virTristateSwitchTypeToString(dump)); if (def->mem.nosharepages) virBufferAddLit(buf, ",mem-merge=off"); -- 2.37.3

2 1

[PATCH] docs: Update best practices wrt "Fixes:" and GitLab
by Michal Privoznik 25 Oct '22

25 Oct '22

We document that a commit fixing an issue tracked in GitLab should put just "Fixes: #NNN" into its commit message. But when viewing git log, having full URL which is directly clickable is more developer friendly and GitLab is capable of handling both. Therefore, document that users should put full URL, just like when fixing a bug tracked in other sites. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/best-practices.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/best-practices.rst b/docs/best-practices.rst index ba8478ab05..a4651c19d0 100644 --- a/docs/best-practices.rst +++ b/docs/best-practices.rst @@ -15,11 +15,11 @@ with minimal back-and-forth. by any longer description of why your patch makes sense. If the patch fixes a regression, and you know what commit introduced the problem, mentioning that is useful. If the patch resolves a - upstream bug reported in GitLab, put "Fixes: #NNN" in the commit - message. For a downstream bug, mention the URL of the bug instead. - In both cases also summarize the issue rather than making all - readers follow the link. You can use 'git shortlog -30' to get - an idea of typical summary lines. + upstream bug reported in GitLab, or downstream bug, put + "Resolves: $fullURL" of the bug. In both cases also summarize + the issue rather than making all readers follow the link. You + can use 'git shortlog -30' to get an idea of typical summary + lines. - Split large changes into a series of smaller patches, self-contained if possible, with an explanation of each patch -- 2.37.4

2 1

Re: [libvirt PATCH v3] cgroup/LXC: Do not condition availability of v2 by controllers
by Pavel Hrdina 24 Oct '22

24 Oct '22

On Mon, Oct 24, 2022 at 12:51:03PM +0000, Eric van Blokland wrote: > ------- Original Message ------- > On Monday, October 24th, 2022 at 1:54 PM, Pavel Hrdina <phrdina(a)redhat.com> wrote: > > > > On Sun, Oct 23, 2022 at 02:08:28PM +0200, Eric van Blokland wrote: > > > > > systemd in hybrid mode uses v1 hierarchies for controllers and v2 for > > > process tracking. > > > > > > The LXC code uses virCgroupAddMachineProcess() to move processes into > > > appropriate cgroup by manipulating cgroupfs directly. (Note, despite > > > libvirt also supports talking to systemd directly via > > > org.freedesktop.machine1 API.) > > > > > > If this path is taken, libvirt/lxc must convince systemd that processes > > > really belong to new cgroup, i.e. also the tracking v2 hierarchy must > > > undergo migration too. > > > > > > The current check would evaluate v2 backend as unavailable with hybrid > > > mode (because there are no available controllers). Simplify the > > > condition and consider the mounted cgroup2 as sufficient to touch v2 > > > hierarchy. > > > > > > This consequently creates an issue with binding the V2 mount. In hybrid > > > mode the V2 filesystem may be mounted upon the V1 filesystem. By reversing > > > the order in which backends are mounted in virCgroupBindMount this problem > > > is circumvented. > > > > > > Fixes: #182 > > > Signed-off-by: Eric van Blokland mail(a)ericvanblokland.nl > > > --- > > > src/util/vircgroup.c | 8 +++++--- > > > src/util/vircgroupv2.c | 12 ------------ > > > 2 files changed, 5 insertions(+), 15 deletions(-) > > > > > > diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c > > > index a6a409af3d..48fbcf625a 100644 > > > --- a/src/util/vircgroup.c > > > +++ b/src/util/vircgroup.c > > > @@ -2924,9 +2924,11 @@ virCgroupBindMount(virCgroup *group, const char *oldroot, > > > size_t i; > > > virCgroup *parent = virCgroupGetNested(group); > > > > > > - for (i = 0; i < VIR_CGROUP_BACKEND_TYPE_LAST; i++) { > > > - if (parent->backends[i] && > > > - parent->backends[i]->bindMount(parent, oldroot, mountopts) < 0) { > > > + /* In hybrid environments, V2 may be mounted over V1. > > > + * Mount the backends in reverse order. */ > > > > > > I don't understand what you mean by mounted over? > > > > In the hybrid environments I've seen V2 is mounted upon "/unified" in the V1 cgroup filesystem. What I've seen is that hybrid systemd environments have: /sys/fs/cgroup/unified /sys/fs/cgroup/memory /sys/fs/cgroup/blkio ... but it doesn't mean that it is mounted in V1 cgroup filesystem. In this case the /sys/fs/cgroup is tmpfs filesystem and there is nothing mounted over V1. In case you've managed to run into environment where unified is actually mounted inside cgroup filesystem then there is something else seriously broken. > > > + for (i = 1; i <= VIR_CGROUP_BACKEND_TYPE_LAST; i++) { > > > + if (parent->backends[VIR_CGROUP_BACKEND_TYPE_LAST - i] && > > > + parent->backends[VIR_CGROUP_BACKEND_TYPE_LAST - i]->bindMount(parent, oldroot, mountopts) < 0) { > > > return -1; > > > } > > > } > > > diff --git a/src/util/vircgroupv2.c b/src/util/vircgroupv2.c > > > index 4c110940cf..0e0c61d466 100644 > > > --- a/src/util/vircgroupv2.c > > > +++ b/src/util/vircgroupv2.c > > > @@ -75,22 +75,10 @@ virCgroupV2Available(void) > > > if (STRNEQ(entry.mnt_type, "cgroup2")) > > > continue; > > > > > > - /* Systemd uses cgroup v2 for process tracking but no controller is > > > - * available. We should consider this configuration as cgroup v2 is > > > - * not available. */ > > > - contFile = g_strdup_printf("%s/cgroup.controllers", entry.mnt_dir); > > > - > > > - if (virFileReadAll(contFile, 1024 * 1024, &contStr) < 0) > > > - goto cleanup; > > > - > > > - if (STREQ(contStr, "")) > > > - continue; > > > - > > > > > > I don't like this at all and IMO this is incorrect fix of the issue you > > are trying to address. In hybrid mode with systemd the cgroup v2 > > controller is not a real controller. It's something systemd uses for > > process tracking and some other features. It is owned by systemd and we > > should not touch it directly at all. We need to use proper systemd APIs > > to make any changes to that directory or if needed ask systemd to create > > cgroup with Delegate=yes which in this case is probably also not the > > correct approach. > > > > I must admit I'm a little in over my head here, but if I understand correctly, > there isn't anything done in the v2 backend in hybrid mode that wouldn't be done > in the v2 backend in unified mode. Does systemd behave differently or is the v2 > implementation in error in both hybrid and unified modes? > > Also in theory there could be a controller bound to the v2 hierarchy which would > activate the v2 backend anyway. So org.freedesktop.systemd1.Manager has method called AttachProcessesToUnit which would be most likely perfect for us for this specific case but it is not documented and from the commit message it was intended for internal use only. I'll ask systemd developers what the state is and if we could use it otherwise we might need to drop the check like this patch does. Pavel > > I know it was already pushed but I'll most likely revert this patch and > > we should find better and proper solution. > > > > Pavel > > > > I'd love to get suggestions for a better solution. > > Eric > > > > ret = true; > > > break; > > > } > > > > > > - cleanup: > > > VIR_FORCE_FCLOSE(mounts); > > > return ret; > > > } > > > -- > > > 2.35.3 >

1 0

[libvirt PATCH 0/7] ci: Integration test suite template fixes
by Erik Skultety 24 Oct '22

24 Oct '22

Failed job to demonstrate fixed log collecting: https://gitlab.com/eskultety/libvirt/-/pipelines/666789669 Successfull job with all patches applied: https://gitlab.com/eskultety/libvirt/-/pipelines/666906197 Erik Skultety (7): ci: integration: Add virtnetworkd to the list of restarted services ci: integration: Add an extra level of quoting for augeas set options ci: integration: Fix the test on avocado directory existence ci: integration: Only create a coredump log when a core exists ci: integration: Use 'set +e' in the log collecting job ci: integration: Create the avocado logs artifact dir conditionally ci: integration: Bundle only failed Avocado test results ci/integration-template.yml | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) -- 2.37.3

2 9

[libvirt PATCH 0/3] qemu: Fix canceling migration
by Jiri Denemark 24 Oct '22

24 Oct '22

This series fixes commit v8.7.0-57-g2d7b22b561 "qemu: Make qemuMigrationSrcCancel optionally synchronous" which was broken in several ways (although the overall idea was correct). Jiri Denemark (3): qemu_migration: Properly wait for migration to be canceled qemu: Do not crash when canceling migration on reconnect NEWS: Document daemon crash on reconnect NEWS.rst | 5 ++++ src/qemu/qemu_migration.c | 61 ++++++++++++++++++++++++++++----------- src/qemu/qemu_migration.h | 3 +- src/qemu/qemu_process.c | 4 +-- 4 files changed, 53 insertions(+), 20 deletions(-) -- 2.38.0

2 4

[PATCH] vircgroup: Remove unused variables in virCgroupV2Available
by Peter Krempa 24 Oct '22

24 Oct '22

After recent commit 'contFile' and 'contStr' became unused breaking build with clang: ../../../libvirt/src/util/vircgroupv2.c:72:26: error: unused variable 'contFile' [-Werror,-Wunused-variable] g_autofree char *contFile = NULL; ^ ../../../libvirt/src/util/vircgroupv2.c:73:26: error: unused variable 'contStr' [-Werror,-Wunused-variable] g_autofree char *contStr = NULL; ^ Fixes: a0f37232b9c4296ca16955cc625f75eb848ace39 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/util/vircgroupv2.c | 3 --- 1 file changed, 3 deletions(-) Pushed as a build fix. diff --git a/src/util/vircgroupv2.c b/src/util/vircgroupv2.c index 0e0c61d466..bf6bd11fef 100644 --- a/src/util/vircgroupv2.c +++ b/src/util/vircgroupv2.c @@ -69,9 +69,6 @@ virCgroupV2Available(void) return false; while (getmntent_r(mounts, &entry, buf, sizeof(buf)) != NULL) { - g_autofree char *contFile = NULL; - g_autofree char *contStr = NULL; - if (STRNEQ(entry.mnt_type, "cgroup2")) continue; -- 2.37.3

1 0

[PATCH v3 0/6] qemu: tpm: Add support for migration across shared storage
by Stefan Berger 24 Oct '22

24 Oct '22

This series of patches adds support for migrating vTPMs across hosts whose storage has been set up to share the directory structure holding the state of the TPM (swtpm). The existence of share storage influences the management of the directory structure holding the TPM state, which for example is only removed when a domain is undefined and not when a VM is removed on the migration source host. Further, when shared storage is used then security labeling on the destination side is skipped assuming that the labeling was already done on the source side. I have tested this with an NFS setup where I had to turn SELinux off on the hosts since the SELinux MLS range labeling is not supported by NFS. For shared storage support to work properly both sides of the migration need to be clients of the shared storage setup, meaning that they both have to have /var/lib/libvirt/swtpm mounted as shared storage, because other- wise the virFileIsSharedFS() may not detect shared storage and in the worst case may cause the TPM emulator (swtpm) to malfunction if for example the source side removed the TPM state directory structure. Shared storage migration requires (upcoming) swtpm v0.8. Stefan v3: - Relying entirely on virFileIsSharedFS() on migration source and destination sides to detect whether shared storage is set up between hosts; no more hint about shared storage from user via flag - Added support for virDomainTPMPrivate structure to store and persist TPM-related private data Stefan Berger (6): util: Add parsing support for swtpm's cmdarg-migration capability qemu: tpm: Conditionally create storage on incoming migration qemu: tpm: Add support for storing private TPM-related data qemu: tpm: Pass --migration option to swtpm if supported and needed qemu: tpm: Avoid security labels on incoming migration with shared storage qemu: tpm: Never remove state on outgoing migration and shared storage src/conf/domain_conf.c | 63 ++++++++++++++++++++-- src/conf/domain_conf.h | 9 ++++ src/qemu/qemu_domain.c | 85 +++++++++++++++++++++++++++-- src/qemu/qemu_domain.h | 17 +++++- src/qemu/qemu_driver.c | 20 +++---- src/qemu/qemu_extdevice.c | 10 ++-- src/qemu/qemu_extdevice.h | 6 ++- src/qemu/qemu_migration.c | 20 ++++--- src/qemu/qemu_process.c | 9 ++-- src/qemu/qemu_snapshot.c | 4 +- src/qemu/qemu_tpm.c | 111 ++++++++++++++++++++++++++++++++++---- src/qemu/qemu_tpm.h | 12 ++++- src/util/virtpm.c | 1 + src/util/virtpm.h | 1 + 14 files changed, 318 insertions(+), 50 deletions(-) -- 2.37.3

2 16

QEMU Advent Calendar 2022 Call for Images
by Eldon Stegall 22 Oct '22

22 Oct '22

Hi, We are working to make QEMU Advent Calendar 2022 happen this year, and if you have had an interesting experience with QEMU recently, we would love for you to contribute! QEMU invocations that showcase new functionality, something cool, bring back retro computing memories, or simply entertain with a puzzle or game are welcome. If you have an idea but aren't sure if it fits, email me and we can try to put something together. QEMU Advent Calendar publishes a QEMU disk image each day from December 1-24. Each image is a surprise designed to delight an audience consisting of the QEMU community and beyond. You can see previous years here: https://www.qemu-advent-calendar.org/ You can help us make this year's calendar awesome by: * Sending disk images ( or links to larger images ) * Replying with ideas for disk images (reply off-list to avoid spoilers!) If you have an idea after the start of the advent, go ahead and send it. We may find space to include it, or go ahead and get a jump on 2024! Here is the format we will work with you to create: * A name and a short description of the disk image (e.g. with hints on what to try) * A ./run shell script that prints out the name and description/hints and launches QEMU * A 320x240 screenshot/image/logo for the website Content must be freely redistributable (i.e. no proprietary license that prevents distribution). For GPL based software, you need to provide the source code, too. Check out this disk image as an example of how to distribute an image: https://www.qemu-advent-calendar.org/2018/download/day24.tar.xz PS: QEMU Advent Calendar is a secular calendar (not religious). The idea is to create a fun experience for the QEMU community which can be shared with everyone. You don't need to celebrate Christmas or another religious festival to participate! Thanks, and best wishes! Eldon

2 1