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

[Michael Roth <mdroth@linux.vnet.ibm.com>]

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

QEMU-specific is probably a better word, in the sense that the API (and 
the code dependencies) terminates at the QEMU level. Though I think one 
can make the argument that shutdown/reboot are hypervisor-related, 
especially given that there are situations where we currently cannot 
induce a guest reboot from qemu. Also, file access is actually horrible 
use case for RPC. It does however provide a pretty powerful primitive 
for exposing data/statistics made available in /proc or /sys, which do 
extend a hypervisor's ability to make better decisions about things like 
memory ballooning.

But those are just some examples of the functionality that could be 
implemented by the agent, and the RPCs that make sense to implement are 
TBD based on input here and elsewhere.

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

To some extent. But what is gained here though except the bus? If we 
aren't using the functions provided by the common agents we still need 
to re-implement them, and if we do use them then we are dependent on 
their implementations as well as their deployment overhead. And even if 
we do choose to ignore the existing agents, we inherit the guest and 
host-side dependencies of Matahari nonetheless. Maybe these dependencies 
are fairly minimal, but it makes it that much more difficult to support 
other/older guests.

Beyond deployment, there's also just the basic end-user experience we 
need to consider. In the context of general systems management it makes 
total sense that you'd install Matahari and then whatever agents you 
needed in your guests/hosts. In the context of qemu it doesn't. VMWare 
has a vmware package that interacts with vmware, virtualbox has a 
virtualbox utilities package that interacts with virtualbox. 
Simple/intuitive and what users are used to. But qemu has an agent that 
communicates with matahari that qemu talks to? And do we make it clear 
that they need to go back to the host and install matahari?

The single dependency with the agent proposed here is xmlrpc-c, and that 
can be removed with a bit of work.

I agree there's a lot of overlap, and it looks like Matahari is a 
completely reasonable architecture for the functionality it implements, 
but it still seems like more buy-in/overhead than what is necessary for 
the simple qemu guest agent we're looking to implement. And it doesn't 
seem like, in the context of this guest agent, that we stand to gain 
much in doing so.

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

Purely between a host and it's guest. If other hosts/guests needed to 
access it it would need to be via the qemu interfaces or libvirt wrappers.

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