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

[Andrew Beekhof]

On 10/25/2010 11:28 PM, Anthony Liguori 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 ;-)
>
> A hypervisor initiated shutdown is very different than a network
> initiated shutdown.

Could you expand on that?

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

Well there are ways to link C programs against a C++ library.
But I agree that they're not ideal.

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

Oh it absolutely makes sense once you have more than a single host.
And even more so if you're in an environment where you don't have access 
to the physical host(s) at all, such as in the cloud.

> 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