#63 RFE: disable libvirtd daemon from the Workstation image
Closed: Fixed 4 years ago by catanzaro. Opened 5 years ago by aruiz.

The system wide libvirtd daemon is there for system wide VMs, since this is in the WS image as a dependency of Boxes and Boxes uses the user session libvirt daemon and not the system wide by default, I think it would be a good idea to disable the system wide daemon by default.

I've already submitted a patch but it looks like I should have consulted the working group, I'm leaving the PR link for reference:
https://pagure.io/fedora-release/pull-request/138


+1

Applications like virt-manager should be capable of enabling the service if required, I suppose?

I'm not sure if autostarts on demand. Perhaps we should investigate with the libvirt team first and see if that can be arranged before we make the change?

So virt-manager shows an error if the service is not started already.

@fidencio maybe this is something you can help us with or at least help us find the right person?

Yes, virt-manager uses the system libvirtd daemon by default, since it provides a much broader feature set than the session libvirt. eg full range of networking options, ability to use host device passthrough for USB, PCI, vGPUs, etc.

It is not possible to use systemd socket activation with libvirtd at this time, because this breaks libvirtd's autostart feature which is designed to allow libvirt VMs to be started on boot when libvirtd is started. For this reasons we do not provide a systemd socket unit for libvirtd. To solve this problem, libvirt needs to re-write the way we handle autostart, to write out systemd unit files for each VM that it manages, so that it can set these per-VM units to start, which would then trigger socket activation of libvirtd.

In summary, I'd be against disabling libvirtd startup on boot as it harms applications that use libvirtd.

running vms at boot is not really an interesting use case for the workstation. So I would still be in favor of disabling libvirtd

Yes, virt-manager uses the system libvirtd daemon by default, since it provides a much broader feature set than the session libvirt. eg full range of networking options, ability to use host device passthrough for USB, PCI, vGPUs, etc.
It is not possible to use systemd socket activation with libvirtd at this time, because this breaks libvirtd's autostart feature which is designed to allow libvirt VMs to be started on boot when libvirtd is started. For this reasons we do not provide a systemd socket unit for libvirtd. To solve this problem, libvirt needs to re-write the way we handle autostart, to write out systemd unit files for each VM that it manages, so that it can set these per-VM units to start, which would then trigger socket activation of libvirtd.
In summary, I'd be against disabling libvirtd startup on boot as it harms applications that use libvirtd.

@berrange If startup vms are the only reason to make libvirtd not socket activatable. Why don't we patch libvirtd to shut itself down when no startup vms are present?

The autostart feature isn't actually just about VMs. It is also used to start other resources like the default virtual network (the virbr0 device), that IIRC, GNOME Boxes relies on existing to get network connectivity for guest. This also applies to storage feature in libvirt.

The autostart feature isn't actually just about VMs. It is also used to start other resources like the default virtual network (the virbr0 device), that IIRC, GNOME Boxes relies on existing to get network connectivity for guest. This also applies to storage feature in libvirt.

My point still holds, libvirtd can shut itself down after initializing network and other host items. Boxes works just fine after stopping libvirtd.

That's really not something we'd willingly do. If libvirt is stopped while any of its managed resources are active, it will miss cleanup actions it has.

@aruiz, could you provide us a status update here?

Is the goal just to generally reduce the number of OS services that are running? I understand that having a system libvirtd instance running when Workstation only requires a session instance by default is perhaps wasteful. Or is there a more specific motivation for the proposed change?

@aruiz, could you provide us a status update here?
Is the goal just to generally reduce the number of OS services that are running? I understand that having a system libvirtd instance running when Workstation only requires a session instance by default is perhaps wasteful. Or is there a more specific motivation for the proposed change?

For some background here: on the 2018' GNOME performance hackfest, @jwrdegoede and I spent some time looking at the overall resource consumption of a tyipical GNOME session.

Basically, Fedora Workstation eats 1.6GB of RAM just to start an empty session and a lot of that footprint can be avoided. @benzea is already doing the work to shut down a lot of 'gsd' daemons by moving them as systemd --user daemons that are triggered by udev targets. There are other things we are trying to trim and shutdown when not needed (like firewalld).

So the number of services running is not really relevant but the overall resource consumption, libvirt consumes ~13megs and brings very little value to a workstation user using Boxes. In fact Boxes in flatpak brings its own libvirt build AFAIK ( @feborges can correct me if I'm wrong ).

Hope this clarifies.

In the very near future there's a number of key changes to libvirt. First we use systemd socket activation for system daemon. It will startup on boot still, but after 120 seconds it will exit if no VM was lanched. So in an out of the box install, this will cause libvirtd to start on boot, create the default network (virbr0) and then exit. IIUC this should be good enough for GNOME Boxes. This will be in rawhide next week I expect

Second, libvirtd is going to be split into many daemons, one of each functional area. So Boxes can have only "virtnetworkd" started, which will have lower memory overhead than libvirtd does today. This probably won't be in rawhide for a little while, since we need SELinux policy work to support this new daemon split.

Without this though, 13 MB, out of 1.6 GB is only 0.8% so that's not exactly a huge burden even today.

In the very near future there's a number of key changes to libvirt. First we use systemd socket activation for system daemon. It will startup on boot still, but after 120 seconds it will exit if no VM was lanched. So in an out of the box install, this will cause libvirtd to start on boot, create the default network (virbr0) and then exit. IIUC this should be good enough for GNOME Boxes. This will be in rawhide next week I expect

Great news!

Second, libvirtd is going to be split into many daemons, one of each functional area. So Boxes can have only "virtnetworkd" started, which will have lower memory overhead than libvirtd does today. This probably won't be in rawhide for a little while, since we need SELinux policy work to support this new daemon split.

I'd like to see numbers before making statements like "this daemon will have lower overhead", I've seen a lot of cases where overhead comes from a dependency brought in that creates a bunch of heap allocations just by virtue of being loaded and initializated.

Does virtnetworkd need to be running 100% of the time or can we use it only when a system-wide VM is started?

Without this though, 13 MB, out of 1.6 GB is only 0.8% so that's not exactly a huge burden even today.

The problem with that last argument is that it is the same argument everybody gives to not solve their own part in this problem. We have dozens of daemons doing the same thing and if we accept this argument then we won't be able to make a dent to that mark any time soon.

It will startup on boot still, but after 120 seconds it will exit if no VM was lanched.

Well if, as of next week, it will shut down after two minutes, and only launch itself when it's actually needed, sounds like there won't be any problem anymore?

It will startup on boot still, but after 120 seconds it will exit if no VM was lanched.

Well if, as of next week, it will shut down after two minutes, and only launch itself when it's actually needed, sounds like there won't be any problem anymore?

That would mark my request as fixed. Yes indeed, thanks a lot to everyone involved.

OK, closing this. If you still see libvirt hanging around for more than two minutes in F31 then of course please do reopen.

Metadata Update from @catanzaro:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.

Metadata