From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37522 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PJ4sr-00055U-KS for qemu-devel@nongnu.org; Thu, 18 Nov 2010 08:50:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PJ4sq-00063G-FM for qemu-devel@nongnu.org; Thu, 18 Nov 2010 08:50:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32105) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PJ4sq-00060R-2g for qemu-devel@nongnu.org; Thu, 18 Nov 2010 08:50:40 -0500 Message-ID: <4CE52F2B.6090907@redhat.com> Date: Thu, 18 Nov 2010 14:50:35 +0100 From: Jes Sorensen MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH v4 00/18] virtagent: host/guest RPC communication agent References: <1289923320-5638-1-git-send-email-mdroth@linux.vnet.ibm.com> In-Reply-To: <1289923320-5638-1-git-send-email-mdroth@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com, agl@linux.vnet.ibm.com, qemu-devel@nongnu.org, abeekhof@redhat.com On 11/16/10 17:01, Michael Roth wrote: > This set of patches is meant to be applied on top of the recently submitted Virtproxy v3 patchset. It can also be obtained at: > > git://repo.or.cz/qemu/mdroth.git virtproxy_v3 > > OVERVIEW: > > There are a wide range of use cases motivating the need for a guest agent of some sort to extend the functionality/usability/control offered by QEMU. Some examples include graceful guest shutdown/reboot and notifications thereof, copy/paste syncing between host/guest, guest statistics gathering, file access, etc. > > Ideally these would all be served by a single, easilly extensible agent that can be deployed in a wide range of guests. Virtagent is an XMLRPC server, integrated into QEMU and the Virtproxy guest daemon, aimed at providing this type of functionality. > > NOTE: The guest agent can potentially be implemented independently of virtproxy depending on the feedback, we simply make use of it to provide an abstraction from the actual transport layer (ISA vs. Virtio serial) and use it's multiplexing capabilities to avoid having to dedicate 2 isa/virtio serial ports to the virtagent service. Please evaluate these patches as being seperate from virtproxy. > Michael, On a general note, while the protocol stuff probably should go into QEMU, then I don't see the actual agent belonging in the QEMU tree. If you put it all together, you are less likely other agents are willing to adopt virtproxy. Cheers, Jes