qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [RFC][PATCH 00/10] virtagent: host/guest RPC communication agent
Date: Mon, 25 Oct 2010 16:28:35 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8

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



reply via email to

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