qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel@nongnu.org, Deepak C Shetty <deepakcs@redhat.com>,
	bharata@linux.vnet.ibm.com, rtalur@redhat.com,
	Prasanna Kumar Kalever <prasanna.kalever@redhat.com>,
	Deepak Shetty <dpkshetty@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 1/1] block/gluster: add support for multiple gluster backup volfile servers
Date: Wed, 9 Sep 2015 12:33:32 +0200	[thread overview]
Message-ID: <20150909103332.GC4860@noname.redhat.com> (raw)
In-Reply-To: <20150909094629.GK9777@stefanha-thinkpad.redhat.com>

Am 09.09.2015 um 11:46 hat Stefan Hajnoczi geschrieben:
> On Tue, Sep 08, 2015 at 08:40:58PM +0530, Deepak Shetty wrote:
> > On Tue, Sep 8, 2015 at 8:32 PM, Daniel P. Berrange <berrange@redhat.com>
> > wrote:
> > 
> > > On Tue, Sep 08, 2015 at 06:34:09PM +0530, Prasanna Kumar Kalever wrote:
> > > > This patch adds a way to specify multiple backup volfile servers to the
> > > gluster
> > > > block backend of QEMU with both tcp and rdma transport types.
> > > >
> > > > Problem:
> > > >
> > > > Currenly VM Image on gluster volume is specified like this:
> > > >
> > > > file=gluster[+tcp]://server1:24007/testvol/a.img
> > > >
> > > > Assuming we have have three servers in trustred pool with replica 3
> > > volume
> > > > in action and unfortunately server1 (mentioned in the command above)
> > > went down
> > > > for some reason, since the volume is replica 3 we now have other 2
> > > servers
> > > > active from which we can boot the VM.
> > > >
> > > > But currently there is no mechanism to pass the other 2 gluster server
> > > > addresses to qemu.
> > > >
> > > > Solution:
> > > >
> > > > New way of specifying VM Image on gluster volume with backup volfile
> > > servers:
> > > >
> > > > file=gluster[+transport-type]://server1:24007/testvol/a.img\
> > > >      ?backup-volfile-servers=server2&backup-volfile-servers=server3
> > >
> > > Comparison with RBD syntax:
> > >
> > >   file=rbd:pool/image:auth_supported=none:\
> > >     mon_host=mon1.example.org\:6321\;mon2.example.org\:6322\;\
> > >     mon3.example.org\:6322,if=virtio,format=raw
> > >
> > > As Peter already mentioned, you're missing port numbers.
> > >
> > > It is slightly unpleasant to have different ways of specifying the first
> > > vs second, third, etc hosts. I wonder if it would be nicer to keep all
> > > the hostnames in the host part of the URI. eg
> > >
> > >
> > >  file=gluster[+transport-type]://server1:24007,server2:3553,server3:2423/testvol/a.img\
> > >       ?backup-volfile-servers=server2&backup-volfile-servers=server3
> > >
> > > Of course it ceases to be a wellformed URI at that point, so another option
> > > would be to just allow the host part of the URI to be optional, and then
> > > accept mutliple instances ofa  'server' arg, eg
> > >
> > >  file=gluster[+transport-type]:///testvol/a.img\
> > >       ?server=server1:2424&server=server2:2423&sever=server3:34222
> > >
> > >
> > Is it allowed to have this syntax and be a valid URI ? I admit i haven't
> > looked at the
> > URI rfc for a long time now, hence the Q. Also looking at rbd syntax, it
> > looks
> > to follow this model already is it ? Whats the difference between using ':'
> > to
> > separate key=value pairs Vs using '?" query syntax ? Should we look at
> > having
> > a uniform way of specifying URI be it rbd or gluster or sheepdog ... ? If
> > yes
> > what that uniform syntax be using ':" or '?" ?
> 
> Instead of trying to make a gluster:// URI that accommodates multiple
> volfile servers, perhaps the block driver can take a list of URIs.
> Something like:
> 
>   -drive driver=gluster,uri[0]=gluster[+transport-type]://server1:24007/testvol/a.img,
>                         uri[1]=gluster[+transport-type]://server2:24008/testvol/a.img,
>                         uri[2]=gluster[+transport-type]://server3:24009/testvol/a.img
> 
> This approach allows full flexibility.
> 
> I have CCed Kevin in case he has comments.

In fact, I think for more complex setups like this one it might be
appropriate to expect full structured blockdev-add style options instead
of URLs:

{ "driver": "gluster",
  "servers": [
    { "transport": "tcp", "host": "server1", "port": 24007,
       "volume": "testvol", "image": "a.img" },
    ...
  ] }

And on the command line either use the json: pseudo-protocol or the
verbose version with every option containing the full "path":

-drive driver=gluster,servers.0.transport=tcp,servers.0.host=server1,...

Kevin

      parent reply	other threads:[~2015-09-09 10:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-08 13:04 [Qemu-devel] [PATCH 1/1] block/gluster: add support for multiple gluster backup volfile servers Prasanna Kumar Kalever
2015-09-08 14:43 ` Peter Krempa
2015-09-08 15:02 ` Daniel P. Berrange
2015-09-08 15:10   ` Deepak Shetty
2015-09-09  6:06     ` Deepak C Shetty
2015-09-09  9:46     ` Stefan Hajnoczi
2015-09-09 10:19       ` Deepak C Shetty
2015-09-09 12:29         ` Stefan Hajnoczi
2015-09-09 17:07           ` Raghavendra Talur
2015-09-10  5:42             ` Deepak Shetty
2015-09-10  9:30               ` Daniel P. Berrange
2015-09-10 11:47               ` Kevin Wolf
2015-09-09 10:33       ` Kevin Wolf [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=20150909103332.GC4860@noname.redhat.com \
    --to=kwolf@redhat.com \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=deepakcs@redhat.com \
    --cc=dpkshetty@gmail.com \
    --cc=prasanna.kalever@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rtalur@redhat.com \
    --cc=stefanha@gmail.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).