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

Daniel P. Berrange berrange at redhat.com
Thu Oct 31 09:23:06 UTC 2013


On Wed, Oct 30, 2013 at 05:30:27PM -0600, Eric Blake wrote:
> Actually put gfapi to use, by allowing the creation of a gluster
> pool.  Right now, all volumes are treated as raw; further patches
> will allow peering into files to allow for qcow2 files and backing
> chains, and reporting proper volume allocation.
> 
> I've reported a couple of glusterfs bugs; if we were to require a
> minimum of (not-yet-released) glusterfs 3.5, we could use the new
> glfs_readdir [1] and not worry about the bogus return value of
> glfs_fini [2], but for now I'm testing with Fedora 19's glusterfs
> 3.4.1.
> 
> [1] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00085.html
> [2] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00086.html
> 
> * src/storage/storage_backend_gluster.c
> (virStorageBackendGlusterRefreshPool): Initial implementation.
> (virStorageBackendGlusterOpen, virStorageBackendGlusterClose): New
> helper functions.
> 
> Signed-off-by: Eric Blake <eblake at redhat.com>
> ---
> 
> Depends on these pre-req patches:
> https://www.redhat.com/archives/libvir-list/2013-October/msg01266.html
> https://www.redhat.com/archives/libvir-list/2013-October/msg00913.html
> 
> My next task - figuring out the use of glfs_open() to read metadata
> from a file and determine backing chains.

NB, we don't want the src/util code to gain a dependancy on glusterfs
RPMs. It is a very heavy weight package chain which cloud folks don't
want us to pull in by default, hence my recent changes to RPM deps.


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