From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM call agenda for Apr 27 Date: Tue, 27 Apr 2010 12:22:39 +0300 Message-ID: <4BD6ACDF.8090705@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Chris Wright , kvm@vger.kernel.org, qemu-devel@nongnu.org, Kevin Wolf To: dlaor@redhat.com Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60573 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754238Ab0D0JWn (ORCPT ); Tue, 27 Apr 2010 05:22:43 -0400 In-Reply-To: <4BD6A995.2010006@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6h0B-0007K2-5f for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:22:47 -0400 Received: from [140.186.70.92] (port=44551 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6h09-0007Jc-Mu for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:22:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6h07-0003GX-OT for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:22:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16195) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6h07-0003GM-Fl for qemu-devel@nongnu.org; Tue, 27 Apr 2010 05:22:43 -0400 Message-ID: <4BD6ACDF.8090705@redhat.com> Date: Tue, 27 Apr 2010 12:22:39 +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> <4BD6A995.2010006@redhat.com> In-Reply-To: <4BD6A995.2010006@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: dlaor@redhat.com Cc: Chris Wright , Kevin Wolf , kvm@vger.kernel.org, qemu-devel@nongnu.org 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. -- error compiling committee.c: too many arguments to function