Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend

[Kevin Wolf <kwolf@redhat.com>]

Am 07.09.2012 11:36, schrieb Paolo Bonzini:
> Il 07/09/2012 05:24, Bharata B Rao ha scritto:
>>>   gluster:///volname/image?transport=unix&sockpath=/path/to/unix/sock
>>             ^why 3 /// here ? volname is not a path, but image is.
> 
> Because the host is the local computer, i.e. empty.
> 
>> gluster://server[:port]/volname/path/to/image[?transport=...]
>>
>> With that, the different options possible are
>>
>> unix - gluster://testvol/dir/a.img?transport=unix&sockpath=/tmp/glusterd.socket
>> ipv4 - gluster://1.2.3.4:0/testvol/dir/a.img?transport=socket
>> ipv6 - gluster://[1:2:3:4:5:6:7:8]:0/testvol/a.img
>> hostname - gluster://example.org/testvol/dir/a.img
>> rdma - gluster://1.2.3.4:0/testvol/a.img?transport=rdma
>>
>> Does this look complete from the specification point of view ?
> 
> Hmm, why don't we do the exact same thing as libvirt (http://libvirt.org/remote.html):
> 
> ipv4 - gluster+tcp://1.2.3.4:0/testvol/dir/a.img
> ipv6 - gluster+tcp://[1:2:3:4:5:6:7:8]:0/testvol/a.img
> host - gluster+tcp://example.org/testvol/dir/a.img
> unix - gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket
> rdma - gluster+rdma://1.2.3.4:0/testvol/a.img
> 
> Where the default transport is tcp (i.e. gluster+tcp is the same as gluster).
> This is easily extensible, theoretically you could have something like this:
> 
> ssh - gluster+ssh://user@host/testvol/a.img?socket=/tmp/glusterd.socket

I like this. Having the type only as a parameter when it decides how the
schema must be parsed has bothered me from the start, but I hadn't
thought of this way.

Strong +1 from me.

Kevin