Re: [Qemu-devel] KVM call minutes for Oct 19

[Anthony Liguori <anthony@codemonkey.ws>]

Hi Andrew,

On 10/21/2010 10:43 AM, Andrew Beekhof wrote:
> In that case we've done a bad job of the wiki.
> Windows and other distributions are a key part of the Matahari vision.
>
> Matahari is two things
> - an architecture, and
> - an implementation of the most common API sets
>
> Each set of APIs (ie. host, network, services) is an independent 
> daemon/agent which attaches to a common QMF broker (more on that later).
>
> While some of these might be platform specific, packaging would be one 
> likely candidate, the intention is to be agnostic distro/platform 
> wherever possible.
>
> Take netcf for example, instead of re-inventing the wheel we wrote the 
> windows port for netcf.
>
>
> So what's this about QMF you ask?
> Again, rather than invent our own message protocol we're leveraging an 
> existing standard that supports windows and linux, is fast, reliable 
> and secure.
>
> Its also pluggable and discoverable - so simply starting a new agent 
> that connects to the matahari broker makes it's API available.  Any 
> QMF client/console can also interrogate the guest to see what agents 
> and API calls are available.
>
> Even better there's going to be a virtio-serial transport.  So we can 
> access the same agents in the same way with or without host-to-guest 
> networking.  This was a key requirement for us because of EC2-like 
> cloud scenarios where we don't have access to the physical host.

I did get this much and I think I'm doing a poor job explaining myself.

I think Matahari is tackling the same space that many other frameworks 
are.  For instance, everything you say above is (supposed to be) true 
for something like OpenWBEM, Pegasus, etc.

The advantage I see in Matahari is that 1) it can take advantage of 
virtio-serial 2) it's significantly lighter than CIM 3) it's community 
driven.

So there's no doubt in my mind that if you need a way to inventory 
physical and virtual systems, something like Matahari becomes a very 
appealing option to do that.

But that's not the problem space I'm trying to tackle.

An example of the problem I'm trying to tackle is guest reboot.

On x86, there is no ACPI interface for requesting a guest reboot.  Other 
platforms do provide this and we usually try to emulate platform 
interfaces whenever possible.  In order to implement host-initiated 
reboot (aka virDomainReboot) we need to have a mechanism to execute the 
reboot command in the guest that's initiated by the hypervisor.

This is not the same thing as a remote system's management interface.  
This is something that should be dead-simple and trivially portable.

I think there's symbiotic relationship that a QEMU-based guest agent 
could play with a Matahari based agent.  But my initial impression is 
that the types of problems we're trying to tackle are fundamentally 
different than the problem that Matahari is even if it superficially 
appears like there's an overlap.

For instance, communication window locations to enable "coherence" mode 
in the QEMU GUI is something that makes no sense as a network management 
interface.  This is something that only makes sense between QEMU and the 
guest agent.

Regards,

Anthony Liguori

>
> Thats probably enough for the moment, I'd better go make dinner :-)
>
>
>>>> It
>>>> exposes interfaces for manipulation of RPM packages, relies on netcf,
>>>> etc.
>>> FYI netcf is not Fedora specific. There is a Win32 backend for it
>>> too. It does need porting to other Linux distros, but that's simply
>>> an internal implementation issue. The goal of netcf is to be the
>>> libvirt of network config mgmt - a portable API for all OS network
>>> config tasks. Further, Matahari itself is also being ported to Win32
>>> and can be ported to other Linux distros too.
>>
>> Yeah, I'm aware of the goals of netcf but that hasn't materialized a
>> port to other distros.
>>
>> Let me be clear, I don't think this is a problem for libvirt,
>> NetworkManager, or even Matahari.
>>
>> But for a QEMU guest agent where we terminate the APIs within QEMU
>> itself, I do think it creates a pretty nasty portability barrier.
>>
>>>> There's nothing wrong with this if the goal of Matahari is to 
>>>> provide a
>>>> robust agent for Fedora-based Linux distributions but I don't think it
>>>> meets the requirements of a QEMU guest agent.
>>>>
>>>> I don't think we can overly optimize for one Linux distribution either
>>>> so a mentality of letting other platforms contribute their own support
>>>> probably won't work.
>>> That is not the goal of Matahari. It is intended to be generically
>>> applicable to *all* guest OS. Obviously in areas where every distro
>>> does different things, then it will need porting for each different
>>> impl. You have to start somewhere and it started with Fedora. This
>>> is all is true of any guest agent solution.
>>
>> There's two approaches that could be taken for a guest agent. You could
>> provide very low level interfaces (read a file, execute a command, read
>> a registry key). This makes for a very portable guest agent at the cost
>> of complexity in interacting with the agent. The agent doesn't ever
>> really need to change much the client (QEMU) needs to handle many
>> different types of guests, and add new functionality based on the
>> supported primitives.
>>
>> Another approach is to put the complexity in the agent and simplify the
>> management interface. For system's management applications, this is
>> probably the right approach. For virtualization, I think this is a bad
>> approach.
>>
>> Very specifically, netcf only really needs to read and write
>> configuration files and potentially run a command. Instead of linking
>> against netcf in the guest, we should link against netcf in QEMU so that
>> we don't have to constantly change the guest agent.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>
>>> Regards,
>>> Daniel
>>
>>
>