Re: [Qemu-devel] Re: [RFC][PATCH 00/10] virtagent: host/guest RPC communication agent

[Anthony Liguori <anthony@codemonkey.ws>]

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