[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
  • Date: Tue, 20 Nov 2012 07:53:33 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 20 Nov 2012 06:54:06 +0000
  • Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nKLhmCKjLW2np/K1+GzoTg1Z8tVZ5XWRYFjw9I4DRKivQsnI/h36e2p6 0VgorF/iiA6orpTSLRCO0Spa3xZVcMP1LVjHhK4xW0RPb5LhCLsH3md5x M8K1a62iMBHy2zo28/b+J9Dm6Os3R5MfuscFrPkuMsc2f6d3/Fb6JkMQp b+wt11yHE8Ybe3cu1p33BgcD8RC7KHh1vjMnsLFHtnPROzD3Ejm/6DtHi 6/hT9upVekbVVdgB0hoOi+f5m24VW;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.