From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nu10L-0003xA-B5 for qemu-devel@nongnu.org; Tue, 23 Mar 2010 06:06:33 -0400 Received: from [199.232.76.173] (port=59473 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nu10J-0003wk-AW for qemu-devel@nongnu.org; Tue, 23 Mar 2010 06:06:31 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nu10H-00040e-LP for qemu-devel@nongnu.org; Tue, 23 Mar 2010 06:06:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8358) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nu10H-00040S-7k for qemu-devel@nongnu.org; Tue, 23 Mar 2010 06:06:29 -0400 From: Juan Quintela In-Reply-To: <4BA7C40C.2040505@codemonkey.ws> (Anthony Liguori's message of "Mon, 22 Mar 2010 14:25:00 -0500") References: <4BA7C40C.2040505@codemonkey.ws> Date: Tue, 23 Mar 2010 11:06:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "libvir-list@redhat.com" , qemu-devel Anthony Liguori wrote: > Hi, > > I've mentioned this to a few folks already but I wanted to start a > proper thread. > > We're struggling in qemu with usability and one area that concerns me > is the disparity in features that are supported by qemu vs what's > implemented in libvirt. > > This isn't necessarily libvirt's problem if it's mission is to provide > a common hypervisor API that covers the most commonly used features. > > However, for qemu, we need an API that covers all of our features that > people can develop against. The ultimate question we need to figure > out is, should we encourage our users to always use libvirt or should > we build our own API for people (and libvirt) to consume. > > I don't think it's necessarily a big technical challenge for libvirt > to support qemu more completely. I think it amounts to introducing a > series of virQemuXXXX APIs that implement qemu specific functions. > Over time, qemu specific APIs can be deprecated in favour of more > generic virDomain APIs. > > What's the feeling about this from the libvirt side of things? Is > there interest in support hypervisor specific interfaces should we be > looking to provide our own management interface for libvirt to > consume? My problems with libvirt are: - I can't "hack" the qemu command line. It would be great to be able to edit the command line that libvirt is about to launch (yes, this is useful for developers, but it is an easy hack). - monitor: I need a way to get to the monitor when going through libvirt, in the past you couldn't allow this, but now it looks possible. - changing the emulator: It is normal for me to be using several qemu binaries for testing, changing it with libvirt is just a mess. Now, why I want to use libvirt in the 1st place? - libvirt is good at remembering details like mac addresses, disks positions, etc. Compare virsh start foo versus a 300+ character long qemu command line. - virt-viewer: I want to be able to switch consoles, period. - networking: man, setting networking is a mess, libvirt just does it for you. Now, to do suggestions. What would make it for me: - being able to use the qemu command line -> maximum flexibility - if that is too complicated for any reason, being able to change the ... would be good enough the mayority of the time. What I normally need is: use a different emulator or add some additional flag to qemu. Just my 2 cents Juan.