From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6NpW-00059Q-Qp for qemu-devel@nongnu.org; Mon, 26 Apr 2010 08:54:30 -0400 Received: from [140.186.70.92] (port=50019 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6NpU-00058l-8P for qemu-devel@nongnu.org; Mon, 26 Apr 2010 08:54:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6NpS-00005s-4Y for qemu-devel@nongnu.org; Mon, 26 Apr 2010 08:54:28 -0400 Received: from mail2.shareable.org ([80.68.89.115]:37952) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6NpR-00005k-SD for qemu-devel@nongnu.org; Mon, 26 Apr 2010 08:54:26 -0400 Date: Mon, 26 Apr 2010 13:54:24 +0100 From: Jamie Lokier Subject: Re: [libvirt] [Qemu-devel] Re: Libvirt debug API Message-ID: <20100426125424.GC16976@shareable.org> References: <4BBF2E93.3020508@redhat.com> <20100409142717.GA11875@redhat.com> <20100412122013.58894a64@redhat.com> <4BD09A3B.3090001@codemonkey.ws> <4BD1971B.7060907@redhat.com> <4BD1A543.1050004@codemonkey.ws> <4BD1ADA2.2050605@redhat.com> <20100423143656.GG17700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100423143656.GG17700@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Libvirt , Jiri Denemark , Avi Kivity , qemu-devel@nongnu.org Daniel P. Berrange wrote: > > Much better to exact a commitment from libvirt to track all QMP (and > > command line) capabilities. Instead of adding cleverness to QMP, add > > APIs to libvirt. > > Agreed. Despite adding this monitor / XML passthrough capability, we still > do not want apps to be using this at all. If there is some capability > missing that apps need then the default mode of operation is to add the > neccessary bits of libvirt. The monitor/XML pasthrough is just a short > term quick workaround until the official support is done. As such I do > not really think we need to put huge amounts of effort in the wierd > complex racey edge cases. The effort is better spent on getting the > features in libvirt. All the features? The qemu API is quite large already (look at all the command line options and monitor commands). I'll be very surprised if libvirt provides all of it that obscure apps may use. I'm thinking of features which are relatively obscure but nonetheless useful to a small number of deployments. Probably not enough to justify the effort building data models, specifying the XML and remote protocol and so on in libvirt. (Unless that becomes so easily mapped to qemu's API that it's almost an automatic thing... Which sounds like QMP, doesn't it?) Is libvirt ever likely to go to the effort of providing all the easily-usable API, or hooks, for: - sending keys to a guest, driven by a timed host script? - rebooting the guest while switching between USB touchpad and mouse devices, because one of them is needed during an OS install and the other is needed after? - changing the amount of RAM available to the guest at the next reboot, for OS install needing more memory than run time, in a scripted fashion when building new VMs from install disk images? - switching the guest between qemu mode and kvm mode on the next guest reset, because qemu is faster for some things (VGA updates) and kvm is faster for other things, so the best choice depends on which app you need to run on that guest - pausing a VM, making a copy, and resuming it, so as to fork it into two VMs (literally fork)? - setting up the host network container and NAT IP forwarding, on demand as guests are stopped and started, so that it works in the above scenario despite clashing IP addresses? - running a copy of the same guest, or perhaps an entire OS install process (scripted), many times for different qemu and qemu-kvm versions, different BIOSes, and different almost-equivalent hardware emulations (i.e. different NIC types, SMP count, CPU features, disk controller type, AIO/cache type) - for testing guests and apps on them - with some paralellism? None of those, except perhaps the first, as what I think of as typical virtualisation workloads, and they all seem obscure things probably outside libvirt's remit. Probably not many users either :-) Yet you can do them all today with qemu and scripting the monitor, and it's getting easier with QMP. Which is fine, qemu works, but it would be great to be able to see those guests and interact in the basic ways through the libvirt-based GUIs? QMP pass-through or QMP multiple monitors seems to provide most of that, although I can see libvirt getting a bit confused about which devices and how much RAM the guest has installed at different times. The bit about forking guests, I'm not sure how complicated it is to tie in to libvirt's notion of which disk images are being used, and hooking into it's network configuration to handle the clashing addresses. If those things are considered to be entirely outside libvirt's remit, that's fine with me. Fair enough: I will continue to live with ssh and vinagre. I'm just raising my hand as a potential user who might like to monitor a bunch of active and inactive guests, remotely, see how much memory they report using, etc. launch VNC viewer from the GUI, even choose the target host based on load and migrate on demand, while also needing a fair bit of non-standardness and qemu-level scripting too. Imho, that probably comes under the heading of apps using pass-through or multiple QMP monitors, which use features that probably won't and probably shouldn't ever be handled by libvirt itself. -- Jamie