On Do, 11.04.19 11:18, Daniel P. Berrangé (berrange@xxxxxxxxxx) wrote: > > 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. 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 -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
