- Devel - libvirt List Archives

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

27 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 25 Oct '22

25 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 25 Oct '22

25 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 25 Oct '22

25 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