6:01 a.m.
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.
Signed-off-by: David Scott <dave.scott(a)eu.citrix.com>
---
src/libxl/libxl_conf.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 7e0753a..2aa5a62 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -788,6 +788,46 @@ libxlMakeCapabilities(libxl_ctx *ctx)
}
int
+libxlMakeEmulator(virDomainDefPtr def, libxl_domain_config *d_config)
+{
+ /* No explicit override means use the default */
+ if (!def->emulator) {
+ return 0;
+ }
+
+ if (!virFileExists(def->emulator)) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("emulator '%s' not found"),
+ def->emulator);
+ return -1;
+ }
+
+ VIR_FREE(d_config->b_info.device_model);
+ if ((d_config->b_info.device_model = strdup(def->emulator)) == NULL) {
+ virReportOOMError();
+ return -1;
+ }
+
+ /* N.B. from xen/tools/libxl/libxl_types.idl:
+ * "If setting device_model you must set device_model_version too."
+ *
+ * The xen-4.3 and later default is "upstream qemu" (QEMU_XEN)
+ * so we make that the default and special-case the old-style
+ * "traditional qemu" (QEMU_XEN_TRADITIONAL)
+ */
+
+ d_config->b_info.device_model_version =
+ LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
+
+ if (STREQ(basename(def->emulator), "qemu-dm"))
+ d_config->b_info.device_model_version =
+ LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+
+ return 0;
+}
+
+
+int
libxlBuildDomainConfig(libxlDriverPrivatePtr driver,
virDomainDefPtr def, libxl_domain_config *d_config)
{
@@ -811,6 +851,10 @@ libxlBuildDomainConfig(libxlDriverPrivatePtr driver,
goto error;
}
+ if (libxlMakeEmulator(def, d_config) < 0) {
+ goto error;
+ }
+
d_config->on_reboot = def->onReboot;
d_config->on_poweroff = def->onPoweroff;
d_config->on_crash = def->onCrash;
--
1.7.1
10:10 a.m.
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?
Regards,
Jim
Signed-off-by: David Scott <dave.scott(a)eu.citrix.com>
---
src/libxl/libxl_conf.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 7e0753a..2aa5a62 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -788,6 +788,46 @@ libxlMakeCapabilities(libxl_ctx *ctx)
}
int
+libxlMakeEmulator(virDomainDefPtr def, libxl_domain_config *d_config)
+{
+ /* No explicit override means use the default */
+ if (!def->emulator) {
+ return 0;
+ }
+
+ if (!virFileExists(def->emulator)) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("emulator '%s' not found"),
+ def->emulator);
+ return -1;
+ }
+
+ VIR_FREE(d_config->b_info.device_model);
+ if ((d_config->b_info.device_model = strdup(def->emulator)) == NULL) {
+ virReportOOMError();
+ return -1;
+ }
+
+ /* N.B. from xen/tools/libxl/libxl_types.idl:
+ * "If setting device_model you must set device_model_version too."
+ *
+ * The xen-4.3 and later default is "upstream qemu" (QEMU_XEN)
+ * so we make that the default and special-case the old-style
+ * "traditional qemu" (QEMU_XEN_TRADITIONAL)
+ */
+
+ d_config->b_info.device_model_version =
+ LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
+
+ if (STREQ(basename(def->emulator), "qemu-dm"))
+ d_config->b_info.device_model_version =
+ LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+
+ return 0;
+}
+
+
+int
libxlBuildDomainConfig(libxlDriverPrivatePtr driver,
virDomainDefPtr def, libxl_domain_config *d_config)
{
@@ -811,6 +851,10 @@ libxlBuildDomainConfig(libxlDriverPrivatePtr driver,
goto error;
}
+ if (libxlMakeEmulator(def, d_config) < 0) {
+ goto error;
+ }
+
d_config->on_reboot = def->onReboot;
d_config->on_poweroff = def->onPoweroff;
d_config->on_crash = def->onCrash;
2:51 p.m.
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
10:42 p.m.
New subject: [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.
Regards,
Jim
2:59 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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 :|
3:46 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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.
8:44 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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
9:11 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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 :|
3:11 p.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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
12:53 p.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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
3:25 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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.
5:46 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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
5:55 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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.
6:14 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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
6:50 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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.
10:34 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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
9:31 a.m.
New subject: [libvirt] [Xen-devel] [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(a)lists.xen.org
http://lists.xen.org/xen-devel
9:52 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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
10:40 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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(a)lists.xen.org
http://lists.xen.org/xen-devel
10:47 a.m.
New subject: [libvirt] [Xen-devel] [PATCH] libxl: allow an <emulator> to be selected in the domain config XML
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.
4006
days inactive
4037
days old
19 comments
5 participants
participants (5)
-
Daniel P. Berrange -
David Scott -
Ian Campbell -
Jim Fehlig -
Marek Marczykowski