From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6h6M-00028D-K6 for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:29:10 -0400 Received: from [140.186.70.92] (port=33752 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6h6G-00021I-Rr for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:29:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6h6B-0004Tp-IX for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:29:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7010) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6h6A-0004TR-Pv for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:28:59 -0400 Message-ID: <4BD6AE57.1000304@redhat.com> Date: Tue, 27 Apr 2010 12:28:55 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20100426172634.GC15278@x200.localdomain> <4BD5D28C.7080700@codemonkey.ws> <20100426221258.GH15278@x200.localdomain> <4BD61584.9080208@codemonkey.ws> <4BD69D03.2050502@redhat.com> <4BD6A4CA.6070306@redhat.com> <4BD6A6BA.1090600@redhat.com> <4BD6AB89.7000609@redhat.com> In-Reply-To: <4BD6AB89.7000609@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: KVM call agenda for Apr 27 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Chris Wright , dlaor@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org 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