On Wed, 2013-05-01 at 15:31 +0100, Jim Fehlig wrote: > 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? People who installed Windows with it and are therefore stuck with it for the lifetime of the VM. We expect it to eventually go away but not as quickly as you might expect, for this reason. > 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. This is still all advanced usage, the majority of users should specify neither the version nor the path, libxl will just do the right thing for them. If the libvirt bindings is trying to insert a path in the "pick a sane default" case then it should stop trying to do this and just let libxl DTRT. BTW "qemu-add-my-args" can be achieved via the libxl API which has a field for extra arguments to pass the device model. [...] > > 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 That's a shame. > |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. Ian -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list