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

[Marek Marczykowski]

On 31.05.2013 12:55, Ian Campbell wrote:
> On Fri, 2013-05-31 at 12:46 +0200, Marek Marczykowski wrote:
>> On 31.05.2013 10:25, Ian Campbell wrote:
>>> On Thu, 2013-05-30 at 11:53 -0600, Jim Fehlig wrote:
>>>> 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.
>>>
>>> The default is handled in libxl, so you don't need to do anything if you
>>> don't want to. It's up to you if you want to provide an override
>>> facility in libvirt. Personally I'd do it with a specific XML
>>> property/key/whatever rather than magic emulator paths...
>>
>> Optional attribute for <emulator> tag? Maybe sth like:
>> <emulator type="stubdom">/usr/lib/xen/boot/ioemu-stubdom.gz</emulator>
>> ?
> 
> FWIW the path can be omitted and libxl will DTRT.

Indeed. It looks like libxl even doesn't allow custom stubdom path - always
uses hardcoded default. libxl_dm.c:
    stubdom_state->pv_kernel.path
        = libxl__abs_path(gc, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path());
    stubdom_state->pv_cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
    stubdom_state->pv_ramdisk.path = "";


IMO it is much more useful to specify device model type (qemu upstream, qemu
traditional, qemu traditional in stubdom) than explicit qemu path, but libvirt
config syntax currently allow only the later one.

-- 
Best Regards,
Marek Marczykowski
Invisible Things Lab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130531/786411e7/attachment-0001.sig>