[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
- From: Jim Fehlig <jfehlig suse com>
- To: Ian Campbell <Ian Campbell citrix com>
- Cc: "libvir-list redhat com" <libvir-list redhat com>, xen-devel <xen-devel lists xen org>
- Subject: Re: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
- Date: Wed, 01 May 2013 08:31:32 -0600
Ian Campbell wrote:
> On Wed, 2013-05-01 at 04:42 +0100, Jim Fehlig wrote:
>> David Scott wrote:
>>> [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.
That doesn't seem right to me. In a few years time who will care about
"qemu-traditional" at all? Seems more useful for me to be able to say
use '/usr/bin/qemu-system-i386', '/usr/bin/qemu-system-arm',
'/usr/lib/xen/bin/qemu-dm', '/usr/local/bin/qemu-add-my-args', etc. And
if I don't specify an emulator, then pick a sane default.
> 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 ...
> 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
> xl will ignore this and print a warning,
> "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
> 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.
That doesn't fit well with the <emulator> documentation
||The contents of the |emulator| element specify the fully qualified
path to the device model emulator binary. The capabilities XML
specifies the recommended default emulator to use for each particular
domain type / architecture combination.
> 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.
> Xen-devel mailing list
> Xen-devel lists xen org
[Date Prev][Date Next] [Thread Prev][Thread Next]