Xen devel - Nov 2012 - [PATCH] Support user domain create extensions

This patch supports arbitrary extensions to xl create by being able to specify
a script which is run at domain creation. The script is specified in the xl
config file and will be started at domain creation with following parameters:

<script> restore|create <domid> <path of config file>

To be able to use non-standard devices a new device class "NSTD" is
defined.
The xl framework will remove all NSTD devices when destroying a domain.

This extension enables us (Fujitsu) to use standard Xen with xl for our
Xen-based mainframe with BS2000 as DomU (this requires an additional Xen
PV-device emulating the BS2000 I/O-system).

It might be interesting for others as well to be able to add new experimental
devices or other features to Xen without having to change Xen (especially xl)
itself.

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>


7 files changed, 65 insertions(+)
tools/examples/xl.conf               |   11 +++++++++++
tools/libxl/libxl.h                  |    3 +++
tools/libxl/libxl_dom.c              |   16 ++++++++++++++++
tools/libxl/libxl_types_internal.idl |    1 +
tools/libxl/xl.c                     |    5 +++++
tools/libxl/xl.h                     |    1 +
tools/libxl/xl_cmdimpl.c             |   28 ++++++++++++++++++++++++++++




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

Juergen Gross writes ("[Xen-devel] [PATCH] Support user domain create
extensions"):
> This patch supports arbitrary extensions to xl create by being able
> to specify a script which is run at domain creation. The script is
> specified in the xl config file and will be started at domain
> creation with following parameters:
> 
> <script> restore|create <domid> <path of config file>
Thanks.  I think this is a reasonable idea.
I wonder if this might be profitably moved down into libxl.

Also the interface needs work.  At the very least there needs to be a
corresponding "destroy" script invocation.
> To be able to use non-standard devices a new device class "NSTD"
is defined.
> The xl framework will remove all NSTD devices when destroying a domain.
Did I miss the implementation of this ?
> +const char *libxl_userdata_path(libxl_ctx *ctx, uint32_t domid,
> +                                const char *userdata_userid,
> +                                const char *wh)
I don''t think this is correct.  We shouldn''t be exposing the
userdata
path like this.  But anyway if we are moving this into libxl then the
config file won''t be exposed to the script anyway.

What does your script need the config file for ?  Writing a separate
parser for it is clearly a mistake...

Ian.

Am 16.11.2012 16:48, schrieb Ian Jackson:
> Juergen Gross writes ("[Xen-devel] [PATCH] Support user domain create
extensions"):
>> This patch supports arbitrary extensions to xl create by being able
>> to specify a script which is run at domain creation. The script is
>> specified in the xl config file and will be started at domain
>> creation with following parameters:
>>
>> <script>  restore|create<domid>  <path of config
file>
>
> Thanks.  I think this is a reasonable idea.
> I wonder if this might be profitably moved down into libxl.
Okay, I''ll try it.
>
> Also the interface needs work.  At the very least there needs to be a
> corresponding "destroy" script invocation.
Sounds reasonable.
>
>> To be able to use non-standard devices a new device class
"NSTD" is defined.
>> The xl framework will remove all NSTD devices when destroying a domain.
>
> Did I miss the implementation of this ?
I haven''t tested it myself. I thought libxl will cycle through all
known
device classes in the xenstore modifying the backend state of the devices
connected to the domain. This should do the job. Have I missed something?
>
>> +const char *libxl_userdata_path(libxl_ctx *ctx, uint32_t domid,
>> +                                const char *userdata_userid,
>> +                                const char *wh)
>
> I don''t think this is correct.  We shouldn''t be exposing
the userdata
> path like this.  But anyway if we are moving this into libxl then the
> config file won''t be exposed to the script anyway.
>
> What does your script need the config file for ?  Writing a separate
> parser for it is clearly a mistake...
We want to be able to:
- specify parameters for our NSTD device per domain
- make sure a domain with a NSTD device is started in the correct cpupool
   (license restriction)

So we need a way to access domain configuration parameters. There are
some other ways to do this, using the config file was the most simple one.
I could think of following alternatives:

- add a new xl subcommand to get a configuration parameter of a domain, e.g.
   xl domain-par <domain> <parameter>

- specify parameters of interest in the xl config file. Those parameters will
   be made available to the script via shell variables. Something like:
   domain_create_script_pars="cpupool nstd_device"
   leading to shell variables XLPAR_cpupool and XLPAR_nstd_device to be set to
   the correct values when invoking the script.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html