On Do, 11.04.19 11:18, Daniel P. Berrangé (berrange(a)redhat.com) wrote:
> I don't know off hand of anything that would prevent it.
> 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.
Or to say this differently: you can combine activation methods nicely
and it's common to do so: activation-on-boot + activation-on-timer +
activation-on-socket + activation-on-hardware +
activation-on-anything-else can be nicely done for the same service.
Or to say this even differently: service activation in systemd is
substantially more powerful than in inetd: it's not exclusively about
*on-demand* socket activation, but socket activation is just one form
that can neatly be composed with every other trigger you like.
Lennart Poettering, Berlin