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

["Daniel P. Berrange" <berrange@redhat.com>]

On Sun, Apr 11, 2010 at 11:17:38PM +0100, Jamie Lokier wrote:
> Richard W.M. Jones wrote:
> > On Fri, Apr 09, 2010 at 10:06:51PM +0100, Jamie Lokier wrote:
> > > Daniel P. Berrange wrote:
> > > > I think this alteration of existing args is faaaar too complex & fragile,
> > > > and way overkill.
> > > 
> > > Would it not be simpler, for the target audience, for the config to
> > > contain a one-line shell script to transform particular matched
> > > arguments in any way that's wanted?
> > 
> > I might be missing something but I thought you could already do this
> > in current libvirt.  ie. Change the <emulator> element [1] to point to
> > your shell script:
> > 
> >   <emulator>/usr/local/bin/my-qemu-wrapper.sh</emulator>
> > 
> > The wrapper should get called with the command line arguments and you
> > can alter them however you like.
> > 
> > Isn't that right, Dan?
> 
> That forces the shell script to be relatively complicated and
> recognise all qemu arguments (including version specific ones) to skip
> the ones with parameters - and to know where to look for the real
> target executable is.
> 
> It's not a very friendly way to add or change parts of specific
> subsystems, for example modifying a blockdev parameter, but it can be
> done that way if necessary.
> 
> It's not that hard to write this for trivial extra options:
> 
>    <emulator>/bin/sh -c 'qemu "$0" "$@" -extra-flag'</emulator>
> 
> (if that works).
> 
> But for things like modifications to particular devices, wouldn't it
> be better to associate "add cache=special option" to a section about
> one of the blockdevs which libvirt knows about, rather than the awful
> prospect of parsing libvirt's output to guess which of three -device
> arguments corresponds with the second SCSI drive mentioned in the
> libvirt config - which might not necessarily be the second on the
> command line, even.

Every device has a unique  alias in the XML, which maps onto the 'id='
parameter for QEMU so you can match up them. We need to consider the
tradeoff between what's likely to be neccessary vs cost of supporting
the extensions. Allowing addition of arbitrary extra command lines is
a trivial extension with low support cost & covers the most pressing
feature timelag problems. Munging existing dev options is a less common 
scenario with significantly higher support burden which I don't really
consider worth explicitly supporting beyond the existing ability to add
a wrapper script.

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|