qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] KVM call minutes for Oct 19
Date: Thu, 21 Oct 2010 11:25:50 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8

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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]