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

On Wed, 2013-05-01 at 04:42 +0100, 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 intended usage model is the other way around, we expect normal users
to just ask for a specific device model version and for them not to care
about the specific path to the device model binary.

Most users won''t even do that and will just want to accept the default
device model version. Only users with preexisting VMs which are reliant
on the older device model for some reason (e.g. Windows "Genuine
Advantage" or whatever it is called) or, historically, people who wanted
to try out the new device model before it became the default would
normally want to specify the device model version at all.

Only advanced users should want to override the actual path to use a
specific device model binary. The _override suffix on
device_model_override is intended to imply "advanced use, you better
know what you are doing", and that includes knowing which version it is
(since there is no obvious way to detect, other than the sorts of
heuristics you are discussing here).

This is probably best documented in the xl.cfg(5) manpage rather than in
anything libxl-ish (sorry):

        =item B<device_model_version="DEVICE-MODEL">
        
        Selects which variant of the device-model should be used for this
        guest. Valid values are:
        
        ... the obvious list ...
        
        =back
        
        It is recommended to accept the default value for new guests.  If
        you have existing guests then, depending on the nature of the guest
        Operating System, you may wish to force them to use the device
        model which they were installed with.
        
        ...
        
        =item B<device_model_override="PATH">
        
        Override the path to the binary to be used as the device-model. The
        binary provided here MUST be consistent with the
        `device_model_version` which you have specified. You should not
        normally need to specify this option.
> > 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"
xl will ignore this and print a warning,
        fprintf(stderr,
                "WARNING: ignoring device_model directive.\n"
                "WARNING: Use \"device_model_override\" instead
if you"
                " really want a non-default device_model\n");
This is because we think the majority of users should not need to care
about the path to the device model binary.
> Are users expected to add
> 
> device_model_version="qemu-traditional"
Not unless they care about the particular device model they are using.

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.

Ian.