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

[Chris Lalancette <clalance@redhat.com>]

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