From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6h8m-0003cP-KU for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:31:41 -0400 Received: from [140.186.70.92] (port=50070 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6h8a-0003Wr-DJ for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:31:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6h8U-0004vD-KR for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:31:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22816) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6h8U-0004uv-Cp for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:31:22 -0400 Message-ID: <4BD6AF41.2090909@redhat.com> Date: Tue, 27 Apr 2010 12:32:49 +0300 From: Dor Laor 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> <4BD6A995.2010006@redhat.com> <4BD6ACDF.8090705@redhat.com> In-Reply-To: <4BD6ACDF.8090705@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 Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Chris Wright , Kevin Wolf , kvm@vger.kernel.org, qemu-devel@nongnu.org On 04/27/2010 12:22 PM, Avi Kivity wrote: > On 04/27/2010 12:08 PM, Dor Laor wrote: >> On 04/27/2010 11:56 AM, Avi Kivity wrote: >>> 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. >> >> Of course, just pass the offset+len on read/write too > > There will be a large performance impact. > >>>> >>>> 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 >>> >>> block layer plugins allow intercepting all interesting block layer >>> events, not just write-past-a-watermark, and allow actions based on >>> those events. It's a more general solution. >> >> No problem there, as long as we do try to use the single existing QMP >> with the plugins. Otherwise we'll create QMP2 for the block events in >> a year from now. > > I don't see how we can interleave messages from the plugin into the qmp > stream without causing confusion. Those are QMP async events. Since Kevin suggested adding even more events (was is cynical?) maybe we can use optional QMP opaque block events that the plugin issues and it will travel using the standard QMP connection as async event to the interested mgmt app. Once stabilized each event can go into the official QMP protocol.