[libvirt] [PATCH] storage: implement rudimentary glusterfs pool refresh

Daniel P. Berrange berrange at redhat.com
Thu Oct 31 17:49:01 UTC 2013


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




More information about the libvir-list mailing list