http://bugzilla.suse.com/show_bug.cgi?id=1130539 http://bugzilla.suse.com/show_bug.cgi?id=1130539#c2 James Fehlig changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ddiss@suse.com Flags| |needinfo?(ddiss@suse.com) --- Comment #2 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? -- You are receiving this mail because: You are on the CC list for the bug.