Comment # 2 on bug 1130539 from James Fehlig

I remembered this bug while reviewing some recent patches on libvirt-dev which
split libvirtd into per-driver daemons. However, after reading the bug
description again I realize what you describe has been "fixed" for quite some
time, although I admit it's not intuitive or documented.

The main libvirt-x.y.z package is a meta package that simply requires all
subpackages needed to satisfy the build time configuration of libvirt. It gives
you a monolithic libvirtd that includes all drivers and functionality specified
at build time, similar to the old days when we only had libvirt (for the
daemon) and libvirt-client packages. Folks complained about the monolithic
daemon, e.g. having xen and lxc drivers when only running a qemu host, so
upstream started decomposing the monolithic daemon based on hypervisor. Along
came libvirt-daemon-{libxl,lxc,qemu,...} subpackages that encapsulated
everything needed to run a hypervisor with support for all options configured
at build time (rbd, gluster, network, nwfilter, etc). This allowed installing a
hypervisor-specific daemon.

For even finer control, the libvirt-daemon-driver-{libxl,lxc,qemu,...}
subpackages were introduced that only require libvirt-daemon for the remote
driver. These hypervisor-specific driver subpackages could be installed along
with libvirt-daemon to give you a small footprint daemon.

As an example, I use kvm/qemu on my laptop and my VMs use libvirt's virtual
network functionality. I manage my own VM storage and don't use any of libvirt
storage pool/volume functionality. Nor do I use nwfilter or any VM config that
requires secrets or host devices. In other words I can get by with a pretty
small daemon

# rpm -qa | grep ^libvirt
libvirt-daemon-driver-storage-core-5.4.0-2.2.x86_64
libvirt-daemon-driver-qemu-5.4.0-2.2.x86_64
libvirt-daemon-5.4.0-2.2.x86_64
libvirt-libs-5.4.0-2.2.x86_64
libvirt-daemon-driver-network-5.4.0-2.2.x86_64

I did find that libvirt-daemon-driver-storage-core is used by the qemu driver
to change ownership of images when starting VMs. But as you can see all the
other storage drivers (along with secret, interface, nodedev, nwfilter, ...)
can be ditched. Can you similarly customize your libvirtd installation?