On Thu, Oct 31, 2013 at 11:43:11AM -0600, Eric Blake wrote: > On 10/31/2013 11:30 AM, Daniel P. Berrange wrote: > > >> > >> I don't know if that means the libvirt-daemon-driver-storage needs to be > >> further split into multiple .so files across multiple sub-rpms, so that > >> a user can pick and choose which .so backends to install rather than > >> dragging in all dependencies for all backends. > > > > The QEMU driver will need to use librbd to query backing file in any > > qcow2 files stored in the rbd volume. Likewise for gluster. So while > > making the storage driver modular would allow you to install a subset > > of the storage driver deps, you're still not going to avoid pulling > > in the gluster/rbd libraries, since the QEMU driver will pull them > > in anyway. > > Not quite - making the storage driver modular would merely mean that > libvirt would not support anything except raw rbd volumes if the rbd > storage backend was not available. Yes, for backing file chains, qemu > would need the full dependencies; but if you know you aren't going to > use qemu with rbd, then having the storage modules would allow you to > avoid dragging in rbd libraries. The QEMU driver should be near 100% functional without needing the storage driver at all. The only dep should be if you use <disk type=vol>. A <disk type=network> should have no dependancy on the storage driver, so we'd need rbd there even if the storage driver was not there. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list