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

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.

> 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.