From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41021 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAUar-0007x7-OR for qemu-devel@nongnu.org; Mon, 25 Oct 2010 17:28:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PAUao-0002bu-4l for qemu-devel@nongnu.org; Mon, 25 Oct 2010 17:28:37 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:38099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PAUan-0002bd-VO for qemu-devel@nongnu.org; Mon, 25 Oct 2010 17:28:34 -0400 Received: by qwf7 with SMTP id 7so1951799qwf.4 for ; Mon, 25 Oct 2010 14:28:33 -0700 (PDT) Message-ID: <4CC5F683.5080907@codemonkey.ws> Date: Mon, 25 Oct 2010 16:28:35 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC][PATCH 00/10] virtagent: host/guest RPC communication agent References: <1287773165-24855-1-git-send-email-mdroth@linux.vnet.ibm.com> <4CC55C59.1010202@redhat.com> In-Reply-To: <4CC55C59.1010202@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Beekhof Cc: ryanh@us.ibm.com, agl@linux.vnet.ibm.com, Michael Roth , qemu-devel@nongnu.org On 10/25/2010 05:30 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. >> This support could be added however: the virtproxy layer used by this >> agent actually lends itself to extending such support to other >> agents/services, or a more direct approach could be taken in adding >> support for isa-serial. >> >> The question that remains however is one of scope. >> This agent is intended purely as a means to extend qemu's abilities >> to perform hypervisor-specific work, > > "shutdown/reboot", "statistics", "file gathering"... none of those > sound very "hypervisor-specific" to me ;-) A hypervisor initiated shutdown is very different than a network initiated shutdown. >> whereas Matahari aims to extend general system management >> capabilities to guests (please correct me if I'm oversimplifying). > > As I replied elsewhere, Matahari is both an architecture and a > collection of independent but commonly useful agents. > > So while there will be a bunch of other agents doing a bunch of things > you don't care about, you don't have to care that they exist either :-) > > A hypothetical QEMU agent would be a independent entity, with both the > daemon and source code completely isolated from any other agents. > > It doesn't even need to live in the Matahari project. I've taken a deeper look at Matahari. First thing I've noticed is that the AMQP seems to be unfriendly to C. QPID and it's friends are all implemented in C++ as it Matahari itself. The lack of a C client library is a deal breaker for QEMU because it makes it impossible to integrate into QEMU. The second thing that I've observed is that AMQP is less oriented toward point-to-point communication than, say, XML-RPC but rather focuses on a pub/sub model. This is not a bad thing, but I wonder if there are any real cases where it makes sense as a guest agent. It seems like a high complexity cost without a lot of return. >> Virtagent cannot meet Matahari's goals, whereas Matahari technically >> can meet Virtagent's. >> My contention however is that the qemu-specific scope/API and shared >> code base with a more closely integrated agent will provide a more >> expedient route to functional improvements to qemu, > > See above. Would leveraging the Matahari architecture but keeping the > agent in the QEMU project address this concern? Biggest is going to be the fact that it's not C-friendly. >> while still allowing for the additional functionality/management >> capabilities provided by something like Matahari. >> >> DESIGN: >> >> There are actually 2 RPC servers: >> >> 1) a server in the guest integrated into the Virtproxy guest daemon >> which handles RPC requests from QEMU > > Question: Is the scope here purely between a host and its guest? Or > is it intended that one could access the guest daemon from other > hosts/guests? Just host and guest is the intended scope. Regards, Anthony Liguori