Re: [libvirt] [RFC PATCHv2 0/2] gluster pools
On 10/18/2013 11:30 AM, Eric Blake wrote:
This addresses the review from RFCv1 for splitting the glfs checks
to be different from the storage backend checks:
https://www.redhat.com/archives/libvir-list/2013-October/msg00645.html
I'm still just in RFC stage; wanting to make sure I have the
documentation correct for sample XML prior to actually coding
up the use of <glfs.h> from storage_backend_gluster.c.
Note that qemu's block/gluster.c documents that qemu expects
that when using glfs to bypass the file system, the image will
always be specified as:
* file=gluster[+transport]://[server[:port]]/volname/image[?socket=...]
which means that there is no way to pass a direct gluster volume
as a raw block device to qemu (it is always a file embedded within
the gluster volume); hence my choice of making a single gluster
volume act as the storage pool.
Eric Blake (2):
storage: initial support for linking with libgfapi
storage: document gluster pool
Another thing to think about while reviewing this:
libgfapi is dual-licensed as your choice of LGPLv3+ or GPLv2. That
means you cannot copy code from libgfapi into an LGPLv2+ project (only
into LGPLv3, GPLv2, GPLv3, or any higher version).
Not being a laywer, my interpretation could be off, but
http://gplv3.fsf.org/dd3-faq says that as long as you _link_ (and not
_copy_) to an LGPLv3 library, you can still release your library/binary
as LGPLV2+. But to be on the safe side, it's all the easier to be on
the safe side if we limit the use of gfapi to libvirtd (which has been
my plan anyways, in case we ever reach the point of shipping storage
backends as separate .so files for minimizing dependencies to unused
backends).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 621 bytes)