Re: [Qemu-devel] [PATCH 4/4] block/gluster: add support for multiple gluster servers

2016-03-23 Thread Prasanna Kalever
On Wed, Mar 23, 2016 at 5:46 PM, Prasanna Kalever  wrote:
> On Fri, Feb 5, 2016 at 6:47 PM, Prasanna Kumar Kalever
>  wrote:
>>
>> On Thursday, February 4, 2016 6:52:15 PM Kevin Wolf Wrote:
>> > Am 12.11.2015 um 23:36 hat Eric Blake geschrieben:
>> > > On 11/12/2015 03:22 AM, Prasanna Kumar Kalever wrote:
>> > > > +static struct glfs *qemu_gluster_init(BlockdevOptionsGluster **gconf,
>> > > > +  const char *filename,
>> > > > +  QDict *options, Error **errp)
>> > > > +{
>> > > > +int ret;
>> > > > +
>> > > > +if (filename) {
>> > > > +ret = qemu_gluster_parseuri(gconf, filename);
>> > > > +if (ret < 0) {
>> > > > +error_setg(errp, "Usage:
>> > > > file=gluster[+transport]://[host[:port]]/"
>> > > > + "volume/path[?socket=...]");
>> > >
>> > > Hmm, just noticing this now, even though this error message is just code
>> > > motion.  It looks like the optional [?socket=...] part of a URI is only
>> > > important when using gluster+unix (is it silently ignored otherwise?).
>> > > And if it is used, you are then assigning it to the host field?
>> > >
>> > > I almost wonder if GlusterServer should be a discriminated union.  That
>> > > is, in qapi-pseudocode (won't actually compile yet, because it depends
>> > > on features that I have queued for 2.6):
>> > >
>> > > { 'union':'GlusterServer', 'base':{'transport':'GlusterTransport'},
>> > >   'discriminator':'transport', 'data':{
>> > > 'tcp':{'host':'str', '*port':'uint16'},
>> > > 'unix':{'socket':'str'},
>> > > 'rdma':{...} } }
>> > >
>> > > Hmm. Qapi doesn't (yet) allow for an optional discriminator (where the
>> > > omission of the discriminator picks a default branch) - another RFE for
>> > > my qapi work for 2.6.
>> >
>> > Eric, Prasanna, is this QAPI extension what we're waiting for or what is
>> > the status of this series? Niels (CCed) was hacking on the same thing,
>> > so maybe it's time to get this moving again.
>>
>> Kevin, correct me if I am wrong, union discriminator support is not yet added
>> into qemu, I am waiting for this. I spoke to Eric Blake regarding the same 
>> may be
>> a month ago from now.
>>
>> -Prasanna

[ Adding Eric in 'to:' list ]

>
> Eric, Kevin, any updates on union discriminator related patches,
> any hope for taking these patches in 2.6 ?
>
> -Prasanna
>
>>
>> >
>> > Kevin
>> >
>> > > Command-line wise, this would mean you could do in JSON:
>> > >
>> > > 'servers':[{'transport':'tcp', 'host':'foo'},
>> > >{'transport':'unix', 'socket':'/path/to/bar'},
>> > >{'host':'blah'}]
>> > >
>> > > where the third entry defaults to transport tcp.
>> > >
>> > > If we think that description is better than what we proposed in 3/4,
>> > > then it's really late to be adding it now, especially since (without
>> > > qapi changes) we'd have a mandatory rather than optional 'transport';
>> > > but worse if we commit to the interface of 3/4 and don't get the
>> > > conversion made in time to the nicer interface.  At least it's okay from
>> > > back-compat perspective to make a mandatory field become optional in
>> > > later releases.
>> > >
>> > > If it were just gluster code I was worried about, then I could live with
>> > > the interface proposal.  But since seeing this error message is making
>> > > me double-guess the interface correctness, and that will have an impact
>> > > on libvirt, I'm starting to have doubts on what it means for qemu 2.5.
>> >
>> >



Re: [Qemu-devel] [PATCH 4/4] block/gluster: add support for multiple gluster servers

2016-03-23 Thread Prasanna Kalever
On Fri, Feb 5, 2016 at 6:47 PM, Prasanna Kumar Kalever
 wrote:
>
> On Thursday, February 4, 2016 6:52:15 PM Kevin Wolf Wrote:
> > Am 12.11.2015 um 23:36 hat Eric Blake geschrieben:
> > > On 11/12/2015 03:22 AM, Prasanna Kumar Kalever wrote:
> > > > +static struct glfs *qemu_gluster_init(BlockdevOptionsGluster **gconf,
> > > > +  const char *filename,
> > > > +  QDict *options, Error **errp)
> > > > +{
> > > > +int ret;
> > > > +
> > > > +if (filename) {
> > > > +ret = qemu_gluster_parseuri(gconf, filename);
> > > > +if (ret < 0) {
> > > > +error_setg(errp, "Usage:
> > > > file=gluster[+transport]://[host[:port]]/"
> > > > + "volume/path[?socket=...]");
> > >
> > > Hmm, just noticing this now, even though this error message is just code
> > > motion.  It looks like the optional [?socket=...] part of a URI is only
> > > important when using gluster+unix (is it silently ignored otherwise?).
> > > And if it is used, you are then assigning it to the host field?
> > >
> > > I almost wonder if GlusterServer should be a discriminated union.  That
> > > is, in qapi-pseudocode (won't actually compile yet, because it depends
> > > on features that I have queued for 2.6):
> > >
> > > { 'union':'GlusterServer', 'base':{'transport':'GlusterTransport'},
> > >   'discriminator':'transport', 'data':{
> > > 'tcp':{'host':'str', '*port':'uint16'},
> > > 'unix':{'socket':'str'},
> > > 'rdma':{...} } }
> > >
> > > Hmm. Qapi doesn't (yet) allow for an optional discriminator (where the
> > > omission of the discriminator picks a default branch) - another RFE for
> > > my qapi work for 2.6.
> >
> > Eric, Prasanna, is this QAPI extension what we're waiting for or what is
> > the status of this series? Niels (CCed) was hacking on the same thing,
> > so maybe it's time to get this moving again.
>
> Kevin, correct me if I am wrong, union discriminator support is not yet added
> into qemu, I am waiting for this. I spoke to Eric Blake regarding the same 
> may be
> a month ago from now.
>
> -Prasanna

Eric, Kevin, any updates on union discriminator related patches,
any hope for taking these patches in 2.6 ?

-Prasanna

>
> >
> > Kevin
> >
> > > Command-line wise, this would mean you could do in JSON:
> > >
> > > 'servers':[{'transport':'tcp', 'host':'foo'},
> > >{'transport':'unix', 'socket':'/path/to/bar'},
> > >{'host':'blah'}]
> > >
> > > where the third entry defaults to transport tcp.
> > >
> > > If we think that description is better than what we proposed in 3/4,
> > > then it's really late to be adding it now, especially since (without
> > > qapi changes) we'd have a mandatory rather than optional 'transport';
> > > but worse if we commit to the interface of 3/4 and don't get the
> > > conversion made in time to the nicer interface.  At least it's okay from
> > > back-compat perspective to make a mandatory field become optional in
> > > later releases.
> > >
> > > If it were just gluster code I was worried about, then I could live with
> > > the interface proposal.  But since seeing this error message is making
> > > me double-guess the interface correctness, and that will have an impact
> > > on libvirt, I'm starting to have doubts on what it means for qemu 2.5.
> >
> >



Re: [Qemu-devel] [PATCH 4/4] block/gluster: add support for multiple gluster servers

2016-02-05 Thread Prasanna Kumar Kalever
On Thursday, February 4, 2016 6:52:15 PM Kevin Wolf Wrote:
> Am 12.11.2015 um 23:36 hat Eric Blake geschrieben:
> > On 11/12/2015 03:22 AM, Prasanna Kumar Kalever wrote:
> > > +static struct glfs *qemu_gluster_init(BlockdevOptionsGluster **gconf,
> > > +  const char *filename,
> > > +  QDict *options, Error **errp)
> > > +{
> > > +int ret;
> > > +
> > > +if (filename) {
> > > +ret = qemu_gluster_parseuri(gconf, filename);
> > > +if (ret < 0) {
> > > +error_setg(errp, "Usage:
> > > file=gluster[+transport]://[host[:port]]/"
> > > + "volume/path[?socket=...]");
> > 
> > Hmm, just noticing this now, even though this error message is just code
> > motion.  It looks like the optional [?socket=...] part of a URI is only
> > important when using gluster+unix (is it silently ignored otherwise?).
> > And if it is used, you are then assigning it to the host field?
> > 
> > I almost wonder if GlusterServer should be a discriminated union.  That
> > is, in qapi-pseudocode (won't actually compile yet, because it depends
> > on features that I have queued for 2.6):
> > 
> > { 'union':'GlusterServer', 'base':{'transport':'GlusterTransport'},
> >   'discriminator':'transport', 'data':{
> > 'tcp':{'host':'str', '*port':'uint16'},
> > 'unix':{'socket':'str'},
> > 'rdma':{...} } }
> > 
> > Hmm. Qapi doesn't (yet) allow for an optional discriminator (where the
> > omission of the discriminator picks a default branch) - another RFE for
> > my qapi work for 2.6.
> 
> Eric, Prasanna, is this QAPI extension what we're waiting for or what is
> the status of this series? Niels (CCed) was hacking on the same thing,
> so maybe it's time to get this moving again.

Kevin, correct me if I am wrong, union discriminator support is not yet added
into qemu, I am waiting for this. I spoke to Eric Blake regarding the same may 
be
a month ago from now.

-Prasanna

> 
> Kevin
> 
> > Command-line wise, this would mean you could do in JSON:
> > 
> > 'servers':[{'transport':'tcp', 'host':'foo'},
> >{'transport':'unix', 'socket':'/path/to/bar'},
> >{'host':'blah'}]
> > 
> > where the third entry defaults to transport tcp.
> > 
> > If we think that description is better than what we proposed in 3/4,
> > then it's really late to be adding it now, especially since (without
> > qapi changes) we'd have a mandatory rather than optional 'transport';
> > but worse if we commit to the interface of 3/4 and don't get the
> > conversion made in time to the nicer interface.  At least it's okay from
> > back-compat perspective to make a mandatory field become optional in
> > later releases.
> > 
> > If it were just gluster code I was worried about, then I could live with
> > the interface proposal.  But since seeing this error message is making
> > me double-guess the interface correctness, and that will have an impact
> > on libvirt, I'm starting to have doubts on what it means for qemu 2.5.
> 
> 



Re: [Qemu-devel] [PATCH 4/4] block/gluster: add support for multiple gluster servers

2016-02-04 Thread Kevin Wolf
Am 12.11.2015 um 23:36 hat Eric Blake geschrieben:
> On 11/12/2015 03:22 AM, Prasanna Kumar Kalever wrote:
> > +static struct glfs *qemu_gluster_init(BlockdevOptionsGluster **gconf,
> > +  const char *filename,
> > +  QDict *options, Error **errp)
> > +{
> > +int ret;
> > +
> > +if (filename) {
> > +ret = qemu_gluster_parseuri(gconf, filename);
> > +if (ret < 0) {
> > +error_setg(errp, "Usage: 
> > file=gluster[+transport]://[host[:port]]/"
> > + "volume/path[?socket=...]");
> 
> Hmm, just noticing this now, even though this error message is just code
> motion.  It looks like the optional [?socket=...] part of a URI is only
> important when using gluster+unix (is it silently ignored otherwise?).
> And if it is used, you are then assigning it to the host field?
> 
> I almost wonder if GlusterServer should be a discriminated union.  That
> is, in qapi-pseudocode (won't actually compile yet, because it depends
> on features that I have queued for 2.6):
> 
> { 'union':'GlusterServer', 'base':{'transport':'GlusterTransport'},
>   'discriminator':'transport', 'data':{
> 'tcp':{'host':'str', '*port':'uint16'},
> 'unix':{'socket':'str'},
> 'rdma':{...} } }
> 
> Hmm. Qapi doesn't (yet) allow for an optional discriminator (where the
> omission of the discriminator picks a default branch) - another RFE for
> my qapi work for 2.6.

Eric, Prasanna, is this QAPI extension what we're waiting for or what is
the status of this series? Niels (CCed) was hacking on the same thing,
so maybe it's time to get this moving again.

Kevin

> Command-line wise, this would mean you could do in JSON:
> 
> 'servers':[{'transport':'tcp', 'host':'foo'},
>{'transport':'unix', 'socket':'/path/to/bar'},
>{'host':'blah'}]
> 
> where the third entry defaults to transport tcp.
> 
> If we think that description is better than what we proposed in 3/4,
> then it's really late to be adding it now, especially since (without
> qapi changes) we'd have a mandatory rather than optional 'transport';
> but worse if we commit to the interface of 3/4 and don't get the
> conversion made in time to the nicer interface.  At least it's okay from
> back-compat perspective to make a mandatory field become optional in
> later releases.
> 
> If it were just gluster code I was worried about, then I could live with
> the interface proposal.  But since seeing this error message is making
> me double-guess the interface correctness, and that will have an impact
> on libvirt, I'm starting to have doubts on what it means for qemu 2.5.



Re: [Qemu-devel] [PATCH 4/4] block/gluster: add support for multiple gluster servers

2015-11-12 Thread Eric Blake
On 11/12/2015 03:22 AM, Prasanna Kumar Kalever wrote:
> This patch adds a way to specify multiple volfile servers to the gluster
> block backend of QEMU with tcp|rdma transport types and their port numbers.
> 

> This patch gives a mechanism to provide all the server addresses, which are in
> replica set, so in case host1 is down VM can still boot from any of the
> active hosts.
> 
> This is equivalent to the backup-volfile-servers option supported by
> mount.glusterfs (FUSE way of mounting gluster volume)
> 
> Credits: Sincere thanks to Kevin Wolf  and
> "Deepak C Shetty"  for inputs and all their support
> 
> Signed-off-by: Prasanna Kumar Kalever 
> ---
>  block/gluster.c  | 288 
> ---
>  qapi/block-core.json |   4 +-
>  2 files changed, 252 insertions(+), 40 deletions(-)

All right - the diffstat is smaller this time around (288 is nicer than
468 lines changed in v13).  There's always a psychological barrier to
reviewing large patches, and breaking things into bite-sized chunks
helps even if the same amount of work is done overall.

> 
> diff --git a/block/gluster.c b/block/gluster.c
> index 615f28b..ba209cf 100644
> --- a/block/gluster.c
> +++ b/block/gluster.c
> @@ -12,6 +12,13 @@
>  #include "qemu/uri.h"
>  
>  #define GLUSTER_OPT_FILENAME"filename"
> +#define GLUSTER_OPT_VOLUME  "volume"
> +#define GLUSTER_OPT_PATH"path"
> +#define GLUSTER_OPT_HOST"host"
> +#define GLUSTER_OPT_PORT"port"
> +#define GLUSTER_OPT_TRANSPORT   "transport"
> +#define GLUSTER_OPT_SERVER_PATTERN  "server."
> +
>  #define GLUSTER_DEFAULT_PORT24007

Once again, I'm jumping to the interface first [1]


> @@ -131,6 +178,7 @@ static int qemu_gluster_parseuri(BlockdevOptionsGluster 
> **pgconf,
>   const char *filename)
>  {
>  BlockdevOptionsGluster *gconf;
> +GlusterServer *gsconf;
>  URI *uri;
>  QueryParams *qp = NULL;
>  bool is_unix = false;
> @@ -142,23 +190,24 @@ static int qemu_gluster_parseuri(BlockdevOptionsGluster 
> **pgconf,
>  }
>  
>  gconf = g_new0(BlockdevOptionsGluster, 1);
> -gconf->server = g_new0(GlusterServer, 1);
> +gconf->server = g_new0(GlusterServerList, 1);
> +gconf->server->value = gsconf = g_new0(GlusterServer, 1);
>  
>  /* transport */
>  if (!uri->scheme || !strcmp(uri->scheme, "gluster")) {
> -gconf->server->transport = GLUSTER_TRANSPORT_TCP;
> +gsconf->transport = GLUSTER_TRANSPORT_TCP;

Most of the changes here in parseuri could have been in patch 3/4 if we
weren't churning on the qapi definition.  But looks like your conversion
here is correct.

> -static struct glfs *qemu_gluster_init(BlockdevOptionsGluster **pgconf,
> -  const char *filename, Error **errp)
> +static struct glfs *qemu_gluster_glfs_init(BlockdevOptionsGluster *gconf,
> +   Error **errp)
>  {

I might have split the refactoring of qemu_gluster_glfs_init() into its
own patch, but not the end of the world the way it was done here.

>  struct glfs *glfs;
>  int ret;
>  int old_errno;
> -BlockdevOptionsGluster *gconf;
> -
> -ret = qemu_gluster_parseuri(&gconf, filename);
> -if (ret < 0) {
> -error_setg(errp, "Usage: file=gluster[+transport]://[host[:port]]/"
> - "volume/path[?socket=...]");
> -errno = -ret;
> -goto out;
> -}
> +GlusterServerList *server;
>  
>  glfs = glfs_new(gconf->volume);
>  if (!glfs) {
>  goto out;
>  }
>  
> -ret = glfs_set_volfile_server(glfs,
> -  
> GlusterTransport_lookup[gconf->server->transport],
> -  gconf->server->host, gconf->server->port);
> -if (ret < 0) {
> -goto out;
> +for (server = gconf->server; server; server = server->next) {

I still wonder if gconf->servers (and therefore servers.0, servers.1 in
the command line, instead of server.0, server.1) would have been a
better name for the list, but I don't know if it is worth repainting the
bikeshed at this point in time.  On the other hand, it's user-visible,
so once it gets released, we're stuck with the name, but up until then,
we can do a followup patch if anyone else has a strong opinion.

> +ret = glfs_set_volfile_server(glfs,
> +  
> GlusterTransport_lookup[server->value->transport],
> +  server->value->host, 
> server->value->port);

I asked in v13 if all initializations set the optional transport and
port.  See [3] below

> +if (ret < 0) {
> +goto out;
> +}
>  }
>  
>  /*
> @@ -244,10 +287,9 @@ static struct glfs 
> *qemu_gluster_init(BlockdevOptionsGluster **pgconf,
>  ret = glfs_init(glfs);
>  if (ret) {
>  error_setg_errno(errp, errno,
> -   

Re: [Qemu-devel] [PATCH 4/4] block/gluster: add support for multiple gluster servers

2015-11-12 Thread Jeff Cody
On Thu, Nov 12, 2015 at 03:52:08PM +0530, Prasanna Kumar Kalever wrote:
> This patch adds a way to specify multiple volfile servers to the gluster
> block backend of QEMU with tcp|rdma transport types and their port numbers.
> 
> Problem:
> 
> Currently VM Image on gluster volume is specified like this:
> 
> file=gluster[+tcp]://host[:port]/testvol/a.img
> 
> Assuming we have three hosts in trusted pool with replica 3 volume
> in action and unfortunately host (mentioned in the command above) went down
> for some reason, since the volume is replica 3 we now have other 2 hosts
> active from which we can boot the VM.
> 
> But currently there is no mechanism to pass the other 2 gluster host
> addresses to qemu.
> 
> Solution:
> 
> New way of specifying VM Image on gluster volume with volfile servers:
> (We still support old syntax to maintain backward compatibility)
> 
> Basic command line syntax looks like:
> 
> Pattern I:
>  -drive driver=gluster,
> volume=testvol,path=/path/a.raw,
> server.0.host=1.2.3.4,
>[server.0.port=24007,]
>[server.0.transport=tcp,]
> server.1.host=5.6.7.8,
>[server.1.port=24008,]
>[server.1.transport=rdma,] ...
> 
> Pattern II:
>  'json:{"driver":"qcow2","file":{"driver":"gluster",
>"volume":"testvol","path":"/path/a.qcow2",
>"server":[{tuple0},{tuple1}, ...{tupleN}]}}'
> 
>driver  => 'gluster' (protocol name)
>volume  => name of gluster volume where our VM image resides
>path=> absolute path of image in gluster volume
> 
>   {tuple}  => {"host":"1.2.3.4"[,"port":"24007","transport":"tcp"]}
> 
>host=> host address (hostname/ipv4/ipv6 addresses)
>port=> port number on which glusterd is listening. (default 24007)
>transport   => transport type used to connect to gluster management daemon,
>it can be tcp|rdma (default 'tcp')
> 
> Examples:
> 1.
>  -drive driver=qcow2,file.driver=gluster,
> file.volume=testvol,file.path=/path/a.qcow2,
> file.server.0.host=1.2.3.4,
> file.server.0.port=24007,
> file.server.0.transport=tcp,
> file.server.1.host=5.6.7.8,
> file.server.1.port=24008,
> file.server.1.transport=rdma
> 2.
>  'json:{"driver":"qcow2","file":{"driver":"gluster","volume":"testvol",
>  "path":"/path/a.qcow2","server":
>  [{"host":"1.2.3.4","port":"24007","transport":"tcp"},
>   {"host":"4.5.6.7","port":"24008","transport":"rdma"}] } }'
> 
> This patch gives a mechanism to provide all the server addresses, which are in
> replica set, so in case host1 is down VM can still boot from any of the
> active hosts.
> 
> This is equivalent to the backup-volfile-servers option supported by
> mount.glusterfs (FUSE way of mounting gluster volume)
> 
> Credits: Sincere thanks to Kevin Wolf  and
> "Deepak C Shetty"  for inputs and all their support
> 
> Signed-off-by: Prasanna Kumar Kalever 
> ---
>  block/gluster.c  | 288 
> ---
>  qapi/block-core.json |   4 +-
>  2 files changed, 252 insertions(+), 40 deletions(-)
> 
> diff --git a/block/gluster.c b/block/gluster.c
> index 615f28b..ba209cf 100644
> --- a/block/gluster.c
> +++ b/block/gluster.c
> @@ -12,6 +12,13 @@
>  #include "qemu/uri.h"
>  
>  #define GLUSTER_OPT_FILENAME"filename"
> +#define GLUSTER_OPT_VOLUME  "volume"
> +#define GLUSTER_OPT_PATH"path"
> +#define GLUSTER_OPT_HOST"host"
> +#define GLUSTER_OPT_PORT"port"
> +#define GLUSTER_OPT_TRANSPORT   "transport"
> +#define GLUSTER_OPT_SERVER_PATTERN  "server."
> +
>  #define GLUSTER_DEFAULT_PORT24007
>  
>  
> @@ -64,6 +71,46 @@ static QemuOptsList runtime_opts = {
>  },
>  };
>  
> +static QemuOptsList runtime_json_opts = {
> +.name = "gluster_json",
> +.head = QTAILQ_HEAD_INITIALIZER(runtime_json_opts.head),
> +.desc = {
> +{
> +.name = GLUSTER_OPT_VOLUME,
> +.type = QEMU_OPT_STRING,
> +.help = "name of gluster volume where VM image resides",
> +},
> +{
> +.name = GLUSTER_OPT_PATH,
> +.type = QEMU_OPT_STRING,
> +.help = "absolute path to image file in gluster volume",
> +},
> +{ /* end of list */ }
> +},
> +};
> +
> +static QemuOptsList runtime_tuple_opts = {
> +.name = "gluster_tuple",
> +.head = QTAILQ_HEAD_INITIALIZER(runtime_tuple_opts.head),
> +.desc = {
> +{
> +.name = GLUSTER_OPT_HOST,
> +.type = QEMU_OPT_STRING,
> +.help = "host address (hostname/ipv4/ipv6 addresses)",
> +},
> +{
> +.name = GLUSTER_OPT_PORT,
> +.type = QEMU_OPT_NUMBER,
> +.help = "port number on which glusterd is listening (default 
> 24007)",
> +},
> +{
> +.name = GLUSTER_OPT_TRANSPORT,
> +.type 

[Qemu-devel] [PATCH 4/4] block/gluster: add support for multiple gluster servers

2015-11-12 Thread Prasanna Kumar Kalever
This patch adds a way to specify multiple volfile servers to the gluster
block backend of QEMU with tcp|rdma transport types and their port numbers.

Problem:

Currently VM Image on gluster volume is specified like this:

file=gluster[+tcp]://host[:port]/testvol/a.img

Assuming we have three hosts in trusted pool with replica 3 volume
in action and unfortunately host (mentioned in the command above) went down
for some reason, since the volume is replica 3 we now have other 2 hosts
active from which we can boot the VM.

But currently there is no mechanism to pass the other 2 gluster host
addresses to qemu.

Solution:

New way of specifying VM Image on gluster volume with volfile servers:
(We still support old syntax to maintain backward compatibility)

Basic command line syntax looks like:

Pattern I:
 -drive driver=gluster,
volume=testvol,path=/path/a.raw,
server.0.host=1.2.3.4,
   [server.0.port=24007,]
   [server.0.transport=tcp,]
server.1.host=5.6.7.8,
   [server.1.port=24008,]
   [server.1.transport=rdma,] ...

Pattern II:
 'json:{"driver":"qcow2","file":{"driver":"gluster",
   "volume":"testvol","path":"/path/a.qcow2",
   "server":[{tuple0},{tuple1}, ...{tupleN}]}}'

   driver  => 'gluster' (protocol name)
   volume  => name of gluster volume where our VM image resides
   path=> absolute path of image in gluster volume

  {tuple}  => {"host":"1.2.3.4"[,"port":"24007","transport":"tcp"]}

   host=> host address (hostname/ipv4/ipv6 addresses)
   port=> port number on which glusterd is listening. (default 24007)
   transport   => transport type used to connect to gluster management daemon,
   it can be tcp|rdma (default 'tcp')

Examples:
1.
 -drive driver=qcow2,file.driver=gluster,
file.volume=testvol,file.path=/path/a.qcow2,
file.server.0.host=1.2.3.4,
file.server.0.port=24007,
file.server.0.transport=tcp,
file.server.1.host=5.6.7.8,
file.server.1.port=24008,
file.server.1.transport=rdma
2.
 'json:{"driver":"qcow2","file":{"driver":"gluster","volume":"testvol",
 "path":"/path/a.qcow2","server":
 [{"host":"1.2.3.4","port":"24007","transport":"tcp"},
  {"host":"4.5.6.7","port":"24008","transport":"rdma"}] } }'

This patch gives a mechanism to provide all the server addresses, which are in
replica set, so in case host1 is down VM can still boot from any of the
active hosts.

This is equivalent to the backup-volfile-servers option supported by
mount.glusterfs (FUSE way of mounting gluster volume)

Credits: Sincere thanks to Kevin Wolf  and
"Deepak C Shetty"  for inputs and all their support

Signed-off-by: Prasanna Kumar Kalever 
---
 block/gluster.c  | 288 ---
 qapi/block-core.json |   4 +-
 2 files changed, 252 insertions(+), 40 deletions(-)

diff --git a/block/gluster.c b/block/gluster.c
index 615f28b..ba209cf 100644
--- a/block/gluster.c
+++ b/block/gluster.c
@@ -12,6 +12,13 @@
 #include "qemu/uri.h"
 
 #define GLUSTER_OPT_FILENAME"filename"
+#define GLUSTER_OPT_VOLUME  "volume"
+#define GLUSTER_OPT_PATH"path"
+#define GLUSTER_OPT_HOST"host"
+#define GLUSTER_OPT_PORT"port"
+#define GLUSTER_OPT_TRANSPORT   "transport"
+#define GLUSTER_OPT_SERVER_PATTERN  "server."
+
 #define GLUSTER_DEFAULT_PORT24007
 
 
@@ -64,6 +71,46 @@ static QemuOptsList runtime_opts = {
 },
 };
 
+static QemuOptsList runtime_json_opts = {
+.name = "gluster_json",
+.head = QTAILQ_HEAD_INITIALIZER(runtime_json_opts.head),
+.desc = {
+{
+.name = GLUSTER_OPT_VOLUME,
+.type = QEMU_OPT_STRING,
+.help = "name of gluster volume where VM image resides",
+},
+{
+.name = GLUSTER_OPT_PATH,
+.type = QEMU_OPT_STRING,
+.help = "absolute path to image file in gluster volume",
+},
+{ /* end of list */ }
+},
+};
+
+static QemuOptsList runtime_tuple_opts = {
+.name = "gluster_tuple",
+.head = QTAILQ_HEAD_INITIALIZER(runtime_tuple_opts.head),
+.desc = {
+{
+.name = GLUSTER_OPT_HOST,
+.type = QEMU_OPT_STRING,
+.help = "host address (hostname/ipv4/ipv6 addresses)",
+},
+{
+.name = GLUSTER_OPT_PORT,
+.type = QEMU_OPT_NUMBER,
+.help = "port number on which glusterd is listening (default 
24007)",
+},
+{
+.name = GLUSTER_OPT_TRANSPORT,
+.type = QEMU_OPT_STRING,
+.help = "transport type 'tcp' or 'rdma' (default 'tcp')",
+},
+{ /* end of list */ }
+},
+};
 
 static int parse_volume_options(BlockdevOptionsGluster *gconf, char *path)
 {
@@ -131,6 +178,7 @@ static int qemu_gluster_parseuri(BlockdevOptionsGluster 
**pgconf,
  const ch