qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.

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