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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
