From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6PHw-0006sx-Ku for qemu-devel@nongnu.org; Mon, 26 Apr 2010 10:27:56 -0400 Received: from [140.186.70.92] (port=50910 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6PHv-0006sK-7i for qemu-devel@nongnu.org; Mon, 26 Apr 2010 10:27:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6PHs-0001gc-NK for qemu-devel@nongnu.org; Mon, 26 Apr 2010 10:27:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6220) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6PHs-0001fz-Fs for qemu-devel@nongnu.org; Mon, 26 Apr 2010 10:27:52 -0400 Message-ID: <4BD5A26A.90003@redhat.com> Date: Mon, 26 Apr 2010 10:25:46 -0400 From: Chris Lalancette MIME-Version: 1.0 Subject: Re: [libvirt] [Qemu-devel] Re: Libvirt debug API 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> <20100426125424.GC16976@shareable.org> In-Reply-To: <20100426125424.GC16976@shareable.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Libvirt , Jiri Denemark , Avi Kivity , qemu-devel@nongnu.org On 04/26/2010 08:54 AM, Jamie Lokier wrote: > 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. In point of fact, you can also do some of them today more-or-less with libvirt and some scripting. However, you are right, there are probably obscure features that libvirt will *never* be able to entirely implement, either because they don't fit into libvirt's world-view or because they are too obscure or difficult to do. However, Dan's point stands; for most features that most users want to use, it is far better to spend effort creating a cross-hypervisor, long-term API than to spend too much effort on individual hypervisor hacks. > 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. Right, and you are probably one of the users this work targets. But in general, for those not very familiar with virtualization/qemu, we want to steer them far clear of this API. That goes doubly true for application developers; we want them to be able to use a stable, long-term API and not have to worry about the nitty-gritty details of the monitor. It's that latter group that we want to make sure doesn't use this API. -- Chris Lalancette