qemu-devel
[Top][All Lists]
Advanced

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

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


From: Kevin Wolf
Subject: [Qemu-devel] Re: KVM call agenda for Apr 27
Date: Tue, 27 Apr 2010 11:16:57 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4

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




reply via email to

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