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: Avi Kivity
Subject: [Qemu-devel] Re: KVM call agenda for Apr 27
Date: Tue, 27 Apr 2010 12:28:55 +0300
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

On 04/27/2010 12:16 PM, Kevin Wolf wrote:
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?

For example, you can't create an lvm snapshot due to privilege problems.

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.

It's separate issue. Consider a fat-provisioned lvm volume, you can't snapshot it today from within qemu.

It doesn't solve the watermark problem (qcow2 on fat-provisioned backing), I didn't think it through.

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. :-)

Any simple question has a complicated answer...

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





reply via email to

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