From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single project Date: Mon, 22 Mar 2010 14:33:45 -0500 Message-ID: <4BA7C619.7080104@codemonkey.ws> References: <4BA76810.4040609@redhat.com> <20100322143212.GE14201@elte.hu> <4BA7821C.7090900@codemonkey.ws> <20100322155505.GA18796@elte.hu> <4BA796DF.7090005@redhat.com> <20100322165107.GD18796@elte.hu> <4BA7A406.9050203@redhat.com> <20100322173400.GB15795@elte.hu> <4BA7AF2D.7060306@redhat.com> <4BA7C1D7.5070208@codemonkey.ws> <20100322193100.GB28709@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Ingo Molnar , Pekka Enberg , "Zhang, Yanmin" , Peter Zijlstra , Sheng Yang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Marcelo Tosatti , oerg Roedel , Jes Sorensen , Gleb Natapov , Zachary Amsden , ziteng.huang@intel.com, Arnaldo Carvalho de Melo , Fr?d?ric Weisbecker , Gregory Haskins To: "Daniel P. Berrange" Return-path: Received: from mail-pw0-f46.google.com ([209.85.160.46]:59725 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755116Ab0CVTdt (ORCPT ); Mon, 22 Mar 2010 15:33:49 -0400 In-Reply-To: <20100322193100.GB28709@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/22/2010 02:31 PM, Daniel P. Berrange wrote: > On Mon, Mar 22, 2010 at 02:15:35PM -0500, Anthony Liguori wrote: > >> On 03/22/2010 12:55 PM, Avi Kivity wrote: >> >>>> Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by >>>> Anthony. >>>> There's numerous ways that this can break: >>>> >>> I don't like it either. We have libvirt for enumerating guests. >>> >> We're stuck in a rut with libvirt and I think a lot of the >> dissatisfaction with qemu is rooted in that. It's not libvirt that's >> the probably, but the relationship between qemu and libvirt. >> >> We add a feature to qemu and maybe after six month it gets exposed by >> libvirt. Release time lines of the two projects complicate the >> situation further. People that write GUIs are limited by libvirt >> because that's what they're told to use and when they need something >> simple, they're presented with first getting that feature implemented in >> qemu, then plumbed through libvirt. >> > That is somewhat unfair as a blanket statement! > Sorry, you're certainly correct. Some features appear quickly, but others can take an awfully long time. >> It wouldn't be so bad if libvirt was basically a passthrough interface >> to qemu but it tries to model everything in a generic way which is more >> or less doomed to fail when you're adding lots of new features (as we are). >> >> The list of things that libvirt doesn't support and won't any time soon >> is staggering. >> > As previously discussed, we want to improve both the set of features > supported, and make it much easier to support new features promptly. > The QMP& qdev stuff has been a very good step forward in making it > easier to support QEMU management. There have been a proposals from > several people, yourself included, on how to improve libvirt's support > for the full range of QEMU features. We're committed to looking at this > and figuring out which proposals are practical to support, so we can > improve QEMU& libvirt interaction for everyone. > Regards, Anthony Liguori > Regards, > Daniel >