On Jul 23, 2012 5:36 PM, <qemu-devel-requ...@nongnu.org> wrote:
> Send Qemu-devel mailing list submissions to > qemu-devel@nongnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.nongnu.org/mailman/listinfo/qemu-devel > or, via email, send a message with subject or body 'help' to > qemu-devel-requ...@nongnu.org > > You can reach the person managing the list at > qemu-devel-ow...@nongnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Qemu-devel digest..." > > > Today's Topics: > > 1. Re: [RFC PATCH 2/2] block: gluster as block backend > (Stefan Hajnoczi) > 2. Re: [RFC PATCH 0/2] GlusterFS support in QEMU - v2 > (Daniel P. Berrange) > 3. Re: [RFC PATCH 0/2] GlusterFS support in QEMU - v2 > (Stefan Hajnoczi) > 4. Re: [RFC PATCH 0/2] GlusterFS support in QEMU - v2 > (ronnie sahlberg) > 5. Re: [RFC PATCH 0/2] GlusterFS support in QEMU - v2 > (ronnie sahlberg) > 6. Re: [RFC PATCH 0/2] GlusterFS support in QEMU - v2 > (Stefan Hajnoczi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Jul 2012 10:06:40 +0100 > From: Stefan Hajnoczi <stefa...@gmail.com> > To: bhar...@linux.vnet.ibm.com > Cc: Amar Tumballi <ama...@redhat.com>, Anand Avati > <aav...@redhat.com>, qemu-devel@nongnu.org, Vijay Bellur > <vbel...@redhat.com> > Subject: Re: [Qemu-devel] [RFC PATCH 2/2] block: gluster as block > backend > Message-ID: > < > cajsp0qu+exbjp9e_r2gaewhszkkaj8rpajoqdcouhy5jzpt...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Jul 23, 2012 at 9:32 AM, Bharata B Rao > <bhar...@linux.vnet.ibm.com> wrote: > > On Sun, Jul 22, 2012 at 04:38:00PM +0100, Stefan Hajnoczi wrote: > >> On Sat, Jul 21, 2012 at 9:31 AM, Bharata B Rao > >> <bhar...@linux.vnet.ibm.com> wrote: > >> > +} GlusterAIOCB; > >> > + > >> > +typedef struct GlusterCBKData { > >> > + GlusterAIOCB *acb; > >> > + struct BDRVGlusterState *s; > >> > + int64_t size; > >> > + int ret; > >> > +} GlusterCBKData; > >> > >> I think GlusterCBKData could just be part of GlusterAIOCB. That would > >> simplify the code a little and avoid some malloc/free. > > > > Are you suggesting to put a field > > > > GlusterCBKData gcbk; > > > > inside GlusterAIOCB and use gcbk from there or > > > > Are you suggesting that I make the fields of GlusterCBKData part of > > GlusterAIOCB and get rid of GlusterCBKData altogether ? This means I > would > > have to pass the GlusterAIOCB to gluster async calls and update its > fields from > > gluster callback routine. I can do this, but I am not sure if you can > touch > > the fields of GlusterAIOCB in non-QEMU threads (gluster callback thread). > > The fields in GlusterCBKData could become part of GlusterAIOCB. > Different threads can access fields in a struct, they just need to > ensure access is synchronized if they touch the same fields. In the > case of this code I think there is nothing that requires > synchronization beyond the pipe mechanism that you already use to > complete processing in a QEMU thread. > > >> When the argument is too long we should probably report an error > >> instead of truncating. > > > > Or should we let gluster APIs to flag an error with truncated > > server and volume names ? > > What if the truncated name is a valid but different object? For example: > Max chars = 5 > Objects: > "helloworld" > "hello" > > If "helloworld" is truncated to "hello" we get no error back because > it's a valid object! > > We need to either check sizes explicitly without truncating or use a > g_strdup() approach without any size limits and let the gfapi > functions error out if the input string is too long. > > >> > +static struct glfs *qemu_gluster_init(GlusterConf *c, const char > *filename) > >> > +{ > >> > + struct glfs *glfs = NULL; > >> > + int ret; > >> > + > >> > + ret = qemu_gluster_parsename(c, filename); > >> > + if (ret < 0) { > >> > + errno = -ret; > >> > + goto out; > >> > + } > >> > + > >> > + glfs = glfs_new(c->volname); > >> > + if (!glfs) { > >> > + goto out; > >> > + } > >> > + > >> > + ret = glfs_set_volfile_server(glfs, "socket", c->server, > c->port); > >> > + if (ret < 0) { > >> > + goto out; > >> > + } > >> > + > >> > + /* > >> > + * TODO: Logging is not necessary but instead nice to have. > >> > + * Can QEMU optionally log into a standard place ? > >> > >> QEMU prints to stderr, can you do that here too? The global log file > >> is not okay, especially when multiple QEMU instances are running. > > > > Ok, I can do glfs_set_logging(glfs, "/dev/stderr", loglevel); > > Yes. I think "-" is best since it is supported by gfapi > (libglusterfs/src/logging.c:gf_log_init). /dev/stderr is not POSIX. > > >> > + * Need to use defines like gf_loglevel_t:GF_LOG_INFO instead of > >> > + * hard coded values like 7 here. > >> > + */ > >> > + ret = glfs_set_logging(glfs, "/tmp/qemu-gluster.log", 7); > >> > + if (ret < 0) { > >> > + goto out; > >> > + } > >> > + > >> > + ret = glfs_init(glfs); > >> > + if (ret < 0) { > >> > + goto out; > >> > + } > >> > + return glfs; > >> > + > >> > +out: > >> > + if (glfs) { > >> > + (void)glfs_fini(glfs); > >> > + } > >> > + return NULL; > >> > +} > >> > + > >> > +static int qemu_gluster_open(BlockDriverState *bs, const char > *filename, > >> > + int bdrv_flags) > >> > +{ > >> > + BDRVGlusterState *s = bs->opaque; > >> > + GlusterConf *c = g_malloc(sizeof(GlusterConf)); > >> > >> Can this be allocated on the stack? > > > > It consists of PATH_MAX(4096), HOST_NAME_MAX(255) and > GLUSTERD_MAX_VOLUME_NAME > > (1000). A bit heavy to be on stack ? > > This is userspace, stacks are big but it's up to you. > > Stefan > > > > ------------------------------ > > Message: 2 > Date: Mon, 23 Jul 2012 10:16:43 +0100 > From: "Daniel P. Berrange" <berra...@redhat.com> > To: Bharata B Rao <bhar...@linux.vnet.ibm.com> > Cc: Amar Tumballi <ama...@redhat.com>, Anand Avati > <aav...@redhat.com>, qemu-devel@nongnu.org, Vijay Bellur > <vbel...@redhat.com> > Subject: Re: [Qemu-devel] [RFC PATCH 0/2] GlusterFS support in QEMU - > v2 > Message-ID: <20120723091643.ga7...@redhat.com> > Content-Type: text/plain; charset=utf-8 > > On Sat, Jul 21, 2012 at 01:59:17PM +0530, Bharata B Rao wrote: > > Hi, > > > > Here is the v2 patchset for supporting GlusterFS protocol from QEMU. > > > > This set of patches enables QEMU to boot VM images from gluster volumes. > > This is achieved by adding gluster as a new block backend driver in QEMU. > > Its already possible to boot from VM images on gluster volumes, but this > > patchset provides the ability to boot VM images from gluster volumes by > > by-passing the FUSE layer in gluster. In case the image is present on the > > local system, it is possible to even bypass client and server translator > and > > hence the RPC overhead. > > > > The major change in this version is to not implement libglusterfs based > > gluster backend within QEMU but instead use libgfapi. libgfapi library > > from GlusterFS project provides APIs to access gluster volumes directly. > > With the use of libgfapi, the specification of gluster backend from QEMU > > matches more closely with the GlusterFS's way of specifying volumes. We > now > > specify the gluster backed image like this: > > > > -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. > > - 'volname' is the name of the gluster volume which contains the VM > image. > > - 'image' is the path to the actual VM image in the gluster volume. > > I don't think we should be using '@' as a field separator here, when ":" > can do that job just fine. In addition we already have a precendent set > with the sheepdog driver for using ':' for separating all fields: > > -drive file=sheepdog:example.org:6000:imagename > > If you want to allow for port number to be omitted, this can be handled > thus: > > -drive file=sheepdog:example.org::imagename > > which is how -chardev deals with omitted port numbers > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/:| > |: http://libvirt.org -o- http://virt-manager.org:| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc:| > > > > ------------------------------ > > Message: 3 > Date: Mon, 23 Jul 2012 10:20:26 +0100 > From: Stefan Hajnoczi <stefa...@gmail.com> > To: Kevin Wolf <kw...@redhat.com>, Markus Armbruster > <arm...@redhat.com> > Cc: Amar Tumballi <ama...@redhat.com>, bhar...@linux.vnet.ibm.com, > Anand Avati <aav...@redhat.com>, qemu-devel@nongnu.org, Vijay > Bellur > <vbel...@redhat.com> > Subject: Re: [Qemu-devel] [RFC PATCH 0/2] GlusterFS support in QEMU - > v2 > Message-ID: > <CAJSP0QXdLCV8FDAMLesZS4Y2tYZYLADUFj3-= > 5ayzvikjra...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 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. > > > > ------------------------------ > > Message: 4 > Date: Mon, 23 Jul 2012 19:28:53 +1000 > From: ronnie sahlberg <ronniesahlb...@gmail.com> > To: "Daniel P. Berrange" <berra...@redhat.com> > Cc: Anand Avati <aav...@redhat.com>, Vijay Bellur > <vbel...@redhat.com>, Amar Tumballi <ama...@redhat.com>, > qemu-devel@nongnu.org, Bharata B Rao <bhar...@linux.vnet.ibm.com> > Subject: Re: [Qemu-devel] [RFC PATCH 0/2] GlusterFS support in QEMU - > v2 > Message-ID: > <CAN05THQ3Y4=dJD9Ycerv0Om4jkxbFJ=WS=_ > 1oriw04hqa6-...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Why not use > > -drive file=gluster://server[:port]/volname/image > > A great many protocols today use the form > > <protocol>://<server>:<port>]/<path> > > so this would make it consistent with a lot of other naming schemes > out there, and imho make > the url more intuitive. > > > FTP looks like this : ftp://user:password@host:port/path > NFS looks like this : nfs://<host>:<port><url-path> > CIFS looks like this : > smb://[[[authdomain;]user@]host[:port][/share[/path][/name]]][?context] > > For iSCSI we use : iscsi://<server>[:<port>]/<target>/<lun> > > > (The iscsi syntax was picked explicitely to be consistent with the > de-facto url naming scheme.) > > > I would argue that this is the de-facto way to create a url for > different protocols, so it would imho be natural to specify a > glusterfs url in a similar format. > > > ronnie sahlberg > > > On Mon, Jul 23, 2012 at 7:16 PM, Daniel P. Berrange <berra...@redhat.com> > wrote: > > On Sat, Jul 21, 2012 at 01:59:17PM +0530, Bharata B Rao wrote: > >> Hi, > >> > >> Here is the v2 patchset for supporting GlusterFS protocol from QEMU. > >> > >> This set of patches enables QEMU to boot VM images from gluster volumes. > >> This is achieved by adding gluster as a new block backend driver in > QEMU. > >> Its already possible to boot from VM images on gluster volumes, but this > >> patchset provides the ability to boot VM images from gluster volumes by > >> by-passing the FUSE layer in gluster. In case the image is present on > the > >> local system, it is possible to even bypass client and server > translator and > >> hence the RPC overhead. > >> > >> The major change in this version is to not implement libglusterfs based > >> gluster backend within QEMU but instead use libgfapi. libgfapi library > >> from GlusterFS project provides APIs to access gluster volumes directly. > >> With the use of libgfapi, the specification of gluster backend from QEMU > >> matches more closely with the GlusterFS's way of specifying volumes. We > now > >> specify the gluster backed image like this: > >> > >> -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. > >> - 'volname' is the name of the gluster volume which contains the VM > image. > >> - 'image' is the path to the actual VM image in the gluster volume. > > > > I don't think we should be using '@' as a field separator here, when ":" > > can do that job just fine. In addition we already have a precendent set > > with the sheepdog driver for using ':' for separating all fields: > > > > -drive file=sheepdog:example.org:6000:imagename > > > > If you want to allow for port number to be omitted, this can be handled > > thus: > > > > -drive file=sheepdog:example.org::imagename > > > > which is how -chardev deals with omitted port numbers > > > > Regards, > > Daniel > > -- > > |: http://berrange.com -o- > http://www.flickr.com/photos/dberrange/ :| > > |: http://libvirt.org -o- > http://virt-manager.org :| > > |: http://autobuild.org -o- > http://search.cpan.org/~danberr/ :| > > |: http://entangle-photo.org -o- > http://live.gnome.org/gtk-vnc :| > > > > > > ------------------------------ > > Message: 5 > Date: Mon, 23 Jul 2012 19:34:20 +1000 > From: ronnie sahlberg <ronniesahlb...@gmail.com> > To: Stefan Hajnoczi <stefa...@gmail.com> > Cc: Kevin Wolf <kw...@redhat.com>, Anand Avati <aav...@redhat.com>, > Vijay Bellur <vbel...@redhat.com>, Amar Tumballi < > ama...@redhat.com>, > qemu-devel@nongnu.org, Markus Armbruster <arm...@redhat.com>, > bhar...@linux.vnet.ibm.com > Subject: Re: [Qemu-devel] [RFC PATCH 0/2] GlusterFS support in QEMU - > v2 > Message-ID: > <CAN05THQk4BcPoec4zsD= > 2m6fuefuhrval3k3t5xevq_unhc...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Stefan, > > in iscsi, i just specify those extra arguments that are required that > are not part of the url itself as just command line options : > > > qemu-system-i386 -iscsi initiator-name=iqn.qemu.test:my-initiator \ > -boot d -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \ > -cdrom iscsi://127.0.0.1/iqn.qemu.test/2 > > Here initiator-name is a custom option to the iscsi layer to tell it > which name to use when identifying/logging in to the target. > > Similar concept could be used by glusterfs ? > > regards > ronnie sahlberg > > > > On Mon, Jul 23, 2012 at 7:20 PM, Stefan Hajnoczi <stefa...@gmail.com> > wrote: > > 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. > > > > > > ------------------------------ > > Message: 6 > Date: Mon, 23 Jul 2012 10:35:50 +0100 > From: Stefan Hajnoczi <stefa...@gmail.com> > To: ronnie sahlberg <ronniesahlb...@gmail.com> > Cc: Kevin Wolf <kw...@redhat.com>, Anand Avati <aav...@redhat.com>, > Vijay Bellur <vbel...@redhat.com>, Amar Tumballi < > ama...@redhat.com>, > qemu-devel@nongnu.org, Markus Armbruster <arm...@redhat.com>, > bhar...@linux.vnet.ibm.com > Subject: Re: [Qemu-devel] [RFC PATCH 0/2] GlusterFS support in QEMU - > v2 > Message-ID: > < > cajsp0qwbff097qghr7q4yaluccwtpkw7oh16s-ewzpjryhg...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Jul 23, 2012 at 10:34 AM, ronnie sahlberg > <ronniesahlb...@gmail.com> wrote: > > in iscsi, i just specify those extra arguments that are required that > > are not part of the url itself as just command line options : > > > > > > qemu-system-i386 -iscsi initiator-name=iqn.qemu.test:my-initiator \ > > -boot d -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \ > > -cdrom iscsi://127.0.0.1/iqn.qemu.test/2 > > > > Here initiator-name is a custom option to the iscsi layer to tell it > > which name to use when identifying/logging in to the target. > > > > Similar concept could be used by glusterfs ? > > That works for global options only. If it's per-drive then this > approach can't be used because different drives might need different > option values. > > Stefan > > > > ------------------------------ > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/qemu-devel > > > End of Qemu-devel Digest, Vol 112, Issue 522 > ******************************************** >
