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

[Itamar Heim]

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).

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?

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.

3. wrt scope, iiuc:
- all disk manipulations are still done like normal posixfs
- running the VM is done directly via 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?