Re: [Qemu-devel] Re: libvirt vs. in-qemu management

[Jamie Lokier]

Daniel P. Berrange wrote:
> The different formats are serving different needs really. People use the
> libvirt XML format because they want a representation that works across
> multiple hypervisors.

Then my use-case is being missed.

I tried using the libvirt XML format because I want to use the nice
virt-manager GUI to remote-control and view my qemu/kvm-based VMs.

Unfortunately I found it insufficiently expressive for my guests (I
needed particular steps to hand-hold old OS installs, for example),
not to mention the documentation was only online at the time and I wasn't.

Also the user-friendly image making tool lacked almost all the options
I needed to use.  (Think of things like -win2k-hack, clock=vm, and
having to use specific version of kvm, or sometimes even disabling
kernel-kvm due to incompatibilities).

It's fine that I didn't use the libvirt config format - it wasn't
intended for my needs and that's ok.

The big lost opportunity was having to throw out the baby, towels,
nappies and all, with the bathwater: I couldn't use virt-manager's
useful facilities like the GUI, remote management,
instantiation/stopping/starting/migration when I needed to, and
resource monitoring (balloon etc.)

So I had to write some annoyingly hairy scripts and still have only a
half-baked solution.

Obvious solution here is for libvirt to be able to manage a VM but have
the *option* to get out of the way when it comes to configuring and/or
scripting that VM.  Or get out of the way for part of it.

That would make libvirt and it's tools *much* more useful imho.

> are far too low level for their needs.  They higher up the stack you go the
> less likely people are to want to use the low level config format directly.

But what about people who want to use the high level tools for the
*management* aspect, but their guests or use scenarios need low level
config and control?

Users aren't exclusively one or the other.

> This is a false analogy. csh & bash are two different implenetations at the
> same level in the stack.  Compare libX11 against libgtk if you want a more
> sensible comparison. libgtk provides 99% of the features you need. In rare
> cases where it doesn't, you can get access to libX11 APIs directly, but that
> doesn't imply that everyone using GTK needs to know X11.  Your argument
> against libvirt is akin to saying that since GTK can't ever support 100% of
> the X11 functionality, people shouldn't use GTK and apps should work against
> X11 directly.

When I had a go with libvirt/virt-manager, it wasn't missing just 1%
of the functionality.  Quite a lot wasn't available (qemu options
needed for particular guests, scriptable control during installs), or
worked in an unsuitable way (the networking didn't fit my needs
either, but I think that's more unusual).

-- Jamie