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

[Jim Fehlig <jfehlig@xxxxxxxx>]

Ian Campbell wrote:
> On Wed, 2013-05-01 at 04:42 +0100, Jim Fehlig wrote:
>   
>> 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 intended usage model is the other way around, we expect normal users
> to just ask for a specific device model version and for them not to care
> about the specific path to the device model binary.
>   

That doesn't seem right to me.  In a few years time who will care about
"qemu-traditional" at all?  Seems more useful for me to be able to say
use '/usr/bin/qemu-system-i386', '/usr/bin/qemu-system-arm',
'/usr/lib/xen/bin/qemu-dm', '/usr/local/bin/qemu-add-my-args', etc.  And
if I don't specify an emulator, then pick a sane default.

> Most users won't even do that and will just want to accept the default
> device model version. Only users with preexisting VMs which are reliant
> on the older device model for some reason (e.g. Windows "Genuine
> Advantage" or whatever it is called) or, historically, people who wanted
> to try out the new device model before it became the default would
> normally want to specify the device model version at all.
>   
> Only advanced users should want to override the actual path to use a
> specific device model binary. The _override suffix on
> device_model_override is intended to imply "advanced use, you better
> know what you are doing", and that includes knowing which version it is
> (since there is no obvious way to detect, other than the sorts of
> heuristics you are discussing here).
>
> This is probably best documented in the xl.cfg(5) manpage rather than in
> anything libxl-ish (sorry):
>
>         =item B<device_model_version="DEVICE-MODEL">
>         
>         Selects which variant of the device-model should be used for this
>         guest. Valid values are:
>         
>         ... the obvious list ...
>         
>         =back
>         
>         It is recommended to accept the default value for new guests.  If
>         you have existing guests then, depending on the nature of the guest
>         Operating System, you may wish to force them to use the device
>         model which they were installed with.
>         
>         ...
>         
>         =item B<device_model_override="PATH">
>         
>         Override the path to the binary to be used as the device-model. The
>         binary provided here MUST be consistent with the
>         `device_model_version` which you have specified. You should not
>         normally need to specify this option.
>
>   
>>> 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"
>>     
>
> xl will ignore this and print a warning,
>         fprintf(stderr,
>                 "WARNING: ignoring device_model directive.\n"
>                 "WARNING: Use \"device_model_override\" instead if you"
>                 " really want a non-default device_model\n");
> This is because we think the majority of users should not need to care
> about the path to the device model binary.
>
>   
>> Are users expected to add
>>
>> device_model_version="qemu-traditional"
>>     
>
> Not unless they care about the particular device model they are using.
>
> I would suggest that libvirt+libxl expose the version as the "emulator"
> option and not the path.

That doesn't fit well with the <emulator> documentation

|emulator|
||
||The contents of the |emulator| element specify the fully qualified
path to the device model emulator binary.  The capabilities XML
specifies the recommended default emulator to use for each particular
domain type / architecture combination.

Regards,
Jim


>  Just leave the path as the default in the
> normal case. You may also want to provide an extra
> emulator-path-override tag/attribute/XML for advanced users, but that's
> up to you.
>
> If you need to support upgrade from xend then you could perhaps treat
> <emulator> values not in the set of valid LIBXL_DEVICE_MODEL_VERSION
> string (currently "qemu-xen" and "qemu-xen-traditional") as a path to a
> qemu-xen-traditional device model -- no xend user can possibly have been
> using the new device model with xend. Or you could take the approach
> that xl does and just warn.
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
>
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel