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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.



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