On Mon, Jul 23, 2012 at 9:50 AM, Bharata B Rao <bhar...@linux.vnet.ibm.com> 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 >> <bhar...@linux.vnet.ibm.com> wrote: >> > -drive file=gluster:server@port:volname:image >> > >> > - Here 'gluster' is the protocol. >> > - 'server@port' 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. >> >> 'server@port' 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. > >> >> 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.
