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
