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

Daniel Veillard wrote: > On Sun, Apr 11, 2010 at 11:17:38PM +0100, Jamie Lokier wrote: > >> It's not that hard to write this for trivial extra options: >> >> <emulator>/bin/sh -c 'qemu "$0" "$@" -extra-flag'</emulator> >> >> (if that works). >> > That won't work because we expect the emulator to be a path to > the emulator program, so yes that has to be done in the wrapper script. > Ok. Being able to pass arguments would be about infinitely more useful, so that you don't need a separate wrapper script for every individual guest configuration - you can pass options to the single wrapper for each variation. Even<emulator>/path/to/wrapper qemu-0.11</emulator> is a big improvement over<emulator>/path/to/wrapper-guest-config-6-with-qemu-0.11</emulator> ;-) Some simple but versatile hook ideas: -<emulator-append-option> (no space splitting, one option, appended) -<emulator-append-options> (space splitting multiple options) -<emulator-prepend-option> -<emulator-prepend-options> -<emulator-setenv name="NAME">VALUE</emulator-setenv>

-<emulator-wrap>/path/to/script</emulator-wrap> This last one is to call the script, but pass all the options including the path to whichever version of qemu/kvm would get selected by libvirt. (I presume it has some selection mechanism, given the variety of guests which break with each version of qemu and/or qemu-kvm and/or kvm?) (It is most unfortunate that XML forces those long prefixes everywhere due to lack of contextual naming, unlike less verbose config formats :-/) >> Parsing libvirt output and having to guess which option corresponds to >> what from the libvirt config sounds very fragile and also a rather >> large amount of effort for something which should be easy. >> > it's not that easy because we change the way we build the command line > for qemu as qemu evolves. for example before and after the support for > -device there have been a lot of changes. > I agree, which is why it's much less fragile if libvirt provides the individual parts to hooks/wrappers, if that's asked, rather than forcing the wrapper to parse libvirts output and guess what libvirt does from version to version. For sure, before and after -device, any script which is involved with those options will probably have to change. But that's quite unusual. Most usually I'd expect things like the order of -device options might change depending on how libvirt pulled together it's backing resources, for example. -- Jamie