- Devel - libvirt List Archives

[libvirt] [PATCH 0/5] Support embedding the QEMU driver in client apps directly
by Daniel P. Berrangé 27 May '19

27 May '19

This patch series proposes a new way to build a "libvirt QEMU shim" which supports more use cases than the previous approach from last year, as well as being vastly simpler to implement. Specifically - We can use this to embed the QEMU driver in unit tests allowing the full range of odriver functionality to be exercised during *unit* testing without interfering with the host OS libvirtd. - Apps like libguestfs can embed the QEMU driver to allow them to spawn VMs that are immediate children of their app, thus inheriting process context, as well as hiding these "service VM" from the main libvirtd. This would avoid a common irritation where libguestfs VMs suddenly appear & disappear in virt-manager's VM list. - Apps like kubevirt could use this to eliminate the need to use the RPC layer for libvirt. It can directly embed the QEMU driver giving it more direct control over how it is run & again inheriting process state. This is useful for kubevirt's one VM per container model where Kubernetes itself provides the aggregated view, thus making libvirtd's aggregated view redundant - The previous shim was very much one shim == one QEMU process. This new embed approach supports that of course, but there's also the option to run multiple VMs if desired. - Using a virtual root directory for QEMU driver state meams we do not need to solve the hard refactoring problem of getting the main libvirtd to detect the VMs launched via the shim. They can safely live independantly. - Thanks to the driver refactoring work it is still possible for the embedded drivers to talk to main libvirtd to use the secondary drivers for storage/network/etc if needed. Ideally we would allow those secondary drivers to be embedded too but that's not implemented here. Most important would be the secrets driver. Other drivers are much less important. Daniel P. Berrangé (5): access: report an error if no access manager is present libvirt: pass a root directory path into drivers qemu: honour the root parameter during driver initialization libvirt: support an "embed" URI path selector for QEMU driver qemu: introduce a new style libvirt_qemu_shim program src/access/viraccessmanager.c | 5 ++ src/driver-state.h | 1 + src/interface/interface_backend_netcf.c | 1 + src/interface/interface_backend_udev.c | 1 + src/libvirt.c | 41 ++++++++++++++- src/libvirt_internal.h | 1 + src/libxl/libxl_driver.c | 1 + src/lxc/lxc_driver.c | 2 + src/network/bridge_driver.c | 1 + src/node_device/node_device_hal.c | 1 + src/node_device/node_device_udev.c | 1 + src/nwfilter/nwfilter_driver.c | 1 + src/qemu/Makefile.inc.am | 7 +++ src/qemu/qemu_conf.c | 41 +++++++++------ src/qemu/qemu_conf.h | 3 +- src/qemu/qemu_driver.c | 9 ++-- src/qemu/qemu_shim.c | 70 +++++++++++++++++++++++++ src/remote/remote_daemon.c | 1 + src/remote/remote_driver.c | 8 +++ src/secret/secret_driver.c | 1 + src/storage/storage_driver.c | 1 + src/vz/vz_driver.c | 1 + 22 files changed, 179 insertions(+), 20 deletions(-) create mode 100644 src/qemu/qemu_shim.c -- 2.21.0

3 11

[libvirt] [glib PATCH 0/2] Simplify autogen.sh & get rid of our own gtk-doc.make
by Fabiano Fidêncio 24 May '19

24 May '19

Let's use a similiar autogen.sh as the one used by libosinfo and, with the change, let's also drop our own crafted gtk-doc.make (as we'll be using gtkdocize to generate the file). Fabiano Fidêncio (2): autogen.sh: Simplify autogen.sh gtk-doc.make: Remove the file .gitignore | 4 + autogen.sh | 70 +++++--------- gtk-doc.make | 256 --------------------------------------------------- 3 files changed, 29 insertions(+), 301 deletions(-) delete mode 100644 gtk-doc.make -- 2.21.0

2 3

[libvirt] [glib PATCH] docs: explicitly link against libvirt-g{config, lib, object}
by Fabiano Fidêncio 24 May '19

24 May '19

Let's explicitly link against the built libvirt-gconfig, libvirt-glib, and libvirt-gobject libtool files for introspecting the gobjects. In case it's *not* done we can run into some issues when where we try to link against installed library, causing failures related to undefined reference of the new symbols. Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> --- This issue was caught by libvirt-jenkins-ci on a debian-9 machine only. However, it's easily reproducible with other distros. https://ci.centos.org/job/libvirt-glib-build/systems=libvirt-debian-9/445/c… --- docs/libvirt-gconfig/Makefile.am | 5 ++++- docs/libvirt-glib/Makefile.am | 5 ++++- docs/libvirt-gobject/Makefile.am | 5 ++++- 3 files changed, 12 insertions(+), 3 deletions(-) diff --git a/docs/libvirt-gconfig/Makefile.am b/docs/libvirt-gconfig/Makefile.am index 6a3df37..7d02354 100644 --- a/docs/libvirt-gconfig/Makefile.am +++ b/docs/libvirt-gconfig/Makefile.am @@ -34,6 +34,9 @@ GTKDOC_CFLAGS= \ GTKDOC_LIBS = \ $(GOBJECT2_LIBS) \ $(LIBXML2_LIBS) \ - $(top_builddir)/libvirt-gconfig/libvirt-gconfig-1.0.la + $(top_builddir)/libvirt-glib/libvirt-glib-1.0.la \ + $(top_builddir)/libvirt-gconfig/libvirt-gconfig-1.0.la \ + $(top_builddir)/libvirt-gobject/libvirt-gobject-1.0.la \ + $(NULL) include $(top_srcdir)/gtk-doc.make diff --git a/docs/libvirt-glib/Makefile.am b/docs/libvirt-glib/Makefile.am index 186f8ff..e3445b9 100644 --- a/docs/libvirt-glib/Makefile.am +++ b/docs/libvirt-glib/Makefile.am @@ -36,7 +36,10 @@ GTKDOC_LIBS = \ $(LIBVIRT_LIBS) \ $(GLIB2_LIBS) \ $(GTHREAD2_LIBS) \ - $(top_builddir)/libvirt-glib/libvirt-glib-1.0.la + $(top_builddir)/libvirt-glib/libvirt-glib-1.0.la \ + $(top_builddir)/libvirt-gconfig/libvirt-gconfig-1.0.la \ + $(top_builddir)/libvirt-gobject/libvirt-gobject-1.0.la \ + $(NULL) include $(top_srcdir)/gtk-doc.make diff --git a/docs/libvirt-gobject/Makefile.am b/docs/libvirt-gobject/Makefile.am index c068a96..f54c389 100644 --- a/docs/libvirt-gobject/Makefile.am +++ b/docs/libvirt-gobject/Makefile.am @@ -36,6 +36,9 @@ GTKDOC_LIBS = \ $(LIBVIRT_LIBS) \ $(GOBJECT2_LIBS) \ $(GIO2_LIBS) \ - $(top_builddir)/libvirt-gobject/libvirt-gobject-1.0.la + $(top_builddir)/libvirt-glib/libvirt-glib-1.0.la \ + $(top_builddir)/libvirt-gconfig/libvirt-gconfig-1.0.la \ + $(top_builddir)/libvirt-gobject/libvirt-gobject-1.0.la \ + $(NULL) include $(top_srcdir)/gtk-doc.make -- 2.21.0

2 1

[libvirt] [PATCH] docs: Link the relevant SEV formatdomain section from formatdomaincaps
by Erik Skultety 24 May '19

24 May '19

formatdomaincaps.html provides explanation of SEV fields, but doesn't link to the domain XML docs to show how it can be actually used in libvirt. Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- docs/formatdomaincaps.html.in | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in index b31b1729f4..432d7aed5e 100644 --- a/docs/formatdomaincaps.html.in +++ b/docs/formatdomaincaps.html.in @@ -514,10 +514,19 @@ encrypted with a key unique to that VM.</p> <p> - For more details on SEV feature see: - <a href="https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf"> - SEV API spec</a> and <a href="http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_E…"> - SEV White Paper</a> + For more details on the SEV feature and how to use it with libvirt have + a look at the following resources: + <dl> + <dd> + <a href="https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf">SEV API spec</a> + </dd> + <dd> + <a href="http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_E…">SEV White Paper</a> + </dd> + <dd> + <a href="formatdomain.html#launchSecurity">SEV in domain XML</a> + </dd> + </dl> </p> <dl> -- 2.20.1

2 1

[libvirt] [PATCH] nodesuspend: report unsupported if systemd & pm-utils aren't available
by Daniel P. Berrangé 24 May '19

24 May '19

When libvirtd is run inside a container it is normal that neither systemd nor pm-utils will be available. In this case there is no way to suspend the host, so libvirt should just report the feature unsupported instead of raising an error. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/util/virnodesuspend.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/util/virnodesuspend.c b/src/util/virnodesuspend.c index 0af0908e4a..3fc5b93ac7 100644 --- a/src/util/virnodesuspend.c +++ b/src/util/virnodesuspend.c @@ -330,11 +330,10 @@ virNodeSuspendSupportsTarget(unsigned int target, bool *supported) if (ret == -2) ret = virNodeSuspendSupportsTargetPMUtils(target, supported); - /* If still unavailable, then report error */ + /* If still unavailable, then report unsupported */ if (ret == -2) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Cannot probe for supported suspend types")); - ret = -1; + *supported = false; + ret = 0; } return ret; -- 2.21.0

2 1

[libvirt] [PATCH] spec: Unconditionally set ownership of /var/lib/libvirt/sanlock
by Jiri Denemark 24 May '19

24 May '19

The libvirt-lock-sanlock subpackage requires sanlock to be installed first and the sanlock package creates the sanlock group on all distros we care about in the spec file (Fedora and RHEL >= 7). Thus instead of setting the ownership and permissions in a post scriptlet only when the sanlock group exists we can just install the directory with the appropriate metadata. https://bugzilla.redhat.com/show_bug.cgi?id=1702758 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- libvirt.spec.in | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index b159c50d8f..5bd3e30509 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1479,14 +1479,6 @@ exit 0 %postun client %systemd_postun libvirt-guests.service -%if %{with_sanlock} -%post lock-sanlock -if getent group sanlock > /dev/null ; then - chmod 0770 %{_localstatedir}/lib/libvirt/sanlock - chown root:sanlock %{_localstatedir}/lib/libvirt/sanlock -fi -%endif - %if %{with_lxc} %pre login-shell getent group virtlogin >/dev/null || groupadd -r virtlogin @@ -1739,7 +1731,7 @@ exit 0 %attr(0755, root, root) %{_libdir}/libvirt/lock-driver/sanlock.so %{_datadir}/augeas/lenses/libvirt_sanlock.aug %{_datadir}/augeas/lenses/tests/test_libvirt_sanlock.aug -%dir %attr(0700, root, root) %{_localstatedir}/lib/libvirt/sanlock +%dir %attr(0770, root, sanlock) %{_localstatedir}/lib/libvirt/sanlock %{_sbindir}/virt-sanlock-cleanup %{_mandir}/man8/virt-sanlock-cleanup.8* %attr(0755, root, root) %{_libexecdir}/libvirt_sanlock_helper -- 2.21.0

2 1

[libvirt] [PATCH] driver: test: Fix the mingw build caused by wrong printf format specifier
by Erik Skultety 24 May '19

24 May '19

Caused by commit 326c3f54. Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- Travis build: https://travis-ci.org/eskultety/libvirt/builds/536736446 Pushed under the build breaker rule. src/test/test_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index b29fd12903..7fd06fcfa8 100644 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -3268,7 +3268,7 @@ testDomainInterfaceAddresses(virDomainPtr dom, iface->addrs[0].type = VIR_IP_ADDR_TYPE_IPV4; iface->addrs[0].prefix = 24; - if (virAsprintf(&iface->addrs[0].addr, "192.168.0.%ld", 1 + i) < 0) + if (virAsprintf(&iface->addrs[0].addr, "192.168.0.%zu", 1 + i) < 0) goto cleanup; iface->naddrs = 1; -- 2.20.1

1 0

[libvirt] [PATCH] spec: Fix permissions of /var/run/libvirt/qemu
by Jiri Denemark 24 May '19

24 May '19

While libvirtd creates this directory with the default 0755 mode, the spec file stores 0700 in the RPM database. Thus RPM verification always complains about this directory. Let's fix the spec file to match reality. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- Notes: Alternatively, we could change libvirt to create the directory with 0700 (instead of 0755), but all other drivers use 0755 (both in reality and in the spec file) and 0700 wouldn't really enhance security anyway. libvirt.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 970d2742ac..dc69920d75 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1661,7 +1661,7 @@ exit 0 %config(noreplace) %{_sysconfdir}/libvirt/qemu.conf %config(noreplace) %{_sysconfdir}/libvirt/qemu-lockd.conf %config(noreplace) %{_sysconfdir}/logrotate.d/libvirtd.qemu -%ghost %dir %attr(0700, root, root) %{_localstatedir}/run/libvirt/qemu/ +%ghost %dir %{_localstatedir}/run/libvirt/qemu/ %dir %attr(0751, %{qemu_user}, %{qemu_group}) %{_localstatedir}/lib/libvirt/qemu/ %dir %attr(0750, %{qemu_user}, %{qemu_group}) %{_localstatedir}/cache/libvirt/qemu/ %{_datadir}/augeas/lenses/libvirtd_qemu.aug -- 2.21.0

2 1

[libvirt] [PATCH v2 0/2] test_driver: add a guest inf and implement virDomainInterfaceAddresses
by Ilias Stamatis 24 May '19

24 May '19

Ilias Stamatis (2): test_driver: implement virDomainInterfaceAddresses test_driver: add a guest interface in the default config src/test/test_driver.c | 73 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) -- 2.21.0

2 4

[libvirt] Increasing TasksMax when creating machines via systemd
by Jim Fehlig 23 May '19

23 May '19

Hi All, I recently received an internal bug report of VM "crashing" due to hitting thread limits. Seems there was an assert in pthread_create within the VM when hitting the limit enforced by pids controller on the host Apr 28 07:45:46 lpcomp02007 kernel: cgroup: fork rejected by pids controller in /machine.slice/machine-qemu\x2d90028\x2dinstance\x2d0000634b.scope The user has TasksMax set to infinity in machine.slice, but apparently that is not inherited by child scopes and appears to be hardcoded to 16384 https://github.com/systemd/systemd/blob/51aba17b88617515e037e8985d3a4ea871a… The TasksMax property can be set when creating the machine as is done in the attached proof of concept patch. Question is whether this should be a tunable? My initial thought when seeing the report was TasksMax could be calculated based on number of vcpus, iothreads, emulator threads, etc. But it appears that could be quite tricky. The following mail thread describes the basic scenario encountered by my user http://lists.ceph.com/pipermail/ceph-users-ceph.com/2016-March/008174.html As you can see, many rbd images attached to a VM can result in an awful lot of threads. 300 images could result in 720K threads! We could punt and set the limit to infinity, but it exists for a reason - fork bomb prevention. A potential compromise between a hardcoded value and per-VM tunable is a driver tunable in qemu.conf. If a per-VM tunable is preferred, suggestions on where to place it and what to call it would be much appreciated :-). Regards, Jim

2 2