[libvirt] [PATCH v2 1/2] Qemu/Gluster: Add Gluster protocol as supported network disk formats.

[Jiri Denemark]

On Fri, Oct 26, 2012 at 15:06:19 +0530, Harsh Bora wrote:
> On 10/05/2012 05:27 PM, Paolo Bonzini wrote:
> > Il 04/10/2012 15:31, Harsh Prateek Bora ha scritto:
> >> Qemu accepts gluster protocol as supported storage backend beside others.
> >> This patch allows users to specify disks on gluster backends like this:
> >>
> >>      <disk type='network' device='disk'>
> >>        <driver name='qemu' type='raw'/>
> >>        <source protocol='gluster' name='volume/image'>
> >>          <host name='example.org' port='6000' transport='tcp'/>
> >>        </source>
> >>        <target dev='vda' bus='virtio'/>
> >>      </disk>
> >>
> >> Note: In the <host> element above, transport is an optional attribute.
> >> Valid transport values are tcp, unix or rdma. If none specified, tcp is assumed.
> >> If transport type is unix, host name specifies path to unix socket.
> >
> > I would rather add a new attribute "socket" than overload the host name.
> >   The host name for Unix sockets is really localhost.
> 
> After looking into the URI infra, I realized, it is better to have the 
> new attribute name as 'query' since socket=</path/to/socket> in 
> qemu-gluster commandline is nothing but a query in the whole URI 
> following by a '?' character.
> 
> Since, the _virURI struct in libvirt also has a member 'query' for the 
> query string in a URI, it makes sense to keep the XML attribute as 
> generic as that so that it can be used by others for related purpose.
> 
> Needless to say, users will have to specify sockets as
> <host name='example.org' port='6000' transport='unix' 
> query='socket=/path/to/sock' />

Ah, this looks horrible. We really want to avoid specifying random garbage for
hostname and port in case of unix transport. What Paolo is suggesting is to
create

    <host name='example.org' port='6000' transport='tcp'/> or
    <host socket='/path/to/sock' transport='unix'/>

However, I don't like this too much either. What if we add a general socket
element? In other words,

    <host name='example.org' port='6000' transport='tcp|rdma'/> or
    <socket type='unix' path='/path/to/sock'/>

where the type attribute in socket element would determine what other
attributes can be used (path for unix sockets). Internally, both elements
could be described by a unified socket structure.

Jirka