[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On 04/12/2010 07:23 AM, Jamie Lokier wrote:
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-setenv name="NAME">VALUE</emulator-setenv>

I'd strongly suggest not focusing on manipulating command line arguments. I think in the not too distant future, few people will pass command line arguments as opposed to just using configuration files.

We are very close to being able to cover 90% of current users via the config file.


Anthony Liguori

         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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]