Re: [libvirt] [PATCH 00/23] Enable proper use of systemd socket activation with libvirtd

On Thu, Jun 27, 2019 at 02:04:44PM +0100, Daniel P. Berrangé wrote: > On Thu, Jun 27, 2019 at 01:56:45PM +0200, Martin Kletzander wrote: > > On Thu, Jun 27, 2019 at 10:54:29AM +0100, Daniel P. Berrangé wrote: > > > The libvirtd daemon has some support for systemd socket activation > > > from: > > > > > > commit 27a7081c2968ca0d7fbd590629b5a5303851f4a3 > > > Author: Martin Kletzander <mkletzan(a)redhat.com&gt; > > > Date: Tue Jul 15 15:28:53 2014 +0200 > > > > > > daemon: support passing FDs from the calling process > > > > > > First FD is the RW unix socket to listen on, second one (if > > > applicable) is the RO unix socket. > > > > > > This was originally intended for use by the libvirt client when doing > > > auto-spawning of libvirtd, but we later deleted that client side code > > > in > > > > > > commit be78814ae07f092d9c4e71fd82dd1947aba2f029 > > > Author: Michal Privoznik <mprivozn(a)redhat.com&gt; > > > Date: Thu Apr 2 14:41:17 2015 +0200 > > > > > > virNetSocketNewConnectUNIX: Use flocks when spawning a daemon > > > > > > We never added systemd socket units before as we need libvirtd to start > > > on boot to perform autostart. > > > > > > It was recently pointed out by Lennart that these two features are not > > > mutually exclusive though. Libvirtd can be set to start on boot, and > > > also have socket unit files. > > > > > > The idea is that we start libvirtd on boot, perform autostart, and then > > > libvirtd can exit if nothing is running. The socket unit files are then > > > there to start it again when a mgmt app connects. > > > > > > > How do you deal with responding to QEMU events, for example proper support for > > <on_poweroff>restart</on_poweroff> ? > > If any QEMU guest is running, libvirtd will keep running. The --timeout > option should only let us exit if we have no client apps and no running > QEMUs, unless I'm mis-remembering. > As far as I remember the session daemon was basing this on connected clients, but it might've changed since. I just wanted to point out this might be something to keep in mind as the reason for not having this setup was something along the lines of this issue.