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 :|