qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Merging the quorum block driver


From: Benoît Canet
Subject: Re: [Qemu-devel] Merging the quorum block driver
Date: Thu, 19 Sep 2013 15:38:18 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Le Thursday 19 Sep 2013 à 15:21:46 (+0200), Kevin Wolf a écrit :
> Am 19.09.2013 um 14:55 hat Benoît Canet geschrieben:
> > Le Thursday 19 Sep 2013 à 10:57:50 (+0200), Kevin Wolf a écrit :
> > > Am 19.09.2013 um 10:26 hat Stefan Hajnoczi geschrieben:
> > > > On Wed, Sep 18, 2013 at 05:05:27PM +0200, Benoît Canet wrote:
> > > > > Le Tuesday 17 Sep 2013 à 14:44:13 (+0200), Stefan Hajnoczi a écrit :
> > > > > > Hi Benoit,
> > > > > > Kevin and I had a chance to chat face-to-face and we discussed what
> > > > > > concrete changes are necessary to merge quorum (without solving all 
> > > > > > the
> > > > > > other block layers problems at once).
> > > > > > 
> > > > > > I think quorum could be merged relatively quickly (and without 
> > > > > > massive
> > > > > > BlockFilter investments) by changing the following:
> > > > > > 
> > > > > > 1. Defining children on the command-line
> > > > > > 
> > > > > > Existing "filter" drivers use the protocol filename to embed 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= option.
> > > > > > 
> > > > > > 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 quorum 
> > > > > > driver
> > > > > > to open children specific on the command-line:
> > > > > > 
> > > > > >   -drive if=none,file.driver=quorum,format=raw,\
> > > > > >          file.children0.file=/nfs1/test.qcow2,\
> > > > > >          file.children1.file=/nfs2/test.qcow2,\
> > > > > >          file.children2.file=/nfs3/test.qcow2
> > > 
> > > By the way, I think he concrete syntax might have to be a bit different
> > > 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 command line
> > > is yet to be implemented I guess.
> > 
> > Hi,
> > 
> > Just to make sure I'll code the right thing; is the following correct ?
> > 
> > -drive if=none,file.driver=quorum,format=raw,\
> >        file.children=[/nfs1/test.qcow2, /nfs2/test.qcow2, 
> > /nfs3/test.qcow2], \
> >        file.vote_threshold=2
> 
> I was thinking more along the lines of:
> 
>     -drive if=none,file.driver=quorum,format=raw,\
>            file.children[0].file.filename=/nfs1/test.qcow2, \
>            file.children[1].file.filename=/nfs2/test.qcow2, \
>            file.children[1].file.cache.direct=on, \
>            file.children[2].file.driver=nbd, \
>            file.children[2].file.host=localhost, \
>            file.vote_threshold=2
> 
> 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.

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 together ?

e.g: converting the incoming qoption into the qdict equivalent of:
dict = { "driver": "quorum",
         "children[0]": "file.filename=/nfs1/test.qcow2",
         "children[1]": "file.filename=/nfs2/test.qcow2,file.cache.direct=on",
         "children[2]": "file.driver=nbd,file.host=localhost",
         "vote_threshold": 2 }

Best regards

Benoît



reply via email to

[Prev in Thread] Current Thread [Next in Thread]