From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NzF4R-00071y-06 for qemu-devel@nongnu.org; Tue, 06 Apr 2010 16:08:23 -0400 Received: from [140.186.70.92] (port=58624 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NzF4O-00071d-Qt for qemu-devel@nongnu.org; Tue, 06 Apr 2010 16:08:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NzF4M-0008JB-On for qemu-devel@nongnu.org; Tue, 06 Apr 2010 16:08:20 -0400 Received: from mail2.shareable.org ([80.68.89.115]:51652) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NzF4M-0008J4-IK for qemu-devel@nongnu.org; Tue, 06 Apr 2010 16:08:18 -0400 Date: Tue, 6 Apr 2010 21:08:15 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: libvirt vs. in-qemu management Message-ID: <20100406200815.GB4510@shareable.org> References: <4BBA60CC.5050008@redhat.com> <20100406110616.GK28689@redhat.com> <4BBB2DD3.3090405@suse.de> <20100406130055.GN28689@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100406130055.GN28689@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel Developers , Anthony Liguori , Alexander Graf , Avi Kivity Daniel P. Berrange wrote: > The different formats are serving different needs really. People use the > libvirt XML format because they want a representation that works across > multiple hypervisors. Then my use-case is being missed. I tried using the libvirt XML format because I want to use the nice virt-manager GUI to remote-control and view my qemu/kvm-based VMs. Unfortunately I found it insufficiently expressive for my guests (I needed particular steps to hand-hold old OS installs, for example), not to mention the documentation was only online at the time and I wasn't. Also the user-friendly image making tool lacked almost all the options I needed to use. (Think of things like -win2k-hack, clock=vm, and having to use specific version of kvm, or sometimes even disabling kernel-kvm due to incompatibilities). It's fine that I didn't use the libvirt config format - it wasn't intended for my needs and that's ok. The big lost opportunity was having to throw out the baby, towels, nappies and all, with the bathwater: I couldn't use virt-manager's useful facilities like the GUI, remote management, instantiation/stopping/starting/migration when I needed to, and resource monitoring (balloon etc.) So I had to write some annoyingly hairy scripts and still have only a half-baked solution. Obvious solution here is for libvirt to be able to manage a VM but have the *option* to get out of the way when it comes to configuring and/or scripting that VM. Or get out of the way for part of it. That would make libvirt and it's tools *much* more useful imho. > are far too low level for their needs. They higher up the stack you go the > less likely people are to want to use the low level config format directly. But what about people who want to use the high level tools for the *management* aspect, but their guests or use scenarios need low level config and control? Users aren't exclusively one or the other. > This is a false analogy. csh & bash are two different implenetations at the > same level in the stack. Compare libX11 against libgtk if you want a more > sensible comparison. libgtk provides 99% of the features you need. In rare > cases where it doesn't, you can get access to libX11 APIs directly, but that > doesn't imply that everyone using GTK needs to know X11. Your argument > against libvirt is akin to saying that since GTK can't ever support 100% of > the X11 functionality, people shouldn't use GTK and apps should work against > X11 directly. When I had a go with libvirt/virt-manager, it wasn't missing just 1% of the functionality. Quite a lot wasn't available (qemu options needed for particular guests, scriptable control during installs), or worked in an unsuitable way (the networking didn't fit my needs either, but I think that's more unusual). -- Jamie