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

Daniel P. Berrange berrange at redhat.com
Thu Oct 31 18:09:13 UTC 2013


On Thu, Oct 31, 2013 at 11:58:48AM -0600, Eric Blake wrote:
> On 10/31/2013 11:49 AM, Daniel P. Berrange wrote:
> 
> > 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.
> 
> <disk type='network'><driver type='raw'/></disk> should be just fine
> without rbd driver pulled in by libvirt.  But you are right that qemu
> will have pulled it in to be able to use the image.  So as long as qemu
> is monolithic, even a raw-only use of a backing file doesn't free your
> system from needing the libraries.
> 
> <disk type='network'><driver type=qcow2'/></disk> currently boots, but
> that is a mistake under sVirt because we can't chase the backing chain
> to guarantee that any backing files are present with correct permissions
> unless we have the rbd/gluster/... storage backend present.  I'm arguing
> that <disk type='network'><driver type='qcow2'/> should be made an error
> unless the storage backend also provides the tools for chasing that
> backing chain, and that the storage backend be modular so that you only
> require the libraries for the particular network storage that you plan
> on using; while you're arguing one step further that <disk
> type='network'> is itself useless if qemu doesn't also support that
> network protocol.

If  <disk type='network'/> were made to require a storage pool in order
to use it, that would be a regression in functionality IMHO. This setup
should be completely independant of the storage driver code. It needs to
be able to resolve the backing file chain directly, without calling into
the storage driver.

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