Re: [Qemu-devel] [RFC PATCH 0/2] GlusterFS support in QEMU - v2

[Markus Armbruster]

Stefan Hajnoczi <address@hidden> writes:

> On Mon, Jul 23, 2012 at 9:50 AM, Bharata B Rao
> <address@hidden> wrote:
>> On Sun, Jul 22, 2012 at 03:42:28PM +0100, Stefan Hajnoczi wrote:
>>> On Sat, Jul 21, 2012 at 9:29 AM, Bharata B Rao
>>> <address@hidden> wrote:
>>> > -drive file=gluster:address@hidden:volname:image
>>> >
>>> > - Here 'gluster' is the protocol.
>>> > - 'address@hidden' specifies the server where the volume file
>>> > specification for
>>> >   the given volume resides. 'port' is the port number on which gluster
>>> >   management daemon (glusterd) is listening. This is optional and if not
>>> >   specified, QEMU will send 0 which will make libgfapi to use the default
>>> >   port.
>>>
>>> 'address@hidden' is weird notation.  Normally it is 'server:port' (e.g.
>>> URLs).  Can you change it?
>>
>> I don't like but, but settled for it since port was optional and : was
>> being used as separator here.

For what it's worth, icsi.c uses

iscsi://[<username>%<password>@]<host>[:<port>]/<targetname>/<lun>

>>> What about the other transports supported by libgfapi: UNIX domain
>>> sockets and RDMA?  My reading of glfs.h is that there are 3 connection
>>> options:
>>> 1. 'transport': 'socket' (default), 'unix', 'rdma'
>>> 2. 'host': server hostname for 'socket', path to UNIX domain socket
>>> for 'unix', or something else for 'rdma'
>>> 3. 'port': TCP port when 'socket' is used.  Ignored otherwise.
>>>
>>> Unfortunately QEMU block drivers cannot take custom options yet.  That
>>> would make it possible to cleanly map these connection options and
>>> save you from inventing syntax which doesn't expose all options.
>>>
>>> In the meantime it would be nice if the syntax exposed all options.
>>
>> So without the capability to pass custom options to block drivers, am I 
>> forced
>> to keep extending the file= with more and more options ?
>>
>> file=gluster:transport:server:port:volname:image ?
>>
>> Looks ugly and not easy to make any particular option optional. If
>> needed I can
>> support this from GlusterFS backend.
>
> Kevin, Markus: Any thoughts on passing options to block drivers?
> Encoding GlusterFS options into a "filename" string is pretty
> cumbersome.

Yes, it is.  Every block driver with special parameters has its own ad
hoc parser, and some of them are badly designed.

I'm working on a sane way to configure block drivers.  Until we got
that, encoding parameters into the "filename" is what you have to do.

Once we got it, block drivers shouldn't be required to expose *all*
their parameters via -drive's encoded "filename".