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

[Andrew Beekhof]

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 ;-)

> 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.

> 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?

> 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?

> 2) a server in the host (integrated into the Virtproxy host daemon, which we 
> plan to integrate directly into qemu) to handle RPC requests sent by the guest 
> agent (mainly for handling asynchronous events reported by the agent).
>
> At the Virtagent level, communication is done via standard RPCs (HTTP/TCP 
> between host and guest). Virtproxy transparently handles transport over a 
> network or isa/virtio serial channel, allowing the agent to be deployed on 
> older guests which may not support virtio-serial.