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