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

[Jim Fehlig <jfehlig@xxxxxxxx>]

Marek Marczykowski wrote:
> On 01.05.2013 16:11, Daniel P. Berrange wrote:
>   
>> On Wed, May 01, 2013 at 02:44:11PM +0100, David Scott wrote:
>>     
>>> On 01/05/13 09:46, Ian Campbell wrote:
>>>       
>>>> I would suggest that libvirt+libxl expose the version as the "emulator"
>>>> option and not the path. 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.
>>>>         
>>> This would work for me: it doesn't seem too bad to consider
>>> "qemu-xen" and "qemu-xen-traditional" as special virtual paths. It's
>>> a useful observation that xend never supported the new device model.
>>> Jim: should I cook up patch v3? :-)
>>>       
>> No, that really doesn't fly. The <emlator> element must always point
>> to a qualfied binary path.
>>
>> IMHO, libvirt should just default to the new QEMU binary and if people
>> want to use the old one, they can configure the emulator path for it.
>>     
>
> What about stubdom? Any idea how to do it better than special paths? Even if
> given path will point to stubdom binary, I don't know how libvirt shoud
> distinguish it from standalone qemu and set b_info->device_model_stubdomain
> accordingly.
>   

As mentioned in my reply to your stubdom patch, this should be handled
in libxl IMO.

https://www.redhat.com/archives/libvir-list/2013-May/msg01994.html

Regards,
Jim


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