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

[Andrew Beekhof]

On 10/21/2010 06:25 PM, Anthony Liguori wrote:
> 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.

I think the scope is also different.
Our focus is on satisfying concrete needs rather than nebulous 
all-encompassing goals.

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

Neither are we really.

I came to Matahari came from clustering (I wrote Pacemaker), so service 
management is my original area of interest.

But for the sake of argument, assume inventory was our sole focus.
There is, by design, a place in the architecture for third-party agents.

Just because the agent wasn't built from matahari.git doesn't mean it 
can't make use of "our" bus.

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

Reboot was one of the first things we implemented :-)

> 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

Honestly, we're interested in whatever the teams that want to work with 
us are interested in.  Our primary mission is to consolidate common 
functionality and avoid N implementations of essentially the same thing.

And I suspect that many people would be interested in having what you're 
working on exposed remotely.


So if you'd like to do this agent as part of Matahari, great.
But if you want to keep it separate and just want to leverage the 
design, that also not a problem.

Or if the core functionality was in a library, we'd happily write the 
glue to make it accessible via QMF and dbus.

There's really a number of levels on which we could work together - if 
you're interested.