From: Deepak C Shetty <deepakcs@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>,
Deepak Shetty <dpkshetty@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Prasanna Kumar Kalever <prasanna.kalever@redhat.com>,
qemu-devel@nongnu.org, bharata@linux.vnet.ibm.com,
rtalur@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/1] block/gluster: add support for multiple gluster backup volfile servers
Date: Wed, 9 Sep 2015 15:49:15 +0530 [thread overview]
Message-ID: <55F007A3.4070403@redhat.com> (raw)
In-Reply-To: <20150909094629.GK9777@stefanha-thinkpad.redhat.com>
On 09/09/2015 03:16 PM, Stefan Hajnoczi wrote:
> 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
Whats the adv of this Vs extending existing gluster URI ?
This actually sounds like a lot more typing, and making qemu cmd line a
lot more lengthier :)
Is -drive file=gluster://.... same as -drive driver=gluster,
uri[0]=gluster..... ?
Also this would mean we need to change libvirt support for gluster based
network disk completely
and also maintain the old code for backward compat, right ?
thanx,
deepak
>
> This approach allows full flexibility.
>
> I have CCed Kevin in case he has comments.
>
> Stefan
next prev parent reply other threads:[~2015-09-09 10:19 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 [this message]
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
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=55F007A3.4070403@redhat.com \
--to=deepakcs@redhat.com \
--cc=bharata@linux.vnet.ibm.com \
--cc=dpkshetty@gmail.com \
--cc=kwolf@redhat.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).