From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMf9Q-0002LE-Jl for qemu-devel@nongnu.org; Thu, 19 Sep 2013 10:24:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMf9K-0005Y4-Jg for qemu-devel@nongnu.org; Thu, 19 Sep 2013 10:24:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMf9K-0005Xc-C6 for qemu-devel@nongnu.org; Thu, 19 Sep 2013 10:24:06 -0400 Date: Thu, 19 Sep 2013 16:23:54 +0200 From: Kevin Wolf Message-ID: <20130919142354.GC3631@dhcp-200-207.str.redhat.com> References: <20130917124413.GA822@stefanha-thinkpad.str.redhat.com> <20130918150527.GA5025@irqsave.net> <20130919082653.GC22814@stefanha-thinkpad.redhat.com> <20130919085750.GA3631@dhcp-200-207.str.redhat.com> <20130919125536.GA12498@irqsave.net> <20130919132146.GB3631@dhcp-200-207.str.redhat.com> <20130919133818.GB12498@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130919133818.GB12498@irqsave.net> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Merging the quorum block driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Beno=EEt?= Canet Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, Stefan Hajnoczi Am 19.09.2013 um 15:38 hat Beno=EEt Canet geschrieben: > Le Thursday 19 Sep 2013 =E0 15:21:46 (+0200), Kevin Wolf a =E9crit : > > Am 19.09.2013 um 14:55 hat Beno=EEt Canet geschrieben: > > > Le Thursday 19 Sep 2013 =E0 10:57:50 (+0200), Kevin Wolf a =E9crit = : > > > > Am 19.09.2013 um 10:26 hat Stefan Hajnoczi geschrieben: > > > > > On Wed, Sep 18, 2013 at 05:05:27PM +0200, Beno=EEt Canet wrote: > > > > > > Le Tuesday 17 Sep 2013 =E0 14:44:13 (+0200), Stefan Hajnoczi = a =E9crit : > > > > > > > Hi Benoit, > > > > > > > Kevin and I had a chance to chat face-to-face and we discus= sed what > > > > > > > concrete changes are necessary to merge quorum (without sol= ving all the > > > > > > > other block layers problems at once). > > > > > > >=20 > > > > > > > I think quorum could be merged relatively quickly (and with= out massive > > > > > > > BlockFilter investments) by changing the following: > > > > > > >=20 > > > > > > > 1. Defining children on the command-line > > > > > > >=20 > > > > > > > Existing "filter" drivers use the protocol filename to embe= d their > > > > > > > children, for example the blkverify driver. This is a big = hack because > > > > > > > we have no proper syntax or escaping for the embedded drive= definitions > > > > > > > in the file=3D option. > > > > > > >=20 > > > > > > > This was one of the main arguments against merging quorum. = Now that > > > > > > > Kevin has implemented driver-specific open options (see > > > > > > > block/qcow2.c:qcow2_runtime_opts), it is possible for the q= uorum driver > > > > > > > to open children specific on the command-line: > > > > > > >=20 > > > > > > > -drive if=3Dnone,file.driver=3Dquorum,format=3Draw,\ > > > > > > > file.children0.file=3D/nfs1/test.qcow2,\ > > > > > > > file.children1.file=3D/nfs2/test.qcow2,\ > > > > > > > file.children2.file=3D/nfs3/test.qcow2 > > > >=20 > > > > By the way, I think he concrete syntax might have to be a bit dif= ferent > > > > so it can be mapped to QAPI for blockdev-add. I think we'll want = to use > > > > a JSON list for the children; a mapping to QDict and to the comma= nd line > > > > is yet to be implemented I guess. > > >=20 > > > Hi, > > >=20 > > > Just to make sure I'll code the right thing; is the following corre= ct ? > > >=20 > > > -drive if=3Dnone,file.driver=3Dquorum,format=3Draw,\ > > > file.children=3D[/nfs1/test.qcow2, /nfs2/test.qcow2, /nfs3/t= est.qcow2], \ > > > file.vote_threshold=3D2 > >=20 > > I was thinking more along the lines of: > >=20 > > -drive if=3Dnone,file.driver=3Dquorum,format=3Draw,\ > > file.children[0].file.filename=3D/nfs1/test.qcow2, \ > > file.children[1].file.filename=3D/nfs2/test.qcow2, \ > > file.children[1].file.cache.direct=3Don, \ > > file.children[2].file.driver=3Dnbd, \ > > file.children[2].file.host=3Dlocalhost, \ > > file.vote_threshold=3D2 > >=20 > > The exact syntax doesn't matter all that much as long as it can be > > mapped to QAPI, but as you can see this allows specifying detailed > > options even for the children. I think this is a requirement. >=20 > So does it mean that on top of your blockdev branch qemu_opts_to_qdict = should do > a little parsing of opt->name to regroup options of the same children t= ogether ? >=20 > e.g: converting the incoming qoption into the qdict equivalent of: > dict =3D { "driver": "quorum", > "children[0]": "file.filename=3D/nfs1/test.qcow2", > "children[1]": "file.filename=3D/nfs2/test.qcow2,file.cache.di= rect=3Don", > "children[2]": "file.driver=3Dnbd,file.host=3Dlocalhost", > "vote_threshold": 2 } No, the qdict is supposed to be completely flat. I think there are two parts to it: 1. Extend qdict_flatten() so that it converts QLists into an array representation. The resulting qdict should look pretty much like the command line: dict =3D { "driver": "quorum", "children[0].file.filename": "/nfs1/test.qcow2", "children[1].file.filename": "/nfs2/test.qcow2", "children[1].file.cache.direct": "on", "children[2].file.driver": "nbd", "children[2].file.host": "localhost", "vote_threshold": 2 } 2. The option parsing code in quorum must find a way to walk this flattened children array. Basically it will end up checking if the keys start with a "children[%d]", and if so, use extract_subqdict() to get the full array element back. Kevin