qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrew Beekhof
Subject: [Qemu-devel] Re: [RFC][PATCH 00/10] virtagent: host/guest RPC communication agent
Date: Tue, 26 Oct 2010 09:14:47 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Thunderbird/3.1.4

On 10/25/2010 07:06 PM, Michael Roth 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 ;-)


QEMU-specific is probably a better word, in the sense that the API (and
the code dependencies) terminates at the QEMU level.

The concepts though apply to all flavours of virtualization and even bare-metal machines.

Implementation details aside, they're the first functions any agent/collection of agents is going to implement - which is why I'm having a hard time with the *-specific labels.

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?

I guess I was thinking that if you have the bus, why not make use of the existing standardised agents and focus the QEMU one on the parts that weren't already provided.

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.

Matahari is purely guest side, the Host is currently a standard qpid server. For usage on a single single host its possible we may drop that as a hard requirement and support dbus as the host-side aggregator.

On the guest side, each agent may well end up being its own subpackage.
So the dependency list would depend on what functionality the user wanted (plus qpid of course).


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.

That's kinda the point, everyone is reinventing the wheel here.
And not just virt projects, off the top of my head there are a couple for clustering; one for SAP, Puppet, MRG; the FMCI team is working on a bunch...

We're working with all those groups (and others) to try and get some consolidation. Mostly the reaction so far has been positive but if you want to do your own thing, I can live with that.

What would be nice though is if the guest-side functions that implement the RPC calls lived in a library. That way, like we do with netcf and libvirt, we could write glue for plugging the QEMU-specific ones into Matahari.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]