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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.