Re: [Qemu-devel] Re: libvirt vs. in-qemu management
Alexander Graf wrote: > > One way to avoid it is to have a rich plugin API so if some needs some > > to, say, set up traffic control on the interface, they can write a > > plugin to do that. > > Another way would be to have an active open source community that just > writes the support for traffic control upstream if they need it. I > actually prefer that to a plugin API. Not every local config quirk should go upstream, and if someone has to edit the C source just to configure their tap interface a bit differently, that's not a good sign. Qemu already has a passable API for this in the form of thw network-up and network-down scripts. Imho much more ability to hook into many parts of device setup that way would be good. You don't need a rich internal API then. Even better if callout scripts are allowed to connect back to QMP and tell Qemu what to do during machine setup and interesting events. -- Jamie
Re: [Qemu-devel] Re: libvirt vs. in-qemu management
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
Re: [Qemu-devel] Re: libvirt vs. in-qemu management
Alexander Graf wrote: > So what if you had a special section that gives you the necessary > information to do that mapping? A vendor specific section so to say. > That would make it a perfect master config format, right? XML with XML Namespaces is quite good for mixing data intended for different applications. In some ways it's better than a .ini style file with an extra section, because you can easily associate the extra data wherever - for example in this case putting management disk info close to the qemu configuration for the guest disk. Then again there's something to be said for explicitly naming things like "disk 1" etc. and referring to extra data out of line - making the linkages more explicit. I wonder, if libvirt's configs were in YAML or something like samba's ini style, instead of XML, and if the guest machine config part was expressive enough to accomodate all of qemu's device attributes, would that work as a happy medium? That sounds not unlike machine configs already discussed, except being a bit more explicit to make the syntax human friendly and to accomodate libivirt/other management config on an equal footing with guest machine config. -- Jamie
Re: [Qemu-devel] Re: libvirt vs. in-qemu management
On Tue, Apr 06, 2010 at 02:43:47PM +0200, Alexander Graf wrote: > Does VMware Player support OVF? > Does VMware Workstation support OVF? > Does VMware Server support OVF? Yes, but "OVF" is a rather loose term here. OVF isn't too well standardized. But ... > Does it make sense to build an OVF with a Xen PV image? This hits on the fundamental problem. What your guest might require could be different from what the hypervisor could provide. Your guest could require Xen paravirtualization, or even just an obscure network card which the hypervisor cannot supply. It's a bit easier if you are building pre-packaged appliances (these have multiple other problems such as their size, and how they get updated). V2V conversion of random guests from another hypervisor to KVM is a very hard problem, something that we're working on with virt-v2v. We certainly don't go via OVF, and we do lots of tinkering inside the guest (eg. installing new kernels). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
