Re: [libvirt] [Qemu-devel] Re: Libvirt debug API

Daniel P. Berrange 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. 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