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. <snip> > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list