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

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

[David Scott]

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?

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

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")

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.

What do you think?

Cheers,
Dave

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

[Jim Fehlig]

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.

Regards,
Jim

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

[Daniel P. Berrange]

On Tue, Apr 30, 2013 at 09:42:59PM -0600, 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 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.

Sigh, is there really no way for Xen to figure this out automatically,
or for QEMU itself to tell Xen what type of device model it is. Pushing
it onto the user is a really horrible design decision IMHO.

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

The QEMU scenario is different to this too. QEMU has the optional to allow
arbitrary command line args to be passed through, but this is declared to
be feature without any formal support. The intent is that everything be
modelled in the generic XML if it is to be supported. If this device model
version  is something that is mandatory to make it work, then it is not
viable to consider a xen specific XML extension for it.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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

[Ian Campbell]

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.

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

[David Scott]

On 01/05/13 09:46, Ian Campbell wrote:
> 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.

This would work for me: it doesn't seem too bad to consider "qemu-xen" 
and "qemu-xen-traditional" as special virtual paths. It's a useful 
observation that xend never supported the new device model. Jim: should 
I cook up patch v3? :-)

Slightly tangentially, do you anticipate the list of valid 
LIBXL_DEVICE_MODEL_VERSIONs expanding in future? For example, will it be 
used to differentiate between different major versions of qemu?

Cheers,
Dave

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

[Daniel P. Berrange]

On Wed, May 01, 2013 at 02:44:11PM +0100, David Scott wrote:
> On 01/05/13 09:46, Ian Campbell wrote:
> >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.
> 
> This would work for me: it doesn't seem too bad to consider
> "qemu-xen" and "qemu-xen-traditional" as special virtual paths. It's
> a useful observation that xend never supported the new device model.
> Jim: should I cook up patch v3? :-)

No, that really doesn't fly. The <emlator> element must always point
to a qualfied binary path.

IMHO, libvirt should just default to the new QEMU binary and if people
want to use the old one, they can configure the emulator path for it.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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

[Marek Marczykowski]

[-- Attachment #1.1: Type: text/plain, Size: 1690 bytes --]

On 01.05.2013 16:11, Daniel P. Berrange wrote:
> On Wed, May 01, 2013 at 02:44:11PM +0100, David Scott wrote:
>> On 01/05/13 09:46, Ian Campbell wrote:
>>> 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.
>>
>> This would work for me: it doesn't seem too bad to consider
>> "qemu-xen" and "qemu-xen-traditional" as special virtual paths. It's
>> a useful observation that xend never supported the new device model.
>> Jim: should I cook up patch v3? :-)
> 
> No, that really doesn't fly. The <emlator> element must always point
> to a qualfied binary path.
> 
> IMHO, libvirt should just default to the new QEMU binary and if people
> want to use the old one, they can configure the emulator path for it.

What about stubdom? Any idea how to do it better than special paths? Even if
given path will point to stubdom binary, I don't know how libvirt shoud
distinguish it from standalone qemu and set b_info->device_model_stubdomain
accordingly.

-- 
Best Regards,
Marek Marczykowski
Invisible Things Lab


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Jim Fehlig]

Marek Marczykowski wrote:
> On 01.05.2013 16:11, Daniel P. Berrange wrote:
>   
>> On Wed, May 01, 2013 at 02:44:11PM +0100, David Scott wrote:
>>     
>>> On 01/05/13 09:46, Ian Campbell wrote:
>>>       
>>>> 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.
>>>>         
>>> This would work for me: it doesn't seem too bad to consider
>>> "qemu-xen" and "qemu-xen-traditional" as special virtual paths. It's
>>> a useful observation that xend never supported the new device model.
>>> Jim: should I cook up patch v3? :-)
>>>       
>> No, that really doesn't fly. The <emlator> element must always point
>> to a qualfied binary path.
>>
>> IMHO, libvirt should just default to the new QEMU binary and if people
>> want to use the old one, they can configure the emulator path for it.
>>     
>
> What about stubdom? Any idea how to do it better than special paths? Even if
> given path will point to stubdom binary, I don't know how libvirt shoud
> distinguish it from standalone qemu and set b_info->device_model_stubdomain
> accordingly.
>   

As mentioned in my reply to your stubdom patch, this should be handled
in libxl IMO.

https://www.redhat.com/archives/libvir-list/2013-May/msg01994.html

Regards,
Jim

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

[Ian Campbell]

On Thu, 2013-05-30 at 11:53 -0600, Jim Fehlig wrote:
> Marek Marczykowski wrote:
> > On 01.05.2013 16:11, Daniel P. Berrange wrote:
> >   
> >> On Wed, May 01, 2013 at 02:44:11PM +0100, David Scott wrote:
> >>     
> >>> On 01/05/13 09:46, Ian Campbell wrote:
> >>>       
> >>>> 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.
> >>>>         
> >>> This would work for me: it doesn't seem too bad to consider
> >>> "qemu-xen" and "qemu-xen-traditional" as special virtual paths. It's
> >>> a useful observation that xend never supported the new device model.
> >>> Jim: should I cook up patch v3? :-)
> >>>       
> >> No, that really doesn't fly. The <emlator> element must always point
> >> to a qualfied binary path.
> >>
> >> IMHO, libvirt should just default to the new QEMU binary and if people
> >> want to use the old one, they can configure the emulator path for it.
> >>     
> >
> > What about stubdom? Any idea how to do it better than special paths? Even if
> > given path will point to stubdom binary, I don't know how libvirt shoud
> > distinguish it from standalone qemu and set b_info->device_model_stubdomain
> > accordingly.
> >   
> 
> As mentioned in my reply to your stubdom patch, this should be handled
> in libxl IMO.

The default is handled in libxl, so you don't need to do anything if you
don't want to. It's up to you if you want to provide an override
facility in libvirt. Personally I'd do it with a specific XML
property/key/whatever rather than magic emulator paths...

Ian.

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

[Marek Marczykowski]

[-- Attachment #1.1: Type: text/plain, Size: 2488 bytes --]

On 31.05.2013 10:25, Ian Campbell wrote:
> On Thu, 2013-05-30 at 11:53 -0600, Jim Fehlig wrote:
>> Marek Marczykowski wrote:
>>> On 01.05.2013 16:11, Daniel P. Berrange wrote:
>>>   
>>>> On Wed, May 01, 2013 at 02:44:11PM +0100, David Scott wrote:
>>>>     
>>>>> On 01/05/13 09:46, Ian Campbell wrote:
>>>>>       
>>>>>> 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.
>>>>>>         
>>>>> This would work for me: it doesn't seem too bad to consider
>>>>> "qemu-xen" and "qemu-xen-traditional" as special virtual paths. It's
>>>>> a useful observation that xend never supported the new device model.
>>>>> Jim: should I cook up patch v3? :-)
>>>>>       
>>>> No, that really doesn't fly. The <emlator> element must always point
>>>> to a qualfied binary path.
>>>>
>>>> IMHO, libvirt should just default to the new QEMU binary and if people
>>>> want to use the old one, they can configure the emulator path for it.
>>>>     
>>>
>>> What about stubdom? Any idea how to do it better than special paths? Even if
>>> given path will point to stubdom binary, I don't know how libvirt shoud
>>> distinguish it from standalone qemu and set b_info->device_model_stubdomain
>>> accordingly.
>>>   
>>
>> As mentioned in my reply to your stubdom patch, this should be handled
>> in libxl IMO.
> 
> The default is handled in libxl, so you don't need to do anything if you
> don't want to. It's up to you if you want to provide an override
> facility in libvirt. Personally I'd do it with a specific XML
> property/key/whatever rather than magic emulator paths...

Optional attribute for <emulator> tag? Maybe sth like:
<emulator type="stubdom">/usr/lib/xen/boot/ioemu-stubdom.gz</emulator>
?

-- 
Best Regards,
Marek Marczykowski
Invisible Things Lab


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Ian Campbell]

On Fri, 2013-05-31 at 12:46 +0200, Marek Marczykowski wrote:
> On 31.05.2013 10:25, Ian Campbell wrote:
> > On Thu, 2013-05-30 at 11:53 -0600, Jim Fehlig wrote:
> >> Marek Marczykowski wrote:
> >>> On 01.05.2013 16:11, Daniel P. Berrange wrote:
> >>>   
> >>>> On Wed, May 01, 2013 at 02:44:11PM +0100, David Scott wrote:
> >>>>     
> >>>>> On 01/05/13 09:46, Ian Campbell wrote:
> >>>>>       
> >>>>>> 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.
> >>>>>>         
> >>>>> This would work for me: it doesn't seem too bad to consider
> >>>>> "qemu-xen" and "qemu-xen-traditional" as special virtual paths. It's
> >>>>> a useful observation that xend never supported the new device model.
> >>>>> Jim: should I cook up patch v3? :-)
> >>>>>       
> >>>> No, that really doesn't fly. The <emlator> element must always point
> >>>> to a qualfied binary path.
> >>>>
> >>>> IMHO, libvirt should just default to the new QEMU binary and if people
> >>>> want to use the old one, they can configure the emulator path for it.
> >>>>     
> >>>
> >>> What about stubdom? Any idea how to do it better than special paths? Even if
> >>> given path will point to stubdom binary, I don't know how libvirt shoud
> >>> distinguish it from standalone qemu and set b_info->device_model_stubdomain
> >>> accordingly.
> >>>   
> >>
> >> As mentioned in my reply to your stubdom patch, this should be handled
> >> in libxl IMO.
> > 
> > The default is handled in libxl, so you don't need to do anything if you
> > don't want to. It's up to you if you want to provide an override
> > facility in libvirt. Personally I'd do it with a specific XML
> > property/key/whatever rather than magic emulator paths...
> 
> Optional attribute for <emulator> tag? Maybe sth like:
> <emulator type="stubdom">/usr/lib/xen/boot/ioemu-stubdom.gz</emulator>
> ?

FWIW the path can be omitted and libxl will DTRT.

Ian.

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

[Marek Marczykowski]

[-- Attachment #1.1: Type: text/plain, Size: 3320 bytes --]

On 31.05.2013 12:55, Ian Campbell wrote:
> On Fri, 2013-05-31 at 12:46 +0200, Marek Marczykowski wrote:
>> On 31.05.2013 10:25, Ian Campbell wrote:
>>> On Thu, 2013-05-30 at 11:53 -0600, Jim Fehlig wrote:
>>>> Marek Marczykowski wrote:
>>>>> On 01.05.2013 16:11, Daniel P. Berrange wrote:
>>>>>   
>>>>>> On Wed, May 01, 2013 at 02:44:11PM +0100, David Scott wrote:
>>>>>>     
>>>>>>> On 01/05/13 09:46, Ian Campbell wrote:
>>>>>>>       
>>>>>>>> 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.
>>>>>>>>         
>>>>>>> This would work for me: it doesn't seem too bad to consider
>>>>>>> "qemu-xen" and "qemu-xen-traditional" as special virtual paths. It's
>>>>>>> a useful observation that xend never supported the new device model.
>>>>>>> Jim: should I cook up patch v3? :-)
>>>>>>>       
>>>>>> No, that really doesn't fly. The <emlator> element must always point
>>>>>> to a qualfied binary path.
>>>>>>
>>>>>> IMHO, libvirt should just default to the new QEMU binary and if people
>>>>>> want to use the old one, they can configure the emulator path for it.
>>>>>>     
>>>>>
>>>>> What about stubdom? Any idea how to do it better than special paths? Even if
>>>>> given path will point to stubdom binary, I don't know how libvirt shoud
>>>>> distinguish it from standalone qemu and set b_info->device_model_stubdomain
>>>>> accordingly.
>>>>>   
>>>>
>>>> As mentioned in my reply to your stubdom patch, this should be handled
>>>> in libxl IMO.
>>>
>>> The default is handled in libxl, so you don't need to do anything if you
>>> don't want to. It's up to you if you want to provide an override
>>> facility in libvirt. Personally I'd do it with a specific XML
>>> property/key/whatever rather than magic emulator paths...
>>
>> Optional attribute for <emulator> tag? Maybe sth like:
>> <emulator type="stubdom">/usr/lib/xen/boot/ioemu-stubdom.gz</emulator>
>> ?
> 
> FWIW the path can be omitted and libxl will DTRT.

Indeed. It looks like libxl even doesn't allow custom stubdom path - always
uses hardcoded default. libxl_dm.c:
    stubdom_state->pv_kernel.path
        = libxl__abs_path(gc, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path());
    stubdom_state->pv_cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
    stubdom_state->pv_ramdisk.path = "";


IMO it is much more useful to specify device model type (qemu upstream, qemu
traditional, qemu traditional in stubdom) than explicit qemu path, but libvirt
config syntax currently allow only the later one.

-- 
Best Regards,
Marek Marczykowski
Invisible Things Lab


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Ian Campbell]

On Fri, 2013-05-31 at 13:14 +0200, Marek Marczykowski wrote:
> >> Optional attribute for <emulator> tag? Maybe sth like:
> >> <emulator type="stubdom">/usr/lib/xen/boot/ioemu-stubdom.gz</emulator>
> >> ?
> > 
> > FWIW the path can be omitted and libxl will DTRT.
> 
> Indeed. It looks like libxl even doesn't allow custom stubdom path - always
> uses hardcoded default. libxl_dm.c:
>     stubdom_state->pv_kernel.path
>         = libxl__abs_path(gc, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path());
>     stubdom_state->pv_cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
>     stubdom_state->pv_ramdisk.path = "";

So it does. FWIW given libxl allows an override for the process type of
qemu I can't think why we wouldn't allow an override here too.

> IMO it is much more useful to specify device model type (qemu upstream, qemu
> traditional, qemu traditional in stubdom) than explicit qemu path,

I agree. Users should not generally need to care about paths to things.

Ian.

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

[Jim Fehlig]

Marek Marczykowski wrote:
> On 31.05.2013 10:25, Ian Campbell wrote:
>   
>> On Thu, 2013-05-30 at 11:53 -0600, Jim Fehlig wrote:
>>     
>>> Marek Marczykowski wrote:
>>>       
>>>> On 01.05.2013 16:11, Daniel P. Berrange wrote:
>>>>   
>>>>         
>>>>> On Wed, May 01, 2013 at 02:44:11PM +0100, David Scott wrote:
>>>>>     
>>>>>           
>>>>>> On 01/05/13 09:46, Ian Campbell wrote:
>>>>>>       
>>>>>>             
>>>>>>> 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.
>>>>>>>         
>>>>>>>               
>>>>>> This would work for me: it doesn't seem too bad to consider
>>>>>> "qemu-xen" and "qemu-xen-traditional" as special virtual paths. It's
>>>>>> a useful observation that xend never supported the new device model.
>>>>>> Jim: should I cook up patch v3? :-)
>>>>>>       
>>>>>>             
>>>>> No, that really doesn't fly. The <emlator> element must always point
>>>>> to a qualfied binary path.
>>>>>
>>>>> IMHO, libvirt should just default to the new QEMU binary and if people
>>>>> want to use the old one, they can configure the emulator path for it.
>>>>>     
>>>>>           
>>>> What about stubdom? Any idea how to do it better than special paths? Even if
>>>> given path will point to stubdom binary, I don't know how libvirt shoud
>>>> distinguish it from standalone qemu and set b_info->device_model_stubdomain
>>>> accordingly.
>>>>   
>>>>         
>>> As mentioned in my reply to your stubdom patch, this should be handled
>>> in libxl IMO.
>>>       
>> The default is handled in libxl, so you don't need to do anything if you
>> don't want to. It's up to you if you want to provide an override
>> facility in libvirt. Personally I'd do it with a specific XML
>> property/key/whatever rather than magic emulator paths...
>>     
>
> Optional attribute for <emulator> tag? Maybe sth like:
> <emulator type="stubdom">/usr/lib/xen/boot/ioemu-stubdom.gz</emulator>
> ?
>   

That sounds like a reasonable compromise to me.

Regards,
Jim

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

[Jim Fehlig]

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

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

[Ian Campbell]

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

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

[Jim Fehlig]

Ian Campbell wrote:
> 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.
>   

These people should use <emulator>/usr/lib/xen/bin/qemu-dm</emulator> IMO.

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

Yes, I agree.  But if a user specifies <emulator>/bla/bla</emulator>,
how should libvirt populate device_model_version?  Is it expected that
qemu-xen-traditional will always be the 0.10.2 version?  If so, libxl
could DTRT by setting device_model_version to qemu-xen-traditional when
detecting the the requested emulator version in 0.10.2.

> BTW "qemu-add-my-args" can be achieved via the libxl API which has a
> field for extra arguments to pass the device model.
>   

Good to know, thanks.

Regards,
Jim

> [...]
>   
>>> 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
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>   

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

[Ian Campbell]

On Wed, 2013-05-01 at 16:40 +0100, Jim Fehlig wrote:
> > 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.
> >   
> 
> Yes, I agree.  But if a user specifies <emulator>/bla/bla</emulator>,
> how should libvirt populate device_model_version?  Is it expected that
> qemu-xen-traditional will always be the 0.10.2 version?  If so, libxl
> could DTRT by setting device_model_version to qemu-xen-traditional when
> detecting the the requested emulator version in 0.10.2.

qemu-xen-traditional certainly won't be getting any version bumps
(certainly not for the first two numbers, I suppose there is a
vanishingly small chance for the third one), so if that is the version
it reports then that might work.

Ian.