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@xxxxxxxxxx> > --- > > 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list