From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call minutes for Oct 19 Date: Thu, 21 Oct 2010 08:32:04 -0500 Message-ID: <4CC040D4.1050204@codemonkey.ws> References: <20101019151441.GA24673@x200.localdomain> <4DE00079-05FA-40DF-9EA5-9573AD745117@suse.de> <4CBEDD97.4010502@redhat.com> <4CC01456.50909@redhat.com> <4CC03B98.9070709@codemonkey.ws> <20101021131815.GJ27578@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Beekhof , Chris Wright , Ted Ross , kvm@vger.kernel.org, arroy@redhat.com, dlaor@redhat.com, Alexander Graf , qemu-devel@nongnu.org, "Perry N. Myers" , Michael D Roth To: "Daniel P. Berrange" Return-path: Received: from mail-qy0-f181.google.com ([209.85.216.181]:37955 "EHLO mail-qy0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757016Ab0JUNcG (ORCPT ); Thu, 21 Oct 2010 09:32:06 -0400 Received: by qyk9 with SMTP id 9so2480344qyk.19 for ; Thu, 21 Oct 2010 06:32:05 -0700 (PDT) In-Reply-To: <20101021131815.GJ27578@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10/21/2010 08:18 AM, Daniel P. Berrange wrote: > On Thu, Oct 21, 2010 at 08:09:44AM -0500, Anthony Liguori wrote: > >> Hi Andrew, >> >> On 10/21/2010 05:22 AM, Andrew Beekhof wrote: >> >>> Hello from the Matahari tech-lead... >>> Is there any documentation on the capabilities provided guest agent >>> Anthony is creating? Perhaps we can combine efforts. >>> >> Mike should be posting today or tomorrow. >> >> >>> Also happy to provide more information on Matahari if anyone is >>> interested. >>> >> I'd really like to hear more about Matahari's long term vision. >> >> For a QEMU guest agent, we need something that is very portable. The >> interfaces it provides need to be reasonably guest agnostic and we need >> to support a wide range of guests including Windows, Linux, *BSD, etc. >> >> From the little bit I've read about Matahari, it seems to be pretty >> specific and pretty oriented towards Fedora-like distributions. 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 >