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

[Jamie Lokier <jamie@shareable.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