<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/24/2012 10:06 AM, Itamar Heim
wrote:<br>
</div>
<blockquote cite="mid:50877030.6040203@redhat.com" type="cite">On
10/22/2012 01:01 PM, Deepak C Shetty wrote:
<br>
<blockquote type="cite">Hi list,
<br>
I created a wiki page for GLUSTERFS_DOMAIN support.
<br>
Comments/Suggestions are welcome.
<br>
<br>
<a class="moz-txt-link-freetext" href="http://wiki.ovirt.org/wiki/Features/GlusterFS_Storage_Domain">http://wiki.ovirt.org/wiki/Features/GlusterFS_Storage_Domain</a>
<br>
</blockquote>
<br>
(moving to @arch)
<br>
<br>
several thoughts:
<br>
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).
<br>
</blockquote>
<tt>I had tried doing somethign similar but that was rejected by
Saggi !<br>
Pls see <br>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-July/001258.html">https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-July/001258.html</a><br>
<br>
</tt>
<blockquote cite="mid:50877030.6040203@redhat.com" type="cite">
<br>
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)?
<br>
this would be both useful to non qemu users of gluster and will
not require any change to qemu/libvirt?
<br>
</blockquote>
<tt>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.</tt><br>
<blockquote cite="mid:50877030.6040203@redhat.com" type="cite">
<br>
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).
<br>
such a block mapper utility would provide vdsm with the block
device to mount for the posixfs mount/volume path it got.
<br>
</blockquote>
<tt>Can you provide more details here, its not clear to us (Copying
bharata as well who worked on native qemu-glusterfs integraiton).<br>
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.<br>
<br>
</tt>
<blockquote cite="mid:50877030.6040203@redhat.com" type="cite">
<br>
3. wrt scope, iiuc:
<br>
- all disk manipulations are still done like normal posixfs
<br>
- running the VM is done directly via block device
<br>
</blockquote>
<tt>To clarify, this wikipage <b>does not refer to the BD xlator
work</b>. This wikipage refers to fitting QEMU-GlusterFS native
integration with VDSM usign a new storage domain.<br>
VM is run using Gluster as a backend (QEMU's way of talking with
FS), not as a block device.<br>
</tt>
<blockquote cite="mid:50877030.6040203@redhat.com" type="cite">
<br>
wouldn't using block device also improve other operations, like
DD/qemu-img?
<br>
(doesn't mean need to be in first phase)
<br>
<br>
4. nit: UI, i assume no need to specify vfsType, since it is
always glusterfs?
<br>
</blockquote>
<tt>Agree, showing vfsType will be good for FYI reasons tho :)</tt><br>
<blockquote cite="mid:50877030.6040203@redhat.com" type="cite">
<br>
<br>
</blockquote>
<br>
</body>
</html>