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 11:56:26 +0300 Message-ID: <4BD6A6BA.1090600@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> 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]:17463 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752841Ab0D0I4a (ORCPT ); Tue, 27 Apr 2010 04:56:30 -0400 In-Reply-To: <4BD6A4CA.6070306@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. > the watermark code needs them too (as info, not the actual buffer). Yeah. It works for lvm snapshots, not for watermarks. > > 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. > b) How the plugins are defined? Is it scripts? Binaries? Do they open > their own sockets? Shared objects. -- error compiling committee.c: too many arguments to function