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

[Jamie Lokier <jamie@shareable.org>]

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