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

[Kevin Wolf <kwolf@redhat.com>]

Am 27.04.2010 10:56, schrieb Avi Kivity:
> 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.

Hm, stupid question: What problem does this NFS thing solve? What can we
do with it that we currently can't do inside qemu?

>> the watermark code needs them too (as info, not the actual buffer).
> 
> Yeah.  It works for lvm snapshots, not for watermarks.

So even if it solves anything, it doesn't solve the watermark problem.
At least I'm not sure how you would use LVM snapshots to dynamically
grow the volume on which a qcow2 image is stored.

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

I agree. But if everyone insists on overengineering what about allowing
QMP clients to request an event for any change to a particular query-*
result? (Or rather a specific field of it, if the watermark is going to
be a blockstat.) Would need to be supported by the respective
implementation behind that query subcommand, but we can enable it one
after another without changes to the interface (except that more
parameter values start working).

If this is not overengineered enough yet, add a scripting engine to
allow specifying more complex conditions for event generation, depending
on multiple fields and so on. :-)

Kevin