qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/1] block/gluster: add support for multiple glu


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 1/1] block/gluster: add support for multiple gluster backup volfile servers
Date: Thu, 10 Sep 2015 13:47:11 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 10.09.2015 um 07:42 hat Deepak Shetty geschrieben:
> [snip]
> 
> On Wed, Sep 9, 2015 at 10:37 PM, Raghavendra Talur <address@hidden> wrote:
> 
> 
> 
>     From QEMU's perspective, it would be better to use separate fields
> 
>         (that have type information) than to encode everything in an opaque
>         URI string.  Fields can do input validation in common code so that
>         block drivers don't need to check whether something is a valid number,
>         for example.  Fields can also be listed and their type information can
>         be displayed so the user knows the expected range of inputs
>         (self-documenting).
> 
> 
>     Coming from Gluster side of things,  the variable/option here is tuple of
>     three
>         transport-type
>         server
>         port 
> 
>     volname and file name should be the same in all the URIs. Just pointing
>     out here so that implementation can ensure that all URIs have the same
>     volname and filename;
>     which are testvol and a.img in the above example.
> 
>     By fields if you mean something like 
>     -drive file=gluster[+transport]://[server[:port]]/volname/image[?socket
>     =...],\
>                    
> file.backup-volfile-server=[tcp:|rdma:|unix:]server2[:port],
>                    file.backup-volfile-server=[tcp:|rdma:|unix:]server2[:port]
> 
> 
> Raghavendra,
>   Thanks for pitching in.
> 
> So are you saying that its possible to have different transport types (tcp,
> rdma etc)
> for different gluster server nodes, all of which are part of the same cluster 
> ?
> 
> If that is true then in the above suggestion of yours, gluster [+transport]://
> doesn't make sense, since it gives a feeling that the transport mentioned
> before :// applies to whole URI, only to be overridden by the later
> file.backup-volfile-server= option
> 
> Maybe then as kwolf mentioned in prev thread of this mail ...
> 
> 
>   -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

To be clear, I did _not_ say that you should use URIs. I think URIs are
a convenient shortcut syntax for simple setups. More complex setups
should use structured options, which should be defined in the QAPI
schema. The command line options are directly derived from that then.

URIs would still be supported as a shortcut syntax on the command line,
but internally they would be converted into structured options before
.bdrv_open() would be called. You can check the nbd or ssh drivers for
comparison, they already work like that.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]