[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