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. Ian. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list