On Thu, Apr 11, 2019 at 03:57:30PM +0200, Lennart Poettering wrote:
On Do, 11.04.19 11:18, Daniel P. Berrangé (berrange(a)redhat.com)
> > I don't know off hand of anything that would prevent it. Libvirt does
> > process events from running qemu VMs, but if there's no API users
> > connected to the daemon then I don't think libvirtd needs to be running;
> > it can handle restart and reconnecting to running VMs. That's
> > essentially the same behavior the session libvirtd instance uses which
> > auto shuts down after 30 seconds if there's no clients IIRC. danpb would
> > know best though, CCd
> The reasons systemd libvirtd starts on boot is that it needs to perform
> auto-start of various resources its manages. These resources don't have
> any associated systemd unit so we can't use systemd for this purpose.
> Ideally we would enable libvirtd to create systemd units for the resources
> it manages that need autostart, but that's a significant bit of work.
> So today we can't use systemd activation.
socket activation doesn't mean you need to start libvirt strictly on
socket traffic. A common pattern is to start both the socket and the
service at boot, but the service exits when idle and then gets
restarted when needed. And that's what I'd like to see here: make
libvirt socket-activatable, but also start it at boot. This would mean
libvirt could start any VMs it wants at boot if they are
configured. And if nothing is configured and nothing has an open IPC
connection it would just exit, knowing that the instance something
wants to talk to it it would be started again.
Ok, I see what you mean, enabling both the service & socket by default
will probably work. We already have support for systemd activation
and auto-exiting, for our non-root instance, so in theory we can
just change the unit file setup. Will have to think if there are
any other edge cases with this in the root instance though as it
has much broader functionality.