From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50428 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAdwg-0002OL-HN for qemu-devel@nongnu.org; Tue, 26 Oct 2010 03:27:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PAdwa-0003kK-QT for qemu-devel@nongnu.org; Tue, 26 Oct 2010 03:27:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PAdwa-0003k6-ID for qemu-devel@nongnu.org; Tue, 26 Oct 2010 03:27:40 -0400 Message-ID: <4CC682E7.6010904@redhat.com> Date: Tue, 26 Oct 2010 09:27:35 +0200 From: Andrew Beekhof 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> <4CC5F683.5080907@codemonkey.ws> In-Reply-To: <4CC5F683.5080907@codemonkey.ws> 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: Anthony Liguori Cc: Perry Myers , ryanh@us.ibm.com, agl@linux.vnet.ibm.com, Michael Roth , qemu-devel@nongnu.org On 10/25/2010 11:28 PM, Anthony Liguori wrote: > 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. Could you expand on that? > >>> 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. Well there are ways to link C programs against a C++ library. But I agree that they're not ideal. > > 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. Oh it absolutely makes sense once you have more than a single host. And even more so if you're in an environment where you don't have access to the physical host(s) at all, such as in the cloud. > 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