December 2022 - Devel - libvirt List Archives

[libvirt PATCH] docs: replace footer link to the bird site with mastodon
by Daniel P. Berrangé 14 Dec '22

14 Dec '22

Since the takeover of the bird site, the bulk of tech people who want a more friendly and inclusive media site have jumped over to Mastodon. With its decentralized nature, there's no one replacement that captures everything, but the fosstodon.org site is a topic relevant choice. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/page.xsl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/page.xsl b/docs/page.xsl index 1414d90b89..548d5a11c4 100644 --- a/docs/page.xsl +++ b/docs/page.xsl @@ -179,7 +179,7 @@ <div id="community"> <h3>Community</h3> <ul> - <li><a href="https://twitter.com/hashtag/libvirt">twitter</a></li> + <li><a href="https://fosstodon.org/tags/libvirt">fosstodon</a></li> <li><a href="https://stackoverflow.com/questions/tagged/libvirt">stackoverflow</a></li> <li><a href="https://serverfault.com/questions/tagged/libvirt">serverfault</a></li> </ul> -- 2.38.1

2 1

[PATCH] tests: qemucapabilitiesdata: Final update of qemu-7.2 capabilities on x86
by Peter Krempa 14 Dec '22

14 Dec '22

QEMU 7.2 was released, update the capabilities data to the final state. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- tests/qemucapabilitiesdata/caps_7.2.0.x86_64.replies | 6 +++--- tests/qemucapabilitiesdata/caps_7.2.0.x86_64.xml | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/qemucapabilitiesdata/caps_7.2.0.x86_64.replies b/tests/qemucapabilitiesdata/caps_7.2.0.x86_64.replies index 47203b8923..18f70a5a3f 100644 --- a/tests/qemucapabilitiesdata/caps_7.2.0.x86_64.replies +++ b/tests/qemucapabilitiesdata/caps_7.2.0.x86_64.replies @@ -17,11 +17,11 @@ { "return": { "qemu": { - "micro": 91, - "minor": 1, + "micro": 0, + "minor": 2, "major": 7 }, - "package": "v7.2.0-rc1" + "package": "v7.2.0" }, "id": "libvirt-2" } diff --git a/tests/qemucapabilitiesdata/caps_7.2.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_7.2.0.x86_64.xml index 6bc739065f..821fcd3199 100644 --- a/tests/qemucapabilitiesdata/caps_7.2.0.x86_64.xml +++ b/tests/qemucapabilitiesdata/caps_7.2.0.x86_64.xml @@ -201,10 +201,10 @@ <flag name='query-stats-schemas'/> <flag name='thread-context'/> <flag name='screenshot-format-png'/> - <version>7001091</version> + <version>7002000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>43100245</microcodeVersion> - <package>v7.2.0-rc1</package> + <package>v7.2.0</package> <arch>x86_64</arch> <hostCPU type='kvm' model='base' migratability='yes'> <property name='vmx-entry-load-rtit-ctl' type='boolean' value='false'/> -- 2.38.1

2 1

[PATCH 0/7] spec: Decompose the daemon subpackage
by Jim Fehlig 14 Dec '22

14 Dec '22

This is a V1 of my previous RFC to decompose the libvirt-daemon package https://listman.redhat.com/archives/libvir-list/2022-November/235924.html The end goal is to remove the libvirt-dameon dependency on the various libvirt-daemon-driver-foo subpackages, allowing installation of a modular daemon configuration without the traditional monolithic libvirtd. Change from V1: - Patches1-3 handled separate from this series since they are unrelated - virtlockd, virtlogd, and virtproxyd are moved to their own subpackages - lockd plugin moved to its own subpackage - virt-admin, virt-host-validate, and others moved to new subpackage TODO: The libvirt-daemon package still contains the following files, which likely need to move somewhere since they are needed by the modular daemons too. %{_unitdir}/virt-guest-shutdown.target I thought of moving this to the libs package, but that would be a change for installations with only libvirt-client. AFAICT, it's used by libvirt-guests and the qemu and lxc drivers. %config(noreplace) %{_sysconfdir}/sasl2/libvirt.conf Another file related to remote access. Should it go to libvirt-libs? %ghost %dir %{_rundir}/libvirt/ %ghost %dir %{_rundir}/libvirt/common/ %dir %attr(0755, root, root) %{_localstatedir}/lib/libvirt/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/images/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/filesystems/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/boot/ %dir %attr(0711, root, root) %{_localstatedir}/cache/libvirt/ %dir %attr(0755, root, root) %{_libdir}/libvirt/ %dir %attr(0755, root, root) %{_libdir}/libvirt/connection-driver/ These files and directories are needed by the modular daemons as well, right? Where should they go? libvirt-daemon-<hypervisor> or libvirt-daemon-driver-<hypervisor>? %{_datadir}/polkit-1/actions/org.libvirt.unix.policy %{_datadir}/polkit-1/actions/org.libvirt.api.policy %{_datadir}/polkit-1/rules.d/50-libvirt.rules More files related to access. libvirt-libs? Jim Fehlig (7): spec: Move virtlockd to a new subpackage libvirt-daemon-lock spec: Move virtlogd to a new subpackage libvirt-daemon-log spec: Move virtproxyd to a new subpackage libvirt-daemon-proxy spec: Move lockd plugin to a new subpackage libvirt-daemon-plugin-lockd spec: Move common files to a new subpackage libvirt-daemon-client spec: Remove libvirt-daemon dependecy from drivers spec: Remove libvirt-daemon dependency from hypervisor subpackages libvirt.spec.in | 274 ++++++++++++++++++++++++++++++++---------------- 1 file changed, 183 insertions(+), 91 deletions(-) -- 2.38.1

3 30

[PATCH] qemu_process: add tray changed event to queue in refresh disks
by Kristina Hanicova 13 Dec '22

13 Dec '22

There are some cases when the internal state of disks can change without qemu sending events about it (e.g. a disk can close during reset). In case this happens, we should emit an event about the modified disk. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1824722#c20 Signed-off-by: Kristina Hanicova <khanicov(a)redhat.com> --- src/qemu/qemu_process.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 5de55435d2..601e9694b6 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -8675,6 +8675,7 @@ qemuProcessRefreshDisks(virDomainObj *vm, qemuDomainObjPrivate *priv = vm->privateData; g_autoptr(GHashTable) table = NULL; size_t i; + virQEMUDriver *driver = QEMU_DOMAIN_PRIVATE(vm)->driver; if (qemuDomainObjEnterMonitorAsync(vm, asyncJob) == 0) { table = qemuMonitorGetBlockInfo(priv->mon); @@ -8697,14 +8698,26 @@ qemuProcessRefreshDisks(virDomainObj *vm, continue; if (info->removable) { + virObjectEvent *event = NULL; + int reason; + if (info->empty) virDomainDiskEmptySource(disk); if (info->tray) { - if (info->tray_open) + if (info->tray_open == disk->tray_status) + continue; + + if (info->tray_open) { + reason = VIR_DOMAIN_EVENT_TRAY_CHANGE_OPEN; disk->tray_status = VIR_DOMAIN_DISK_TRAY_OPEN; - else + } else { + reason = VIR_DOMAIN_EVENT_TRAY_CHANGE_CLOSE; disk->tray_status = VIR_DOMAIN_DISK_TRAY_CLOSED; + } + + event = virDomainEventTrayChangeNewFromObj(vm, disk->info.alias, reason); + virObjectEventStateQueue(driver->domainEventState, event); } } -- 2.38.1

2 1

[libvirt PATCH 0/2] qemu_migration: Fix p2p post-copy recovery
by Jiri Denemark 13 Dec '22

13 Dec '22

Jiri Denemark (2): qemu_migration: Move qemuMigrationSrcPerformResume up qemu_migration: Fix p2p post-copy recovery src/qemu/qemu_migration.c | 129 ++++++++++++++++++++------------------ 1 file changed, 68 insertions(+), 61 deletions(-) -- 2.39.0

2 4

[libvirt PATCH v3 00/18] Use nbdkit for http/ftp/ssh network drives in libvirt
by Jonathon Jongsma 13 Dec '22

13 Dec '22

This is the third version of this patch series. See https://bugzilla.redhat.com/show_bug.cgi?id=2016527 for more information about the goal, but the summary is that RHEL does not want to ship the qemu storage plugins for curl and ssh. Handling them outside of the qemu process provides several advantages such as reduced attack surface and stability. A quick summary of the code: - at startup I query to see whether nbdkit exists on the host and if so, I query which plugins/filters are installed. These capabilities are cached and stored in the qemu driver - When the driver prepares the domain, we go through each disk source and determine whether the nbdkit capabilities allow us to support this disk via nbdkit, and if so, we allocate a qemuNbdkitProcess object and stash it in the private data of the virStorageSource. - The presence or absence of this qemuNbdkitProcess data then indicates whether this disk will be served to qemu indirectly via nbdkit or directly - When we launch the qemuProcess, as part of the "external device start" step, I launch a ndkit process for each disk that is supported by nbdkit. - for devices which are served by an intermediate ndkit process, I change the qemu commandline in the following ways: - I no longer pass auth/cookie secrets to qemu (those are handled by nbdkit) - I replace the actual network URL of the remote disk source with the path to the nbdkit unix socket - We create a 'monitor' for the nbdkit process that watches to see whether the process exits. If it does, we pause the domain, attempt to restart nbdkit, and then resume the domain. Open questions - I think selinux will work once we add a policy for the /usr/sbin/nbdkit binary to allow it to be executed by libvirt, but for now it fails to execute nbdkit in enforcing mode. The current context for nbdkit (on fedora) is "system_u:object_r:bin_t:s0". When I temporarily change the context to something like qemu_exec_t, I am able to start nbdkit and the domain launches. Known shortcomings - creating disks (in ssh) still isn't supported. Changes in v3: - Various formatting fixes - Don't kill process in qemuNbdkitProcessFree() since we want the nbdkit daemon to continue running even if libvirt restarts. - Better detection and error reporting when starting the nbdkit process - Add monitoring for nbdkit process so that it can be restarted if if ever exits unexpectedly. Changes in v2: - split into multiple patches - added a build option for nbdkit_moddir - don't instantiate any secret / cookie props for disks that are being served by nbdkit since we don't send secrets to qemu anymore - ensure that nbdkit processes are started/stopped for the entire backing chain - switch to virFileCache-based capabilities for nbdkit so that we don't need to requery every time - switch to using pipes for communicating sensitive data to nbdkit - use pidfile support built into virCommand rather than nbdkit's --pidfile argument - added significantly more tests Jonathon Jongsma (18): schema: allow 'ssh' as a protocol for network disks qemu: Add functions for determining nbdkit availability qemu: expand nbdkit capabilities util: Allow virFileCache data to be any GObject qemu: implement basic virFileCache for nbdkit caps qemu: implement persistent file cache for nbdkit caps qemu: use file cache for nbdkit caps qemu: Add qemuNbdkitProcess qemu: add functions to start and stop nbdkit tests: add ability to test various nbdkit capabilities qemu: split qemuDomainSecretStorageSourcePrepare qemu: include nbdkit state in private xml qemu: use nbdkit to serve network disks if available tests: add tests for nbdkit invocation util: make virCommandSetSendBuffer testable qemu: pass sensitive data to nbdkit via pipe qemu: add test for authenticating a https network disk qemu: Monitor nbdkit process for exit build-aux/syntax-check.mk | 4 +- meson.build | 9 + meson_options.txt | 1 + po/POTFILES | 1 + src/conf/schemas/domaincommon.rng | 1 + src/libvirt_private.syms | 1 + src/qemu/meson.build | 1 + src/qemu/qemu_block.c | 162 ++- src/qemu/qemu_conf.c | 23 + src/qemu/qemu_conf.h | 7 + src/qemu/qemu_domain.c | 180 ++- src/qemu/qemu_domain.h | 4 + src/qemu/qemu_driver.c | 4 + src/qemu/qemu_extdevice.c | 48 + src/qemu/qemu_nbdkit.c | 1243 +++++++++++++++++ src/qemu/qemu_nbdkit.h | 120 ++ src/qemu/qemu_nbdkitpriv.h | 31 + src/qemu/qemu_process.c | 13 + src/util/vircommand.c | 19 +- src/util/vircommand.h | 8 + src/util/vircommandpriv.h | 4 + src/util/virfilecache.c | 14 +- src/util/virfilecache.h | 2 +- src/util/virutil.h | 2 +- tests/meson.build | 1 + .../disk-cdrom-network.args.disk0 | 7 + .../disk-cdrom-network.args.disk1 | 9 + .../disk-cdrom-network.args.disk1.pipe.1778 | 1 + .../disk-cdrom-network.args.disk2 | 9 + .../disk-cdrom-network.args.disk2.pipe.1780 | 1 + .../disk-network-http.args.disk0 | 7 + .../disk-network-http.args.disk1 | 6 + .../disk-network-http.args.disk2 | 7 + .../disk-network-http.args.disk2.pipe.1778 | 1 + .../disk-network-http.args.disk3 | 8 + .../disk-network-http.args.disk3.pipe.1780 | 1 + ...work-source-curl-nbdkit-backing.args.disk0 | 8 + ...e-curl-nbdkit-backing.args.disk0.pipe.1778 | 1 + .../disk-network-source-curl.args.1.pipe.1 | 1 + .../disk-network-source-curl.args.disk0 | 8 + ...k-network-source-curl.args.disk0.pipe.1778 | 1 + .../disk-network-source-curl.args.disk1 | 10 + ...k-network-source-curl.args.disk1.pipe.1780 | 1 + ...k-network-source-curl.args.disk1.pipe.1782 | 1 + ...isk-network-source-curl.args.disk1.pipe.49 | 1 + .../disk-network-source-curl.args.disk2 | 8 + ...k-network-source-curl.args.disk2.pipe.1782 | 1 + ...k-network-source-curl.args.disk2.pipe.1784 | 1 + ...isk-network-source-curl.args.disk2.pipe.51 | 1 + .../disk-network-source-curl.args.disk3 | 7 + .../disk-network-source-curl.args.disk4 | 7 + .../disk-network-ssh.args.disk0 | 7 + tests/qemunbdkittest.c | 294 ++++ ...sk-cdrom-network-nbdkit.x86_64-latest.args | 42 + .../disk-cdrom-network-nbdkit.xml | 1 + ...isk-network-http-nbdkit.x86_64-latest.args | 45 + .../disk-network-http-nbdkit.xml | 1 + ...rce-curl-nbdkit-backing.x86_64-latest.args | 38 + ...isk-network-source-curl-nbdkit-backing.xml | 45 + ...work-source-curl-nbdkit.x86_64-latest.args | 50 + .../disk-network-source-curl-nbdkit.xml | 1 + ...isk-network-source-curl.x86_64-latest.args | 54 + .../disk-network-source-curl.xml | 74 + ...disk-network-ssh-nbdkit.x86_64-latest.args | 36 + .../disk-network-ssh-nbdkit.xml | 1 + .../disk-network-ssh.x86_64-latest.args | 36 + tests/qemuxml2argvdata/disk-network-ssh.xml | 31 + tests/qemuxml2argvtest.c | 18 + tests/testutilsqemu.c | 27 + tests/testutilsqemu.h | 5 + 70 files changed, 2707 insertions(+), 116 deletions(-) create mode 100644 src/qemu/qemu_nbdkit.c create mode 100644 src/qemu/qemu_nbdkit.h create mode 100644 src/qemu/qemu_nbdkitpriv.h create mode 100644 tests/qemunbdkitdata/disk-cdrom-network.args.disk0 create mode 100644 tests/qemunbdkitdata/disk-cdrom-network.args.disk1 create mode 100644 tests/qemunbdkitdata/disk-cdrom-network.args.disk1.pipe.1778 create mode 100644 tests/qemunbdkitdata/disk-cdrom-network.args.disk2 create mode 100644 tests/qemunbdkitdata/disk-cdrom-network.args.disk2.pipe.1780 create mode 100644 tests/qemunbdkitdata/disk-network-http.args.disk0 create mode 100644 tests/qemunbdkitdata/disk-network-http.args.disk1 create mode 100644 tests/qemunbdkitdata/disk-network-http.args.disk2 create mode 100644 tests/qemunbdkitdata/disk-network-http.args.disk2.pipe.1778 create mode 100644 tests/qemunbdkitdata/disk-network-http.args.disk3 create mode 100644 tests/qemunbdkitdata/disk-network-http.args.disk3.pipe.1780 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl-nbdkit-backing.args.disk0 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl-nbdkit-backing.args.disk0.pipe.1778 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.1.pipe.1 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk0 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk0.pipe.1778 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk1 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk1.pipe.1780 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk1.pipe.1782 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk1.pipe.49 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk2 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk2.pipe.1782 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk2.pipe.1784 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk2.pipe.51 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk3 create mode 100644 tests/qemunbdkitdata/disk-network-source-curl.args.disk4 create mode 100644 tests/qemunbdkitdata/disk-network-ssh.args.disk0 create mode 100644 tests/qemunbdkittest.c create mode 100644 tests/qemuxml2argvdata/disk-cdrom-network-nbdkit.x86_64-latest.args create mode 120000 tests/qemuxml2argvdata/disk-cdrom-network-nbdkit.xml create mode 100644 tests/qemuxml2argvdata/disk-network-http-nbdkit.x86_64-latest.args create mode 120000 tests/qemuxml2argvdata/disk-network-http-nbdkit.xml create mode 100644 tests/qemuxml2argvdata/disk-network-source-curl-nbdkit-backing.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/disk-network-source-curl-nbdkit-backing.xml create mode 100644 tests/qemuxml2argvdata/disk-network-source-curl-nbdkit.x86_64-latest.args create mode 120000 tests/qemuxml2argvdata/disk-network-source-curl-nbdkit.xml create mode 100644 tests/qemuxml2argvdata/disk-network-source-curl.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/disk-network-source-curl.xml create mode 100644 tests/qemuxml2argvdata/disk-network-ssh-nbdkit.x86_64-latest.args create mode 120000 tests/qemuxml2argvdata/disk-network-ssh-nbdkit.xml create mode 100644 tests/qemuxml2argvdata/disk-network-ssh.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/disk-network-ssh.xml -- 2.37.3

5 46

[libvirt PATCH] qemu: Don't warn when releasing a released job
by Jiri Denemark 13 Dec '22

13 Dec '22

When qemuDomainObjReleaseAsyncJob is called when the current async job is already released we emit quite useless warning which was implemented to warn about releasing a job owned by another thread. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_domainjob.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_domainjob.c b/src/qemu/qemu_domainjob.c index 4d320f075e..8d958b9d21 100644 --- a/src/qemu/qemu_domainjob.c +++ b/src/qemu/qemu_domainjob.c @@ -647,7 +647,8 @@ qemuDomainObjReleaseAsyncJob(virDomainObj *obj) VIR_DEBUG("Releasing ownership of '%s' async job", virDomainAsyncJobTypeToString(obj->job->asyncJob)); - if (obj->job->asyncOwner != virThreadSelfID()) { + if (obj->job->asyncOwner != 0 && + obj->job->asyncOwner != virThreadSelfID()) { VIR_WARN("'%s' async job is owned by thread %llu", virDomainAsyncJobTypeToString(obj->job->asyncJob), obj->job->asyncOwner); -- 2.39.0

2 1

[libvirt PATCH] cpu: Improve debug message in virCPUGetVendorForModel
by Jiri Denemark 13 Dec '22

13 Dec '22

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/cpu/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c index 7f3caf7a27..c5de9fc95c 100644 --- a/src/cpu/cpu.c +++ b/src/cpu/cpu.c @@ -936,7 +936,7 @@ virCPUGetVendorForModel(virArch arch, { struct cpuArchDriver *driver; - VIR_DEBUG("arch=%s", virArchToString(arch)); + VIR_DEBUG("arch=%s model=%s", virArchToString(arch), model); if (!(driver = cpuGetSubDriver(arch))) return NULL; -- 2.39.0

2 1

[libvirt PATCH] qemu: Fix warning in qemuMigrationDstPostcopyFailed
by Jiri Denemark 13 Dec '22

13 Dec '22

The function is called even if QEMU reports migration as postcopy-paused, i.e., it's not migrating anymore. And while changing the warning, we can drop the part about unattended migration to make the warning shorter and consistent with qemuMigrationSrcPostcopyFailed. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_migration.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 81bb08c029..2e87db883e 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -1704,9 +1704,8 @@ qemuMigrationDstPostcopyFailed(virDomainObj *vm) reason == VIR_DOMAIN_RUNNING_POSTCOPY_FAILED) return; - VIR_WARN("Migration protocol failed during incoming migration of domain " - "%s, but QEMU keeps migrating; leaving the domain running, the " - "migration will be handled as unattended", vm->def->name); + VIR_WARN("Incoming migration of domain %s failed during post-copy; " + "leaving the domain running", vm->def->name); virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_POSTCOPY_FAILED); -- 2.39.0

2 1

[PATCH] meson: Provide default values for nonexistent xenlight pkgconfig vars
by Michal Privoznik 12 Dec '22

12 Dec '22

It may happen that xenlight pkgconfig file does not contain 'xenfirmwaredir' and/or 'libexec_bin' variables, which is okay and we have code that deals with this situation. But that code is executed when the queried value is an empty string. This may not always be the case and we should specifically set 'default_value' so that the empty string is returned if pkgconfig variable doesn't exist. Fixes: 968479adcfa5c49b29b7b6680dcaffde1408f044 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- meson.build | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meson.build b/meson.build index f9834a36c2..3d870d77db 100644 --- a/meson.build +++ b/meson.build @@ -1478,8 +1478,8 @@ if not get_option('driver_libxl').disabled() and conf.has('WITH_LIBVIRTD') libxl_dep = dependency('xenlight', version: '>=' + libxl_version, required: get_option('driver_libxl')) if libxl_dep.found() - libxl_firmware_dir = libxl_dep.get_variable(pkgconfig : 'xenfirmwaredir') - libxl_execbin = libxl_dep.get_variable(pkgconfig : 'libexec_bin') + libxl_firmware_dir = libxl_dep.get_variable(pkgconfig : 'xenfirmwaredir', default_value: '') + libxl_execbin = libxl_dep.get_variable(pkgconfig : 'libexec_bin', default_value: '') if libxl_firmware_dir != '' conf.set_quoted('LIBXL_FIRMWARE_DIR', libxl_firmware_dir) endif -- 2.37.4

2 1

[PATCH 00/11] Remove secure clearing of memory where it doesn't make sense
by Peter Krempa 12 Dec '22

12 Dec '22

In certain cases we tried to clear stuff which isn't secure and in other cases we clear the pointer but then pass the secret on the commandline. Remove the security theatre. Additionally all other instances which pass secret via RPC can be theoreticlaly removed as the secret is copied to/from and non-sanitized RPC buffer. We'd have to clear all RPC buffers though for this to be "properly" handled and not just security theater. Peter Krempa (11): virCryptoEncryptDataAESgnutls: Don't secure erase gnutls_datum_t structs virCryptoEncryptDataAESgnutls: Properly initialize data structures virCryptoEncryptDataAESgnutls: Restructure control flow virStorageBackendISCSISetAuth: Don't bother securely erasing password virStorageBackendISCSISetAuth: Use g_strndup to '\0' terminate data virStorageBackendISCSISetAuth: Refactor cleanup libxlMakeNetworkDiskSrc: Don't bother with secure erase of secrets libxlMakeNetworkDiskSrc: Refactor cleanup virStorageBackendRBDOpenRADOSConn: Don't log the RBD key datatypes: Register autoptr cleanup for virSecret virSecretGetSecretString: Refactor cleanup src/datatypes.h | 1 + src/libxl/libxl_conf.c | 24 +++++----------- src/storage/storage_backend_iscsi.c | 22 +++++---------- src/storage/storage_backend_rbd.c | 24 ++++++++++++---- src/util/vircrypto.c | 43 ++++++++++------------------- src/util/virsecret.c | 19 ++++--------- 6 files changed, 53 insertions(+), 80 deletions(-) -- 2.38.1

3 20

[libvirt PATCH] rpm: switch to using %mingw_find_lang
by Daniel P. Berrangé 12 Dec '22

12 Dec '22

We currently list the locale file paths via a wildcard in %files, but the normal pattern for mingw RPMs in Fedora is to use %mingw_find_lang. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- libvirt.spec.in | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 562baea52e..31ff8ea01e 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1355,6 +1355,8 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh %mingw_debug_install_post +%mingw_find_lang %{name} + %endif %check @@ -2181,7 +2183,7 @@ exit 0 %{_datadir}/libvirt/api/libvirt-lxc-api.xml %if %{with_mingw} -%files -n mingw32-libvirt +%files -n mingw32-libvirt -f mingw32-libvirt.lang %dir %{mingw32_sysconfdir}/libvirt/ %config(noreplace) %{mingw32_sysconfdir}/libvirt/libvirt.conf %config(noreplace) %{mingw32_sysconfdir}/libvirt/libvirt-admin.conf @@ -2212,7 +2214,6 @@ exit 0 %{mingw32_datadir}/libvirt/api/libvirt-admin-api.xml %{mingw32_datadir}/libvirt/cpu_map/*.xml %{mingw32_datadir}/libvirt/test-screenshot.png -%{mingw32_datadir}/locale/*/LC_MESSAGES/libvirt.mo %dir %{mingw32_includedir}/libvirt %{mingw32_includedir}/libvirt/libvirt.h %{mingw32_includedir}/libvirt/libvirt-common.h @@ -2239,7 +2240,7 @@ exit 0 %{mingw32_mandir}/man1/virt-pki-validate.1* %{mingw32_mandir}/man7/virkey*.7* -%files -n mingw64-libvirt +%files -n mingw64-libvirt -f mingw64-libvirt.lang %dir %{mingw64_sysconfdir}/libvirt/ %config(noreplace) %{mingw64_sysconfdir}/libvirt/libvirt.conf %config(noreplace) %{mingw64_sysconfdir}/libvirt/libvirt-admin.conf @@ -2270,7 +2271,6 @@ exit 0 %{mingw64_datadir}/libvirt/api/libvirt-admin-api.xml %{mingw64_datadir}/libvirt/cpu_map/*.xml %{mingw64_datadir}/libvirt/test-screenshot.png -%{mingw64_datadir}/locale/*/LC_MESSAGES/libvirt.mo %dir %{mingw64_includedir}/libvirt %{mingw64_includedir}/libvirt/libvirt.h %{mingw64_includedir}/libvirt/libvirt-common.h -- 2.38.1

2 1

[libvirt PATCH 0/3] Actually do secure erase with explicit_bzero
by Daniel P. Berrangé 12 Dec '22

12 Dec '22

If we're going to have a virSecureErase function, we might as well make it do secure erasure with currently available explicit_bzero in FreeBSD/Linux. While we're here, we should use it from the RPC code. The remaining hole in the RPC code is xdr_free which does not securely erase buffers. That's not easily fixed without dropping the RPC impl in favour of a custom one. Daniel P. Berrangé (3): util: implement secure erase with explicit_bzero rpc: fix buffer offset updates after decoding payload rpc: securely erase the message buffers meson.build | 1 + src/rpc/virnetmessage.c | 4 +++- src/util/virsecureerase.c | 6 ++++++ 3 files changed, 10 insertions(+), 1 deletion(-) -- 2.38.1

2 4

[PATCH] formatcaps: Update capabilities example
by Michal Privoznik 12 Dec '22

12 Dec '22

In the formatcaps.rst we give an example output of capabilities. Well, there are couple of issues with it: 1) We show <features/> nested under /capabilities/host/cpu. There's no such element and never was. 2) The ordering of elements is corrupted. 3) There is plenty of elements missing. Fix these by showing an actual output of 'virsh capabilities' as obtained on my machine. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/formatcaps.rst | 230 +++++++++++++++++++++++++++++++++----------- 1 file changed, 176 insertions(+), 54 deletions(-) diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst index 39b1fb78ac..f7e5342654 100644 --- a/docs/formatcaps.rst +++ b/docs/formatcaps.rst @@ -143,60 +143,182 @@ capabilities enabled in the chip and BIOS you will see: :: - <capabilities> - <host> - <cpu> - <arch>x86_64</arch> - <features> - <vmx/> - </features> - <model>core2duo</model> - <vendor>Intel</vendor> - <topology sockets="1" dies="1" cores="2" threads="1"/> - <feature name="lahf_lm"/> - <feature name='xtpr'/> - <pages unit='KiB' size='4'/> - <pages unit='KiB' size='2048'/> - <pages unit='KiB' size='1048576'/> - <microcode version='36'/> - <maxphysaddr mode='emulate' bits='46'/> - ... - </cpu> - <power_management> - <suspend_mem/> - <suspend_disk/> - <suspend_hybrid/> - </power_management> - </host> + <capabilities> -  - <guest> - <os_type>xen</os_type> - <arch name="x86_64"> - <wordsize>64</wordsize> - <domain type="xen"></domain> - <emulator>/usr/lib64/xen/bin/qemu-dm</emulator> - </arch> - <features> - </features> - </guest> + <host> + <uuid>7b55704c-29f4-11b2-a85c-9dc6ff50623f</uuid> + <cpu> + <arch>x86_64</arch> + <model>Skylake-Client-noTSX-IBRS</model> + <vendor>Intel</vendor> + <microcode version='236'/> + <signature family='6' model='142' stepping='12'/> + <counter name='tsc' frequency='2303997000' scaling='no'/> + <topology sockets='1' dies='1' cores='4' threads='2'/> + <maxphysaddr mode='emulate' bits='39'/> + <feature name='ds'/> + <feature name='acpi'/> + <feature name='ss'/> + <feature name='ht'/> + <feature name='tm'/> + <feature name='pbe'/> + <feature name='dtes64'/> + <feature name='monitor'/> + <feature name='ds_cpl'/> + <feature name='vmx'/> + <feature name='smx'/> + <feature name='est'/> + <feature name='tm2'/> + <feature name='xtpr'/> + <feature name='pdcm'/> + <feature name='osxsave'/> + <feature name='tsc_adjust'/> + <feature name='sgx'/> + <feature name='clflushopt'/> + <feature name='intel-pt'/> + <feature name='md-clear'/> + <feature name='stibp'/> + <feature name='arch-capabilities'/> + <feature name='ssbd'/> + <feature name='xsaves'/> + <feature name='sgx1'/> + <feature name='sgx-debug'/> + <feature name='sgx-mode64'/> + <feature name='sgx-provisionkey'/> + <feature name='sgx-tokenkey'/> + <feature name='pdpe1gb'/> + <feature name='invtsc'/> + <feature name='rdctl-no'/> + <feature name='ibrs-all'/> + <feature name='skip-l1dfl-vmentry'/> + <feature name='mds-no'/> + <feature name='tsx-ctrl'/> + <pages unit='KiB' size='4'/> + <pages unit='KiB' size='2048'/> + <pages unit='KiB' size='1048576'/> + </cpu> + <power_management> + <suspend_mem/> + </power_management> + <iommu support='yes'/> + <migration_features> + <live/> + <uri_transports> + <uri_transport>tcp</uri_transport> + <uri_transport>rdma</uri_transport> + </uri_transports> + </migration_features> + <topology> + <cells num='1'> + <cell id='0'> + <memory unit='KiB'>32498112</memory> + <pages unit='KiB' size='4'>6813808</pages> + <pages unit='KiB' size='2048'>2048</pages> + <pages unit='KiB' size='1048576'>1</pages> + <distances> + <sibling id='0' value='10'/> + </distances> + <cpus num='8'> + <cpu id='0' socket_id='0' die_id='0' core_id='0' siblings='0,4'/> + <cpu id='1' socket_id='0' die_id='0' core_id='1' siblings='1,5'/> + <cpu id='2' socket_id='0' die_id='0' core_id='2' siblings='2,6'/> + <cpu id='3' socket_id='0' die_id='0' core_id='3' siblings='3,7'/> + <cpu id='4' socket_id='0' die_id='0' core_id='0' siblings='0,4'/> + <cpu id='5' socket_id='0' die_id='0' core_id='1' siblings='1,5'/> + <cpu id='6' socket_id='0' die_id='0' core_id='2' siblings='2,6'/> + <cpu id='7' socket_id='0' die_id='0' core_id='3' siblings='3,7'/> + </cpus> + </cell> + </cells> + </topology> + <cache> + <bank id='0' level='3' type='both' size='8' unit='MiB' cpus='0-7'/> + </cache> + <secmodel> + <model>none</model> + <doi>0</doi> + </secmodel> + <secmodel> + <model>dac</model> + <doi>0</doi> + <baselabel type='kvm'>+77:+77</baselabel> + <baselabel type='qemu'>+77:+77</baselabel> + </secmodel> + </host> -  - <guest> - <os_type>hvm</os_type> - <arch name="i686"> - <wordsize>32</wordsize> - <domain type="xen"></domain> - <emulator>/usr/lib/xen/bin/qemu-dm</emulator> - <machine>pc</machine> - <machine>isapc</machine> - <loader>/usr/lib/xen/boot/hvmloader</loader> - </arch> - <features> - <cpuselection/> - <deviceboot/> - </features> - </guest> + <guest> + <os_type>hvm</os_type> + <arch name='x86_64'> + <wordsize>64</wordsize> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <machine maxCpus='255'>pc-i440fx-7.1</machine> + <machine canonical='pc-i440fx-7.1' maxCpus='255'>pc</machine> + <machine maxCpus='288'>pc-q35-5.2</machine> + <machine maxCpus='255'>pc-i440fx-2.12</machine> + <machine maxCpus='255'>pc-i440fx-2.0</machine> + <machine maxCpus='255'>pc-i440fx-6.2</machine> + <machine maxCpus='288'>pc-q35-4.2</machine> + <machine maxCpus='255'>pc-i440fx-2.5</machine> + <machine maxCpus='255'>pc-i440fx-4.2</machine> + <machine maxCpus='255'>pc-i440fx-5.2</machine> + <machine maxCpus='255' deprecated='yes'>pc-i440fx-1.5</machine> + <machine maxCpus='255'>pc-q35-2.7</machine> + <machine maxCpus='288'>pc-q35-7.1</machine> + <machine canonical='pc-q35-7.1' maxCpus='288'>q35</machine> + <machine maxCpus='255'>pc-i440fx-2.2</machine> + <machine maxCpus='255'>pc-i440fx-2.7</machine> + <machine maxCpus='288'>pc-q35-6.1</machine> + <machine maxCpus='255'>pc-q35-2.4</machine> + <machine maxCpus='288'>pc-q35-2.10</machine> + <machine maxCpus='1'>x-remote</machine> + <machine maxCpus='288'>pc-q35-5.1</machine> + <machine maxCpus='255' deprecated='yes'>pc-i440fx-1.7</machine> + <machine maxCpus='288'>pc-q35-2.9</machine> + <machine maxCpus='255'>pc-i440fx-2.11</machine> + <machine maxCpus='288'>pc-q35-3.1</machine> + <machine maxCpus='255'>pc-i440fx-6.1</machine> + <machine maxCpus='288'>pc-q35-4.1</machine> + <machine maxCpus='255'>pc-i440fx-2.4</machine> + <machine maxCpus='255'>pc-i440fx-4.1</machine> + <machine maxCpus='255'>pc-i440fx-5.1</machine> + <machine maxCpus='255'>pc-i440fx-2.9</machine> + <machine maxCpus='1'>isapc</machine> + <machine maxCpus='255' deprecated='yes'>pc-i440fx-1.4</machine> + <machine maxCpus='255'>pc-q35-2.6</machine> + <machine maxCpus='255'>pc-i440fx-3.1</machine> + <machine maxCpus='288'>pc-q35-2.12</machine> + <machine maxCpus='288'>pc-q35-7.0</machine> + <machine maxCpus='255'>pc-i440fx-2.1</machine> + <machine maxCpus='288'>pc-q35-6.0</machine> + <machine maxCpus='255'>pc-i440fx-2.6</machine> + <machine maxCpus='288'>pc-q35-4.0.1</machine> + <machine maxCpus='255'>pc-i440fx-7.0</machine> + <machine maxCpus='255' deprecated='yes'>pc-i440fx-1.6</machine> + <machine maxCpus='288'>pc-q35-5.0</machine> + <machine maxCpus='288'>pc-q35-2.8</machine> + <machine maxCpus='255'>pc-i440fx-2.10</machine> + <machine maxCpus='288'>pc-q35-3.0</machine> + <machine maxCpus='255'>pc-i440fx-6.0</machine> + <machine maxCpus='288'>pc-q35-4.0</machine> + <machine maxCpus='288'>microvm</machine> + <machine maxCpus='255'>pc-i440fx-2.3</machine> + <machine maxCpus='255'>pc-i440fx-4.0</machine> + <machine maxCpus='255'>pc-i440fx-5.0</machine> + <machine maxCpus='255'>pc-i440fx-2.8</machine> + <machine maxCpus='288'>pc-q35-6.2</machine> + <machine maxCpus='255'>pc-q35-2.5</machine> + <machine maxCpus='255'>pc-i440fx-3.0</machine> + <machine maxCpus='288'>pc-q35-2.11</machine> + <domain type='qemu'/> + <domain type='kvm'/> + </arch> + <features> + <acpi default='on' toggle='yes'/> + <apic default='on' toggle='no'/> + <cpuselection/> + <deviceboot/> + <disksnapshot default='on' toggle='no'/> + </features> + </guest> - ... - </capabilities> + </capabilities> -- 2.37.4

2 1

[PATCH] docs: Add missing elements to formatcaps.rst
by Nobuhiro MIKI 12 Dec '22

12 Dec '22

Signed-off-by: Nobuhiro MIKI <nmiki(a)yahoo-corp.jp> --- docs/formatcaps.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst index 9d7932a6a8..39b1fb78ac 100644 --- a/docs/formatcaps.rst +++ b/docs/formatcaps.rst @@ -155,6 +155,11 @@ capabilities enabled in the chip and BIOS you will see: <topology sockets="1" dies="1" cores="2" threads="1"/> <feature name="lahf_lm"/> <feature name='xtpr'/> + <pages unit='KiB' size='4'/> + <pages unit='KiB' size='2048'/> + <pages unit='KiB' size='1048576'/> + <microcode version='36'/> + <maxphysaddr mode='emulate' bits='46'/> ... </cpu> <power_management> -- 2.38.1

2 1

[PATCH RFC 0/6] spec: Decompose the daemon subpackage
by Jim Fehlig 11 Dec '22

11 Dec '22

Currently it is not possible to install a modular daemon subpackage without also installing the monolithic daemon https://listman.redhat.com/archives/libvir-list/2022-September/234554.html This series is an initial attempt at moving common daemons, utilities, and files from the daemon subpackage to a new daemon-core subpackage. The monolithic and modular daemons can then depend on the new subpackage. libvirt-guests is moved to a new libvirt-guests subpackage, which is recommended by the daemon subpackage to provide smoother upgrade. I've likely overlooked several items, but before continuing down this path too far I first wanted to gauge interest and see if this work is worth pursuing. If so, any comments on the RFC are appreciated! Note that patches 1-3 are things I noticed while working on the others and could be pushed independently. Jim Fehlig (6): spec: Remove redundant with_libxl spec: Use more %{name} macro spec: Remove daemon postun trigger spec: Move common daemons to a separate subpackage spec: Move more files to the daemon-core subpackage spec: Move libvirt-guests to guests subpackage libvirt.spec.in | 406 ++++++++++++++++++++++++++---------------------- 1 file changed, 219 insertions(+), 187 deletions(-) -- 2.37.3

3 14

[PATCH v2 0/2] virnetdevtap.c: Disallow pre-existing TAP devices
by Michal Privoznik 08 Dec '22

08 Dec '22

v2 of: https://listman.redhat.com/archives/libvir-list/2022-December/236197.html diff to v1: - Check for existing device iff virNetDevGenerateName() returned early (per Laine's suggestion). Michal Prívozník (2): virnetdev: Make virNetDevGenerateName() return 1 if no name was generated virnetdevtap.c: Disallow pre-existing TAP devices src/qemu/qemu_interface.c | 2 ++ src/util/virnetdev.c | 6 ++++-- src/util/virnetdevtap.c | 23 +++++++++++++++++++++-- src/util/virnetdevtap.h | 2 ++ 4 files changed, 29 insertions(+), 4 deletions(-) -- 2.37.4

2 3

[libvirt PATCH] tools: Fix style issues in virt-qemu-sev-validate
by Andrea Bolognani 08 Dec '22

08 Dec '22

The script had an incorrect interpreter line until commit f6a19d7264bb, so the flake8 check would not realize it needed to pick it up and these issues, some of which were present it the very first version that was committed, were not being reported. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- tools/virt-qemu-sev-validate | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/virt-qemu-sev-validate b/tools/virt-qemu-sev-validate index 46a92aa7a0..3d8b292fef 100755 --- a/tools/virt-qemu-sev-validate +++ b/tools/virt-qemu-sev-validate @@ -849,7 +849,7 @@ class ConfidentialVM(abc.ABC): secret64 = b64encode(secret_table_ciphertext).decode('utf8') log.debug("Header: %s (%d bytes)", header64, len(header)) log.debug("Secret: %s (%d bytes)", - secret64, len(secret_table_ciphertext)) + secret64, len(secret_table_ciphertext)) return header64, secret64 @@ -955,7 +955,7 @@ class LibvirtConfidentialVM(ConfidentialVM): self.dom = self.conn.lookupByName(id_name_uuid) log.debug("VM: id=%d name=%s uuid=%s", - self.dom.ID(), self.dom.name(), self.dom.UUIDString()) + self.dom.ID(), self.dom.name(), self.dom.UUIDString()) if not self.dom.isActive(): raise InvalidStateException( @@ -1331,5 +1331,6 @@ def main(): print("ERROR: %s" % e, file=sys.stderr) sys.exit(6) + if __name__ == "__main__": main() -- 2.38.1

3 3

[PATCH] virnetdevtap.c: Disallow pre-existing TAP devices
by Michal Privoznik 08 Dec '22

08 Dec '22

When starting a guest with <interface/> which has the target device name set (i.e. not generated by us), it may happen that the TAP device already exists. This then may lead to all sorts of problems. For instance: for <interface type='network'/> the TAP device is plugged into the network's bridge, but since the TAP device is persistent it remains plugged there even after the guest is shut off. We don't have a code that unplugs TAP devices from the bridge because TAP devices we create are transient, i.e. are removed automatically when QEMU closes their FD. The only exception is <interface type='ethernet'/> with <target managed='no'/> where we specifically want to let users use pre-created TAP device and basically not touch it at all. There's another reason for denying to use a pre-created TAP devices: if we ever have bug in TAP name generation, we may re-use a TAP device from another domain. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2144738 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_interface.c | 2 ++ src/util/virnetdevtap.c | 31 ++++++++++++++++++++++++++++++- src/util/virnetdevtap.h | 2 ++ 3 files changed, 34 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_interface.c b/src/qemu/qemu_interface.c index 4cc76e07a5..264d5e060c 100644 --- a/src/qemu/qemu_interface.c +++ b/src/qemu/qemu_interface.c @@ -461,6 +461,8 @@ qemuInterfaceEthernetConnect(virDomainDef *def, if (!net->ifname) template_ifname = true; + tap_create_flags |= VIR_NETDEV_TAP_CREATE_ALLOW_EXISTING; + if (virNetDevTapCreate(&net->ifname, tunpath, tapfd, tapfdSize, tap_create_flags) < 0) { goto cleanup; diff --git a/src/util/virnetdevtap.c b/src/util/virnetdevtap.c index 112a1e8b99..406339c583 100644 --- a/src/util/virnetdevtap.c +++ b/src/util/virnetdevtap.c @@ -148,12 +148,15 @@ virNetDevTapGetRealDeviceName(char *ifname G_GNUC_UNUSED) * @tunpath: path to the tun device (if NULL, /dev/net/tun is used) * @tapfds: array of file descriptors return value for the new tap device * @tapfdSize: number of file descriptors in @tapfd - * @flags: OR of virNetDevTapCreateFlags. Only one flag is recognized: + * @flags: OR of virNetDevTapCreateFlags. Only the following flags are + * recognized: * * VIR_NETDEV_TAP_CREATE_VNET_HDR * - Enable IFF_VNET_HDR on the tap device * VIR_NETDEV_TAP_CREATE_PERSIST * - The device will persist after the file descriptor is closed + * VIR_NETDEV_TAP_CREATE_ALLOW_EXISTING + * - The device creation fails if @ifname already exists * * Creates a tap interface. The caller must use virNetDevTapDelete to * remove a persistent TAP device when it is no longer needed. In case @@ -182,6 +185,19 @@ int virNetDevTapCreate(char **ifname, if (virNetDevGenerateName(ifname, VIR_NET_DEV_GEN_NAME_VNET) < 0) return -1; + if (!(flags & VIR_NETDEV_TAP_CREATE_ALLOW_EXISTING)) { + int rc = virNetDevExists(*ifname); + + if (rc < 0) { + return -1; + } else if (rc > 0) { + virReportError(VIR_ERR_OPERATION_INVALID, + _("The %s interface already exists"), + *ifname); + return -1; + } + } + if (!tunpath) tunpath = "/dev/net/tun"; @@ -319,6 +335,19 @@ int virNetDevTapCreate(char **ifname, if (virNetDevGenerateName(ifname, VIR_NET_DEV_GEN_NAME_VNET) < 0) return -1; + if (!(flags & VIR_NETDEV_TAP_CREATE_ALLOW_EXISTING)) { + int rc = virNetDevExists(*ifname); + + if (rc < 0) { + return -1; + } else if (rc > 0) { + virReportError(VIR_ERR_OPERATION_INVALID, + _("The %s interface already exists"), + *ifname); + return -1; + } + } + /* As FreeBSD determines interface type by name, * we have to create 'tap' interface first and * then rename it to 'vnet' diff --git a/src/util/virnetdevtap.h b/src/util/virnetdevtap.h index 197ea10f94..c9d29c0384 100644 --- a/src/util/virnetdevtap.h +++ b/src/util/virnetdevtap.h @@ -56,6 +56,8 @@ typedef enum { VIR_NETDEV_TAP_CREATE_USE_MAC_FOR_BRIDGE = 1 << 2, /* The device will persist after the file descriptor is closed */ VIR_NETDEV_TAP_CREATE_PERSIST = 1 << 3, + /* The device is allowed to exist before creation */ + VIR_NETDEV_TAP_CREATE_ALLOW_EXISTING = 1 << 4, } virNetDevTapCreateFlags; int -- 2.37.4

2 1

[libvirt PATCH 00/21] meson: remove many obsolete checks
by Daniel P. Berrangé 08 Dec '22

08 Dec '22

We have alot of checks for Linux kernel features that are obsolete since our supported platform matrix lets us assume new enough kernel versions. Removing the checks will speed up the meson phase and reduce the tangle of #ifdefs in the code. I thought I could remove the check for linux/kvm.h but for some reason our code in virhostpcu.c / cpu_x86.c is enabling the codebases even on FreeBSD, which I find kind of odd. Does FreeBSD really ship a linux/kvm.h ? Daniel P. Berrangé (21): meson: remove obsolete check for LOOP_CTL_GET_FREE meson: remove obsolete check for EPOLL_CLOEXEC meson: remove obsolete check for LO_FLAGS_AUTOCLEAR meson: drop check for unshare() netdev: simplify check for ethtool functionality meson: remove obsolete check for ETHTOOL_GGSO meson: remove obsolete check for ETHTOOL_GGRO meson: remove obsolete check for ETHTOOL_GFLAGS meson: remove obsolete check for ETH_FLAG_LRO meson: remove obsolete check for ETH_FLAG_TXVLAN/RXVLAN meson: remove obsolete check for ETH_FLAG_NTUPLE meson: remove obsolete check for ETH_FLAG_RXHASH meson: remove obsolete check for ETHTOOL_GFEATURES meson: remove obsolete check for ETHTOOL_GCOALESCE meson: remove obsolete check for GET_VLAN_VID_CMD meson: simplify check for virnetdevbridge.c headers meson: remove obsolete check for DEVLINK_CMD_ESWITCH_GET meson: remove obsolete check for linux/magic.h meson: remove obsolete check for VHOST_VSOCK_SET_GUEST_CID meson: remove obsolete check for BPF_PROG_QUERY meson: remove obsolete check for BPF_CGROUP_DEVICE meson.build | 82 +++-------------------------------- src/util/virbpf.c | 6 +-- src/util/virbpf.h | 6 +-- src/util/vircgroupv2devices.c | 10 ++--- src/util/virfile.c | 15 ++----- src/util/virnetdev.c | 65 ++++----------------------- src/util/virvsock.c | 4 +- tests/securityselinuxhelper.c | 4 +- tests/virfilemock.c | 2 +- 9 files changed, 32 insertions(+), 162 deletions(-) -- 2.38.1

3 25

[libvirt PATCH 0/2] virt-qemu-sev-validate: A couple of small fixes
by Andrea Bolognani 08 Dec '22

08 Dec '22

Andrea Bolognani (2): docs: Fix typo in virt-qemu-sev-validate(1) tools: Fix interpreter for virt-qemu-sev-validate docs/manpages/virt-qemu-sev-validate.rst | 2 +- tools/virt-qemu-sev-validate | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.38.1

2 3

RFC: New APIs for delegation of privileged operations
by Andrea Bolognani 08 Dec '22

08 Dec '22

Hi, this is a proposal for introducing a new family of APIs in libvirt, with the goal of improving integration with management applications. KubeVirt is intended to be the primary consumer of these APIs. Background ---------- KubeVirt makes it possible to run VMs on a Kubernetes cluster, side by side with containers. It does so by running QEMU and libvirtd themselves inside a container. The architecture is explained in more detail at https://kubevirt.io/user-guide/architecture/ but for the purpose of this discussion we only need to keep in mind two components: * virt-launcher - runs in the same container as QEMU and libvirtd - one instance per VM * virt-handler - runs in a separate container - one instance per node Conceptually, these two components roughly map to QEMU processes and libvirtd respectively. >From a security perspective, there is a strong push in Kubernetes to run workloads under unprivileged user accounts and without additional capabilities. Again, this is similar to how libvirtd itself runs as root but the QEMU processes it starts are under the unprivileged "qemu" account. KubeVirt has been working towards the goal of running VMs as completely unprivileged workloads and made excellent progress so far. Some of the operations needed for running a VM, however, inherently require elevated privilege. In KubeVirt, the conundrum is solved by having virt-handler (a privileged component) take care of those operations, making it possible for virt-launcher (as well as QEMU and libvirtd) to run in an unprivileged context. Examples -------- Here are a few examples of how KubeVirt has been able to reduce the privilege required by virt-launcher by selectively handing over responsibilities to virt-handler: * Remove SYS_RESOURCE capability from launcher pod https://github.com/kubevirt/kubevirt/pull/2584 * Drop SYS_RESOURCE capability https://github.com/kubevirt/kubevirt/pull/5558 * Housekeeping cgroup https://github.com/kubevirt/kubevirt/pull/8233 * Real time VMs fail to change vCPU scheduler and priority in non-root deployments https://github.com/kubevirt/kubevirt/pull/8750 * virt-launcher: Drop SYS_PTRACE capability https://github.com/kubevirt/kubevirt/pull/8842 The pattern we can see is that, initially, libvirt just assumes that it can perform a certain privileged operation. This fails in the context of KubeVirt, where libvirtd runs with significantly reduced privileges. As a consequence, libvirt is patched to be more resilient to such lack of privilege: for example, instead of attempting to create a file and erroring out due to lack of permissions, it will instead first check whether the file already exists and, if it does, assume that it has been prepared ahead of time by an external entity. Limitations ----------- This approach works fine, but only for the privileged operations that would be performed by libvirt before the VM starts running. Looking at the "housekeeping cgroup" PR in particular, we notice that the VM is initially created in paused state: this is necessary in order to create a point in time in which all the VM threads already exist but, crucially, none of the vCPUs have stated running yet. This is the only opportunity to move threads across cgroups without invalidating the expectations of a real time workload. When it comes to live migration, however, there is no way to create similar conditions, since the VM is running on the destination host right out of the gate. As a consequence, live migration has to be blocked when the housekeeping cgroup is in use, which is an unfortunate limitation. Moreover, there's an overall sense of fragility surrounding these interactions: both KubeVirt and, to some extent, libvirt need to be acutely aware of what the other component is going to do, but there is never an explicit handover and the whole thing only works if you just so happen to do everything with the exact right order and timing. Proposal -------- In order to address the issues outlined above, I propose that we introduce a new set of APIs in libvirt. These APIs would expose some of the inner workings of libvirt, and as such would come with *massively reduced* stability guarantees compared to the rest of our public API. The idea is that applications such as KubeVirt, which track libvirt fairly closely and stay pinned to specific versions, would be able to adapt to changes in these APIs relatively painlessly. More traditional management applications such as virt-manager would simply not opt into using the new APIs and maintain the status quo. Using memlock as an example, the new API could look like typedef int (*virInternalSetMaxMemLockHandler)(pid_t pid, unsigned long long bytes); int virInternalSetProcessSetMaxMemLockHandler(virConnectPtr conn, virInternalSetMaxMemLockHandler handler); The application-provided handler would be responsible for performing the privileged operation (in this case raising the memlock limit for a process). For KubeVirt, virt-launcher would have to pass the baton to virt-handler. If such an handler is installed, libvirt would invoke it (and likely go through some sanity checks afterwards); if not, it would attempt to perform the privileged operation itself, as it does today. This would make the interaction between libvirt and the management application explicit rather than implicit. Not having to stick to our usual API stability guarantees would make it possible to be more liberal in exposing the internals of libvirt as interaction points. Scope ----- I think we should initially limit the new APIs to the scenarios that have already been identified, then gradually expand the scope as needed. In other words, we shouldn't comb through the codebase looking for potential adopters. Since the intended consumers of these APIs are those that can adopt a new libvirt release fairly quickly, this shouldn't be a problem. Once the pattern has been established, we might consider introducing support for it at the same time as a new feature that might benefit from it is added. Caveats ------- libvirt is all about stable API, so introducing an API that is unstable *by design* is completely uncharted territory. To ensure that the new APIs are 100% opt-in, we could define them in a separate <libvirt/libvirt-internal.h> header. Furthermore, we could have a separate libvirt-internal.so shared library for the symbols and a corresponding libvirt-internal.pc pkg-config file. We could even go as far as requiring a preprocessor symbol such as VIR_INTERNAL_UNSTABLE_API_OPT_IN to be defined before the entry points are visible to the compiler. Whatever the mechanism, we would need to make sure that it's usable from language bindings as well. Internal APIs are amendable to not only come and go, but also change semantics between versions. We should make sure that such changes are clearly exposed to the user, for example by requiring them to pass a version number to the function and erroring out immediately if the value doesn't match our expectations. KubeVirt has a massive suite of functional tests, so this kind of change would immediately be spotted when a new version of libvirt is imported, with no risk of an incompatibility lingering in the codebase until it affects users. Disclaimer ---------- This proposal is intentionally vague on several of the details. Before attempting to nail those down, I want to gather feedback on the high-level idea, both from the libvirt and KubeVirt side. Credits ------- Thanks to Michal and Martin for helping shape and polish the idea from its initial rough state. -- Andrea Bolognani / Red Hat / Virtualization

7 15

[PATCH] tools: Fix install_mode for some scripts
by Michal Privoznik 08 Dec '22

08 Dec '22

Scripts from the following list were installed with group write bit set: virt-xml-validate, virt-pki-validate, virt-sanlock-cleanup, libvirt-guests.sh. This is very unusual and in contrast with the way other scripts/binaries are installed. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2151202 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- tools/meson.build | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/meson.build b/tools/meson.build index c41c619af4..fad7f202ad 100644 --- a/tools/meson.build +++ b/tools/meson.build @@ -249,7 +249,7 @@ configure_file( configuration: tools_conf, install: true, install_dir: bindir, - install_mode: 'rwxrwxr-x', + install_mode: 'rwxr-xr-x', ) configure_file( @@ -258,7 +258,7 @@ configure_file( configuration: tools_conf, install: true, install_dir: bindir, - install_mode: 'rwxrwxr-x', + install_mode: 'rwxr-xr-x', ) executable( @@ -295,7 +295,7 @@ if conf.has('WITH_SANLOCK') configuration: tools_conf, install: true, install_dir: sbindir, - install_mode: 'rwxrwxr-x', + install_mode: 'rwxr-xr-x', ) endif @@ -311,7 +311,7 @@ if conf.has('WITH_LIBVIRTD') configuration: tools_conf, install: true, install_dir: libexecdir, - install_mode: 'rwxrwxr-x', + install_mode: 'rwxr-xr-x', ) if init_script == 'systemd' -- 2.37.4

3 2

Release of libvirt-php-0.5.7
by Michal Prívozník 07 Dec '22

07 Dec '22

The 0.5.7 release of libvirt-php is tagged and tarball is available at: https://libvirt.org/sources/php/ Notable changes: * Dropped support for PHP-6.0 and older * Fixed libvirt_connect_get_machine_types() with PHP-7.0 and newer * Dropped imagick dependency * Bug fixes Thanks to everybody who helped with this release. Michal

1 0

[PATCH v4] virsh: Add message to terminal when running snapshot-revert
by Haruka Ohata 07 Dec '22

07 Dec '22

When running virsh snapshot-* command, such as snapshot-create-as / snapshot-delete, it prints a result message. On the other hand virsh snapshot-revert command doesn't print a result message. So, This patch fixes to add message when running virsh snapshot-revert command. --- # virsh snapshot-create-as vm1 test1 Domain snapshot test01 created # virsh snapshot-revert vm1 test1 # virsh snapshot-delete vm1 test1 Domain snapshot test01 deleted # --- Signed-off-by: Haruka Ohata <ohata.haruka(a)fujitsu.com> --- tests/virsh-snapshot | 3 +++ tools/virsh-snapshot.c | 4 ++++ 2 files changed, 7 insertions(+) diff --git a/tests/virsh-snapshot b/tests/virsh-snapshot index 4c64bb537b..b09273917b 100755 --- a/tests/virsh-snapshot +++ b/tests/virsh-snapshot @@ -100,11 +100,14 @@ Domain snapshot s1 created Domain snapshot s3 created Domain snapshot s2 created +Domain snapshot s3 reverted Domain snapshot s6 created Domain snapshot s5 created +Domain snapshot s6 reverted Domain snapshot s4 created +Domain snapshot s1 reverted Domain snapshot s7 created Domain snapshot s8 created diff --git a/tools/virsh-snapshot.c b/tools/virsh-snapshot.c index 8fa64ba903..68908cd10a 100644 --- a/tools/virsh-snapshot.c +++ b/tools/virsh-snapshot.c @@ -1783,6 +1783,10 @@ cmdDomainSnapshotRevert(vshControl *ctl, const vshCmd *cmd) result = virDomainRevertToSnapshot(snapshot, flags); } + if (result < 0) + vshError(ctl, _("Failed to revert snapshot %s"), name); + else + vshPrintExtra(ctl, _("Domain snapshot %s reverted\n"), name); return result >= 0; } -- 2.38.1

2 1