Re: [PATCH] Support user domain create extensions

[Juergen Gross <juergen.gross@ts.fujitsu.com>]

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