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