Re: [Xen-devel] [PATCH] Support user domain create extensions

[Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

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