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