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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
