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?
_______________________________________________
Arch mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/arch
