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

[Harsh Bora]

On 10/26/2012 07:08 PM, Jiri Denemark wrote:
> 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.

IIUC, a separate element for socket makes more sense if there will be 
more than one socket utilized per connection (source/target pair), which 
I am not really sure about.

Also, if there is a use case in future, we can always introduce a change 
in schema as we are doing in this patch.

regards,
Harsh


>
> Jirka
>