[libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
Jim Fehlig
jfehlig at suse.com
Wed May 1 15:40:06 UTC 2013
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 at lists.xen.org
> http://lists.xen.org/xen-devel
>
>
More information about the libvir-list
mailing list