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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list