[Qemu-devel] Re: KVM call agenda for Apr 27

[Avi Kivity]

On 04/27/2010 12:08 PM, Dor Laor wrote:
> On 04/27/2010 11:56 AM, Avi Kivity wrote:
> > On 04/27/2010 11:48 AM, Dor Laor wrote:
> > > > Here's another option: an nbd-like protocol that remotes all 
> > > > BlockDriver
> > > > operations except read and write over a unix domain socket. The open
> > > > operation returns an fd (SCM_RIGHTS strikes again) that is used for 
> > > > read
> > > > and write. This can be used to implement snapshots over LVM, for
> > > > example.
> > >
> > >
> > > Why w/o read/writes?
> >
> > To avoid the copying.
>
> Of course, just pass the offset+len on read/write too

There will be a large performance impact.

> > > IMHO the whole thing is way over engineered:
> > > a) Having another channel into qemu is complicating management
> > > software. Isn't the monitor should be the channel? Otherwise we'll
> > > need to create another QMP (or nbd like Avi suggest) for these
> > > actions. It's extra work for mgmt and they will have hard time to
> > > understand events interleaving of the various channels
> >
> > block layer plugins allow intercepting all interesting block layer
> > events, not just write-past-a-watermark, and allow actions based on
> > those events. It's a more general solution.
>
> No problem there, as long as we do try to use the single existing QMP 
> with the plugins. Otherwise we'll create QMP2 for the block events in 
> a year from now.

I don't see how we can interleave messages from the plugin into the qmp 
stream without causing confusion.

--
error compiling committee.c: too many arguments to function