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

[Andrew Beekhof <abeekhof@redhat.com>]

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