On 05/21/2012 06:15 AM, Bharata B Rao wrote:
On Sun, May 20, 2012 at 4:57 PM, Dor Laor<dl...@redhat.com> wrote:
On 05/18/2012 04:28 PM, Deepak C Shetty wrote:
On 05/17/2012 11:05 PM, Itamar Heim wrote:
On 05/17/2012 06:55 PM, Bharata B Rao wrote:
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.
With QEMU using GlusterFS backend natively (as described above), it also
it needs addnl options/parameters as part of qemu command line (as given
There is no support in qemu for gluster yet but it will be there not far
As I said above, I am working on this. Will post the patches shortly.
/me apologize for the useless noise, I'm using a new thunderbird plugin
that collapses quotes and it made me loss the context.
vdsm-devel mailing list