From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: Anand Avati <aavati@redhat.com>,
Amar Tumballi <amarts@redhat.com>,
Vijay Bellur <vbellur@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH 0/3] GlusterFS support in QEMU
Date: Fri, 6 Jul 2012 11:05:53 +0530 [thread overview]
Message-ID: <20120706053553.GA31524@in.ibm.com> (raw)
In-Reply-To: <20120611141806.GA2737@in.ibm.com>
On Mon, Jun 11, 2012 at 07:48:07PM +0530, Bharata B Rao wrote:
>
> # qemu-system-x86_64 --enable-kvm --nographic -smp 4 -m 1024 -drive file=gluster:c-qemu.vol:/F16,format=gluster
>
If you notice above, I am directly feeding the gluster volume file to QEMU.
During my discussions with GlusterFS developers, I realized that it is more
relevant to use volume name than volume file directly. Hence I am proposing
that QEMU should have the gluster specifications like this:
-drive file=gluster:volfileserver:volumename:imagename
Note that volfile server and volume name combination is the standard way
of specifying a volume in gluster world.
QEMU would pass volfileserver:volumename to libglusterfsclient which will
contact the server and fetch the right client volume file to use. This
specification change has two side effects:
1. It limits the QEMU user to pick volfiles that are generated only
by gluster CLI. This should be fine as long as gluster CLI provides
the capability to generate or regenerate volume files for a given volume
with the xlator set that QEMU user is interested in. GlusterFS developers
tell me that this can be provided with some enhancements to
glusterCLI/glusterd.
Note that custom volume files could be typically needed when GlusterFS
server is co-located with QEMU in which case you would like to get rid
of client-server overhead and RPC communication overhead.
2. As of now, the specification of volfileserver:volumename picks the
default client volume file for the given volume name. Since we want to
have the flexibility to pick the volfile of our choice, we could slightly
extend the specification like this:
volfileserver:volumename.custom
that would instruct gluster to pick a custom volume file.
Eg. volfileserver:myvol.rpcbypass would pick myvol.rpcbypass.vol volume
file for the volume myvol.
Here also, the creation of custom volume file is done by gluster CLI, so
that gluster is in a position to pick the right volume file.
As per my current understanding, such custom volfile extensions works with
gluster.
Request QEMU developers to comment on the new specification and point out any
use cases that wouldn't be possible or would be hindered by this
volfileserver:volumename specification.
I also request the GlusterFS developers (on CC) to validate my understanding
of gluster here and let me know if the proposed enhancements to
glusterCLI/glusterd are indeed feasible.
Regards,
Bharata.
prev parent reply other threads:[~2012-07-06 5:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 14:18 [Qemu-devel] [RFC PATCH 0/3] GlusterFS support in QEMU Bharata B Rao
2012-06-11 14:19 ` [Qemu-devel] [RFC PATCH 1/3] qemu: Add a config option for GlusterFS as block backend Bharata B Rao
2012-06-11 14:20 ` [Qemu-devel] [RFC PATCH 2/3] block: GlusterFS helpers to interface with libglusterfs Bharata B Rao
2012-06-18 17:35 ` Stefan Hajnoczi
2012-06-19 9:31 ` Bharata B Rao
2012-07-02 9:52 ` Paolo Bonzini
2012-07-02 10:05 ` Bharata B Rao
2012-06-11 14:21 ` [Qemu-devel] [RFC PATCH 3/3] block: gluster as block backend Bharata B Rao
2012-06-18 17:35 ` Stefan Hajnoczi
2012-06-19 9:27 ` Avi Kivity
2012-06-19 9:30 ` Bharata B Rao
2012-06-19 11:05 ` Stefan Hajnoczi
2012-07-01 14:50 ` Paolo Bonzini
2012-07-01 14:49 ` Paolo Bonzini
2012-06-18 15:36 ` [Qemu-devel] [RFC PATCH 0/3] GlusterFS support in QEMU Stefan Hajnoczi
2012-06-19 9:10 ` Bharata B Rao
2012-07-06 5:35 ` Bharata B Rao [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120706053553.GA31524@in.ibm.com \
--to=bharata@linux.vnet.ibm.com \
--cc=aavati@redhat.com \
--cc=amarts@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=vbellur@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).