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

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.