From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44292 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P9fIt-00077N-8N for qemu-devel@nongnu.org; Sat, 23 Oct 2010 10:42:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P9fIH-0005bG-1p for qemu-devel@nongnu.org; Sat, 23 Oct 2010 10:42:35 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:49082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P9fIG-0005ah-V5 for qemu-devel@nongnu.org; Sat, 23 Oct 2010 10:42:00 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o9NEPpaR006835 for ; Sat, 23 Oct 2010 10:25:51 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9NEfxvO1802258 for ; Sat, 23 Oct 2010 10:41:59 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9NEfxKL023516 for ; Sat, 23 Oct 2010 10:41:59 -0400 Message-ID: <4CC2F435.1020909@linux.vnet.ibm.com> Date: Sat, 23 Oct 2010 09:41:57 -0500 From: Michael Roth MIME-Version: 1.0 References: <1287773165-24855-1-git-send-email-mdroth@linux.vnet.ibm.com> <4CC2C79D.2010504@redhat.com> In-Reply-To: <4CC2C79D.2010504@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC][PATCH 00/10] virtagent: host/guest RPC communication agent List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Beekhof Cc: aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com, agl@linux.vnet.ibm.com, qemu-devel@nongnu.org On 10/23/2010 06:31 AM, Andrew Beekhof wrote: > On 10/22/2010 08:45 PM, Michael Roth wrote: >> This set of patches is meant to be applied on top of the Virtproxy v1 >> patchset. >> >> 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 the Virtproxy guest daemon and aimed at >> providing this type of functionality. >> >> This code is very rough, and I'll to document most of the >> bugs/shortcomings we're aware of in this version of the patchset. The >> main goal of this RFC to get feedback on the types of core >> functionality we would need in an agent of this sort, as well as >> feedback on the general approach/architecture implemented here. Any >> feedback is greatly appreciated however. >> >> To start off this discussion, there have been some recent posts about >> how much an agent of this sort overlaps with the goals of the Matahari >> project (https://fedorahosted.org/matahari/). While both of these >> approaches are at least *feasible*, our use cases require > > >> the ability to deploy to guests which may not support virtio-serial, >> which currently rules Matahari out. > > Possibly there has been some miscommunication, Matahari does not require > virtio-serial. > > It will be possible to configure Matahari to use virtio-serial if it > exists, but like Virtproxy it can also be used over a regular IP network > (yes, its transparent to clients too). > Sorry, I'm aware of this but wasn't very clear here. I was speaking in the context of our cloud, or other environments where there isn't any network access between the host and the guest. This essentially leaves virtio-serial and isa-serial, and a large number of our guests don't support the former. > -- Andrew >