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 15:31 +0100, Jim Fehlig wrote:
>   
>> 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?
>>     
>
> People who installed Windows with it and are therefore stuck with it for
> the lifetime of the VM. We expect it to eventually go away but not as
> quickly as you might expect, for this reason.
>   

These people should use <emulator>/usr/lib/xen/bin/qemu-dm</emulator> IMO.

>   
>>   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.
>>     
>
> This is still all advanced usage, the majority of users should specify
> neither the version nor the path, libxl will just do the right thing for
> them. If the libvirt bindings is trying to insert a path in the "pick a
> sane default" case then it should stop trying to do this and just let
> libxl DTRT.
>   

Yes, I agree.  But if a user specifies <emulator>/bla/bla</emulator>,
how should libvirt populate device_model_version?  Is it expected that
qemu-xen-traditional will always be the 0.10.2 version?  If so, libxl
could DTRT by setting device_model_version to qemu-xen-traditional when
detecting the the requested emulator version in 0.10.2.

> BTW "qemu-add-my-args" can be achieved via the libxl API which has a
> field for extra arguments to pass the device model.
>   

Good to know, thanks.

Regards,
Jim

> [...]
>   
>>> 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
>>     
>
> That's a shame.
>
>   
>> |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.
>>     
>
> 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