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

David Scott wrote:
> 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?
I tend to agree.  Why should apps have to specify device_model_version? 
I think it is sufficient to say here''s an emulator, please use it.
> 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
Right, it would probably catch a lot of cases.  But users are free to
have names with no ''qemu-dm'' component.
>
> 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")
How is this handled in xl?  There is certainly a lot of xm config out
there with

device_model="/usr/lib/xen/bin/qemu-dm"

Are users expected to add

device_model_version="qemu-traditional"

when migrating to xl/libxl?  I suppose xl handles this (should just look
at the code), but it seems an implementation detail that shouldn''t be
exposed to 3rd party apps.
> 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.
There is such functionality for qemu, but I would prefer to avoid it for
this case, particularly since it works in the legacy xen driver.

Regards,
Jim