Xen devel - Apr 2013 - Re: [PATCH] libxl: allow an <emulator> to be selected in the domain config XML

Hi,

[added xen-devel: FYI this is about how to properly set the libxl 
device_model_version when the user has provided a manual device_model 
override (aka a path to a qemu) in the libvirt domain XML.]

On 30/04/13 16:10, Jim Fehlig wrote:
> David Scott wrote:
>> The emulator path supplied can be any valid path on the system.
>>
>> Note that when setting a device_model, libxl needs us to set the
>> device_model_version too. The device_model_version can be either
>>
>>    ...QEMU_XEN: meaning "upstream qemu", the default in
xen-4.3 onwards
>>    ...QEMU_XEN_TRADITIONAL: the old xen-specific fork
>>
>> We detect the device_model_version by examining the qemu filename:
>> if it is "qemu-dm" then it''s the old xen-specific
fork. If anything
>> else then we assume "upstream qemu" (whose filename may
change
>> in future). Note that if you are using a wrapper script to (eg)
>> adjust the arguments of the old qemu during development, you will
>> have to ensure the wrapper script also has the name
"qemu-dm", by
>> placing it in a separate directory.
>>
>
> That is unfortunate.  Users could have existing config with
> <emulator>/usr/bin/my-qemu-dm</emulator> which works with the
legacy
> stack but not with libxl right?  Is it possible to safely query the
> binary to determine if it is qemu-dm?
 From my reading of libxl, it doesn''t seem to have any way to detect
the
type of a given qemu binary (or at least I couldn''t spot it). I think 
that if we were to write some detection code we should probably add it 
to libxl rather than libvirt -- what do you think?

The other options I can think of are:

1. weaken the test so we interpret any filename containing the substring 
"qemu-dm" as traditional-- this would catch your case at least

2. flip the default around so that if an <emulator> is provided we 
assume traditional unless the filename is "qemu-system-i386" (or maybe
just "contains qemu-system-i386" or "contains qemu-system")

3. add libxl driver-specific XML (is that possible?) to allow the user 
to override a libvirt default. It would be a shame to expose the 
complexity to the libvirt client though.

What do you think?

Cheers,
Dave