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

[Anthony Liguori <anthony@codemonkey.ws>]

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-prepend-option>
>     -<emulator-prepend-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.

Regards,

Anthony Liguori

>     -<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
>
>
>