From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36265 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P8uqG-00046T-7f for qemu-devel@nongnu.org; Thu, 21 Oct 2010 09:06:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P8uqE-0000Gb-6e for qemu-devel@nongnu.org; Thu, 21 Oct 2010 09:05:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36687) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P8uqD-0000GO-Sl for qemu-devel@nongnu.org; Thu, 21 Oct 2010 09:05:58 -0400 Message-ID: <4CC03AAE.4090405@redhat.com> Date: Thu, 21 Oct 2010 15:05:50 +0200 From: Dor Laor MIME-Version: 1.0 Subject: Re: [Qemu-devel] KVM call minutes for Oct 19 References: <20101019151441.GA24673@x200.localdomain> <4DE00079-05FA-40DF-9EA5-9573AD745117@suse.de> <4CBEE84F.7060207@codemonkey.ws> <20101020131925.GH15143@redhat.com> <4CBEECE6.8030605@codemonkey.ws> <4CBF7154.2070304@redhat.com> <9DABD2D4-389E-4D05-8A4C-2DE1E20D3B5C@suse.de> <4CBFEF95.9060703@redhat.com> <4CC039DA.5090607@codemonkey.ws> In-Reply-To: <4CC039DA.5090607@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , "kvm@vger.kernel.org" , Alexander Graf , "qemu-devel@nongnu.org" , Paolo Bonzini On 10/21/2010 03:02 PM, Anthony Liguori wrote: > On 10/21/2010 02:45 AM, Paolo Bonzini wrote: >> On 10/21/2010 03:14 AM, Alexander Graf wrote: >>>> I agree that some agent code for basic stuff like live snapshot >>>> sync with the filesystem is small enough and worth to host within >>>> qemu. Maybe we do need more than one project? >>> >>> No, please. That's exactly what I don't want to see. The >>> libvirt/qemu/virt-man split is killing us already. How is this going >>> to become with 20 driver packs for the guest? >> >> Agreed. Not relying on Mata Hari and reinventing a dbus/WMI interface >> would be yet another case of QEMU NIH. > > I think we're about 10 steps ahead of where we should be right now. > > The first step is just identifying what interfaces we need in a guest > agent. So far, I think we can get away with a very small number of > interfaces (mainly read/write files, execute command). > >> The same argument also works on the backend BTW, it can be virtio >> serial but also a Xen pvconsole and that wheel should not be >> reinvented either. >> >> The guest agent should be a pluggable architecture, and QEMU can >> provide plugins for sync, spice, "info balloon" and everything else it >> needs. > > virtio-serial is essentially our plugin interface. The core QEMU agent > would use org.qemu.guest-agent and a spice against could use > org.spice-space.guest-agent. > > The QEMU agent should have an interface that terminates in QEMU itself. I agree that for some think with semi-transaction oriented actions like the fs-freeze on live snapshot, we need a small, self confined code base. > > Regards, > > Anthony Liguori > >> Paolo > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html