[Engine-devel] Feature page for GLUSTERFS_DOMAIN support is now available.

[Deepak C Shetty]

On 10/24/2012 10:06 AM, Itamar Heim wrote:
> On 10/22/2012 01:01 PM, Deepak C Shetty wrote:
>> Hi list,
>>      I created a wiki page for GLUSTERFS_DOMAIN support.
>> Comments/Suggestions are welcome.
>>
>> http://wiki.ovirt.org/wiki/Features/GlusterFS_Storage_Domain
>
> (moving to @arch)
>
> several thoughts:
> 1. it almost sounds like a property of posixfs storage domain on how 
> to attach the disk, since everything else is similar to posixfs, but i 
> don't think we have a better way to notate this than a new type of 
> storage domain today (actually, a new type of data center for now as 
> well).
I had tried doing somethign similar but that was rejected by Saggi !
Pls see
https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-July/001258.html

>
> 2. general question on the solution: this sounds somewhat like iscsi, 
> which qemu doesn't handle. why not do the mapping of a remote gluster 
> file to a block device at host level, by passing the fuse layer, in a 
> general use case (not qemu specific)?
> this would be both useful to non qemu users of gluster and will not 
> require any change to qemu/libvirt?
Goal here was to use GlusterFS as a filesystem layer for virt. stack, so 
that all virt. related ops can be done/achieved using simple FS cmds. We 
are not looking at doing (what looks like the opposite to me) things the 
other way. We are also looking at this purely from the virt. stack 
layer, hence haven't thought abt non-qemu use cases. I am still not 
clear on how what you are proposing works and helps ? Why add block->fs 
conversion when Gluster is designed as FS and any application ( qemu and 
non-qemu as well) can use libgfapi to talk to images stored in gluster 
bypassing the fuse layer, so that part is already covered.
>
> now, just a thought, if we combine 1+2, maybe this can become an 
> option of posixfs domain on "block mapper utility", with a predefined 
> list of options in the engine vdsm supports (well, hooks maybe as well).
> such a block mapper utility would provide vdsm with the block device 
> to mount for the posixfs mount/volume path it got.
Can you provide more details here, its not clear to us (Copying bharata 
as well who worked on native qemu-glusterfs integraiton).
In case you are referring to the Gluster BD xlator, that does the 
reverse of this (block is seen as file). I am a bit confused here.

>
> 3. wrt scope, iiuc:
> - all disk manipulations are still done like normal posixfs
> - running the VM is done directly via block device
To clarify, this wikipage *does not refer to the BD xlator work*. This 
wikipage refers to fitting QEMU-GlusterFS native integration with VDSM 
usign a new storage domain.
VM is run using Gluster as a backend (QEMU's way of talking with FS), 
not as a block device.
>
> wouldn't using block device also improve other operations, like 
> DD/qemu-img?
> (doesn't mean need to be in first phase)
>
> 4. nit: UI, i assume no need to specify vfsType, since it is always 
> glusterfs?
Agree, showing vfsType will be good for FYI reasons tho :)
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121029/de238783/attachment.html>