Jim Fehlig
2013-May-01 14:31 UTC
Re: [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
Ian Campbell wrote:> 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. >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 ... > > =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.That doesn''t fit well with the <emulator> documentation |emulator| || ||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. Regards, Jim> 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. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > >