[Users] glusterfs and ovirt
bailey at cs.kent.edu
Thu May 17 18:40:58 UTC 2012
On 5/17/2012 1:35 PM, Itamar Heim wrote:
> 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:
>>>> Thanks for an update. Can I have KVM hypervisors also function as
>>>> nodes for glusterfs? What is a release date for glusterfs support?
>>>> 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 .
>>> I'm not sure if all of them will make the ovirt 3.1 version which is
>>> to branch for stabilization June 1st, but i think "enough" is there.
>>> so i'd start trying current upstream version to help find issues
>>> you, and following on them during june as we stabilize ovirt 3.1 for
>>> (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
>>> 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
>> 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.
Direct qemu support for gluster is similar to ceph rbd/rados object
storage which is also supported in qemu. A domain type which can handle
object based storage of this sort would be very nice.
> Users mailing list
> Users at ovirt.org
More information about the Users