[Users] glusterfs and ovirt

[Itamar Heim]

On 05/17/2012 06:55 PM, Bharata B Rao wrote:
> On Wed, May 16, 2012 at 3:29 PM, Itamar Heim<iheim at redhat.com>  wrote:
>> On 05/15/2012 07:35 PM, Andrei Vakhnin wrote:
>>>
>>> Yair
>>>
>>> Thanks for an update. Can I have KVM hypervisors also function as storage
>>> nodes for glusterfs? What is a release date for glusterfs support? We're
>>> looking for a production deployment in June. Thanks
>>
>>
>> current status is
>> 1. patches for provisioning gluster clusters and volumes via ovirt are in
>> review, trying to cover this feature set [1].
>> I'm not sure if all of them will make the ovirt 3.1 version which is slated
>> to branch for stabilization June 1st, but i think "enough" is there.
>> so i'd start trying current upstream version to help find issues blocking
>> you, and following on them during june as we stabilize ovirt 3.1 for release
>> (planned for end of june).
>>
>> 2. you should be able to use same hosts for both gluster and virt, but there
>> is no special logic/handling for this yet (i.e., trying and providing
>> feedback would help improve this mode).
>> I would suggest start from separate clusters though first, and only later
>> trying the joint mode.
>>
>> 3. creating a storage domain on top of gluster:
>> - expose NFS on top of it, and consume as a normal nfs storage domain
>> - use posixfs storage domain with gluster mount semantics
>> - future: probably native gluster storage domain, up to native
>>   integration with qemu
>
> I am looking at GlusterFS integration with QEMU which involves adding
> GlusterFS as block backend in QEMU. This will involve QEMU talking to
> gluster directly via libglusterfs bypassing FUSE. I could specify a
> volume file and the VM image directly on QEMU command line to boot
> from the VM image that resides on a gluster volume.
>
> Eg: qemu -drive file=client.vol:/Fedora.img,format=gluster
>
> In this example, Fedora.img is being served by gluster and client.vol
> would have client-side translators specified.
>
> I am not sure if this use case would be served if GlusterFS is
> integrated as posixfs storage domain in VDSM. Posixfs would involve
> normal FUSE mount and QEMU would be required to work with images from
> FUSE mount path ?
>
> With QEMU supporting GlusterFS backend natively, further optimizations
> are possible in case of gluster volume being local to the host node.
> In this case, one could provide QEMU with a simple volume file that
> would not contain client or server xlators, but instead just the posix
> xlator. This would lead to most optimal IO path that bypasses RPC
> calls.
>
> So do you think, this use case (QEMU supporting GlusterFS backend
> natively and using volume file to specify the needed translators)
> warrants a specialized storage domain type for GlusterFS in VDSM ?

I'm not sure if a special storage domain, or a PosixFS based domain with 
enhanced capabilities.
Ayal?