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

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Tue, Apr 30, 2013 at 09:42:59PM -0600, Jim Fehlig wrote:
> David Scott wrote:
> > Hi,
> >
> > [added xen-devel: FYI this is about how to properly set the libxl
> > device_model_version when the user has provided a manual device_model
> > override (aka a path to a qemu) in the libvirt domain XML.]
> >
> > On 30/04/13 16:10, Jim Fehlig wrote:
> >> David Scott wrote:
> >>> The emulator path supplied can be any valid path on the system.
> >>>
> >>> Note that when setting a device_model, libxl needs us to set the
> >>> device_model_version too. The device_model_version can be either
> >>>
> >>>    ...QEMU_XEN: meaning "upstream qemu", the default in xen-4.3 onwards
> >>>    ...QEMU_XEN_TRADITIONAL: the old xen-specific fork
> >>>
> >>> We detect the device_model_version by examining the qemu filename:
> >>> if it is "qemu-dm" then it's the old xen-specific fork. If anything
> >>> else then we assume "upstream qemu" (whose filename may change
> >>> in future). Note that if you are using a wrapper script to (eg)
> >>> adjust the arguments of the old qemu during development, you will
> >>> have to ensure the wrapper script also has the name "qemu-dm", by
> >>> placing it in a separate directory.
> >>>
> >>
> >> That is unfortunate.  Users could have existing config with
> >> <emulator>/usr/bin/my-qemu-dm</emulator> which works with the legacy
> >> stack but not with libxl right?  Is it possible to safely query the
> >> binary to determine if it is qemu-dm?
> >
> > From my reading of libxl, it doesn't seem to have any way to detect
> > the type of a given qemu binary (or at least I couldn't spot it). I
> > think that if we were to write some detection code we should probably
> > add it to libxl rather than libvirt -- what do you think?
> 
> I tend to agree.  Why should apps have to specify device_model_version? 
> I think it is sufficient to say here's an emulator, please use it.
> 
> > The other options I can think of are:
> >
> > 1. weaken the test so we interpret any filename containing the
> > substring "qemu-dm" as traditional-- this would catch your case at least
> 
> Right, it would probably catch a lot of cases.  But users are free to
> have names with no 'qemu-dm' component.
> 
> >
> > 2. flip the default around so that if an <emulator> is provided we
> > assume traditional unless the filename is "qemu-system-i386" (or maybe
> > just "contains qemu-system-i386" or "contains qemu-system")
> 
> How is this handled in xl?  There is certainly a lot of xm config out
> there with
> 
> device_model="/usr/lib/xen/bin/qemu-dm"
> 
> Are users expected to add
> 
> device_model_version="qemu-traditional"
> 
> when migrating to xl/libxl?  I suppose xl handles this (should just look
> at the code), but it seems an implementation detail that shouldn't be
> exposed to 3rd party apps.

Sigh, is there really no way for Xen to figure this out automatically,
or for QEMU itself to tell Xen what type of device model it is. Pushing
it onto the user is a really horrible design decision IMHO.

> > 3. add libxl driver-specific XML (is that possible?) to allow the user
> > to override a libvirt default. It would be a shame to expose the
> > complexity to the libvirt client though.
> 
> There is such functionality for qemu, but I would prefer to avoid it for
> this case, particularly since it works in the legacy xen driver.

The QEMU scenario is different to this too. QEMU has the optional to allow
arbitrary command line args to be passed through, but this is declared to
be feature without any formal support. The intent is that everything be
modelled in the generic XML if it is to be supported. If this device model
version  is something that is mandatory to make it work, then it is not
viable to consider a xen specific XML extension for it.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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