From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuYJN-00031K-Lf for qemu-devel@nongnu.org; Wed, 24 Mar 2010 17:40:25 -0400 Received: from [140.186.70.92] (port=35906 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuYJM-00031C-A9 for qemu-devel@nongnu.org; Wed, 24 Mar 2010 17:40:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuYJK-0007NR-Gt for qemu-devel@nongnu.org; Wed, 24 Mar 2010 17:40:24 -0400 Received: from qw-out-1920.google.com ([74.125.92.144]:14188) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuYJK-0007NN-Dp for qemu-devel@nongnu.org; Wed, 24 Mar 2010 17:40:22 -0400 Received: by qw-out-1920.google.com with SMTP id 5so1118723qwf.4 for ; Wed, 24 Mar 2010 14:40:21 -0700 (PDT) Message-ID: <4BAA86C2.4020701@codemonkey.ws> Date: Wed, 24 Mar 2010 16:40:18 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt References: <4BA7C40C.2040505@codemonkey.ws> <20100323145105.GV16253@redhat.com> <4BA8D8A9.7090308@codemonkey.ws> <201003231557.19474.paul@codesourcery.com> <4BA8E6FC.9080207@codemonkey.ws> <4BA901B5.3020704@redhat.com> <4BA9A066.3070904@redhat.com> <20100324103643.GB624@redhat.com> <4BA9EC88.6000906@redhat.com> <20100324134250.38822113@redhat.com> <4BAA6CD9.6060001@redhat.com> <20100324171219.4365318b@redhat.com> <4BAA76EA.2060601@codemonkey.ws> <20100324182501.000b69a7@redhat.com> In-Reply-To: <20100324182501.000b69a7@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org, Avi Kivity On 03/24/2010 04:25 PM, Luiz Capitulino wrote: > > I see it as a related problem, because what seems to be under discussion > is the quality of our interfaces with humans and tools. > > Also, when we were discussing the usuability problems I remember that > you > > *WARNING: I might be wrong here, please correct me if so* > > you said that you don't push users to libvirt because it's out of sync with > our features. Yes. > The point is that, even if this true and even if we solve that, > I don't think it will solve the problem of a good experience for a > 'single VM user', because libvirt is more than that and people will likely > be annoyed as much as they are today. > > I believe this problem is up to us to solve. > With my qemu hat on, I'm happy to ignore libvirt and say we need to own our interfaces and to compete with libvirt for users. But with my Linux virtualization hat on, I want to see a single management interface that users can use without having to make a choice between libvirt features or libqemu features. >>> Then we make virt-manager optional and this is good because we can sync >>> features way faster and we don't have to care about _managing_ several >>> VMs, our world in terms of usability and maintainability is about one VM. >>> >>> IMVHO, everything else should be done by third-party tools like libvirt, >>> we just provide the means for it. >>> >>> >> We need to have a common management interface for third party tools. >> > QMP? :-) Only if QMP is compatible with libvirt. I don't want a user to have to choose between QMP and libvirt. >> So far, a libqemu.so with a flexible transport that could be used >> directly by a libvirt user (ala cairo/gdk type interactions) seems like >> the best solution to me. >> > I tend to disagree. > > First, I think we should invest our time and effort on the text protocol > business, which is QMP. Having yet another public interface will likely split > efforts a bit and will make clients' life harder (which one should I choose? > What if they get out of sync?). Not to mention that I think Paul has a point, > if QMP is not useful here, why do we have it in the first place (vs. a C library > from the beginning)? > > You mentioned dynamic dispatch, but this is useful only for C clients right? > If so, what C clients you expected beyond libvirt? Users want a C API. I don't agree that libvirt is the only C interface consumer out there. > Note that libvirt has added > a new events API recently. > > The second most important point for me is: why do you believe that > libqemu.so is going to improve things? Do you expect that libvirt will > sync faster? With GDK and Cairo, when Cairo adds a new feature, GDK doesn't have to do anything to support it. Users just get a cairo context from GDK and use the cairo API directly. GDK provides a higher level interface for 2d operations that is more platform agnostic, and users can choice to use that or write directly to the cairo API. > If this is the case, I think it will be as slower as it's > currently, as the problem is not the availability of interfaces, but > most likely community integration. > > I like the idea of having a transient qemu-specific API in libvirt, > as suggested by someone in this thread. > I really think what we want is for a libvirt user to be able to call libqemu functions directly. There shouldn't have to be libvirt specific functions for every operation we expose. Regards, Anthony Liguori