From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36050 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P8hQy-0000uD-Bz for qemu-devel@nongnu.org; Wed, 20 Oct 2010 18:47:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P8hQx-000793-5M for qemu-devel@nongnu.org; Wed, 20 Oct 2010 18:47:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P8hQw-00078e-Ug for qemu-devel@nongnu.org; Wed, 20 Oct 2010 18:46:59 -0400 Message-ID: <4CBF7154.2070304@redhat.com> Date: Thu, 21 Oct 2010 00:46:44 +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> In-Reply-To: <4CBEECE6.8030605@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 , Alexander Graf , kvm@vger.kernel.org, qemu-devel@nongnu.org On 10/20/2010 03:21 PM, Anthony Liguori wrote: > On 10/20/2010 08:19 AM, Daniel P. Berrange wrote: >> The thinking with Matahari is that there is significant overlap between >> agent requirements for a physical and virtual host, so it aims to provide >> an agent that works everywhere, whether virtualized or not. All that need >> change is the communication transport (TCP vs VirtIO Serial vs legacy >> serial vs some other data channel), and enable/disable certain agent >> services according to deployment scenario. Once you go to a more general >> purpose agent in this way, then it doesn't make such sense to put it all >> in the QEMU tree. > > Actually, I don't think we want to have a common agent for physical and > virtual systems. > > The requirements are actually very different. The virtual agent exists > solely to support hypervisor functionality. Not to provide general > purpose system management support. True although there is much in common and there are several api for hypervisor only. I think it's sensible to ask for such. IMHO we can't put the complete guest agent code in qemu: - There would be OS specific code like windows and windows only interfaces (WMI) - Agents can benefits from guest frameworks like dbus. Will we take dbus into qemu or re-write it ourselves? 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? > > Regards, > > Anthony Liguori > >> Regards, >> Daniel > > -- > 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