Chris wrote:
> Agreed; I do not mean to suggest otherwise.
>
> My point is that if this project and others all implement their own
> management tools and inevitably conflicting means of storing information
> about of sets of domains, then that's not a path to a happy place.
You are absolutely right!
> If you decide that your needs are best served by developing a new set of
> tools, please keep the discussion alive on the list. It's a potentially
> useful capability and I'd like to see how it progresses.
Okay, here is our proposal for the user interface. We plan to do the
implementation work in the next month(s).
Support of cpu-pools
The physical cpus of a server are grouped in cpu-pools. Each physical CPU is
assigned at most to one cpu-pool. Domains are each restricted to a single
cpu-pool. Scheduling does not cross cpu-pool boundaries, so each cpu-pool
has an own scheduler.
The cpu-pool of the domain Dom0 will be pool0, at boot-time we have to create
this cpu-pool implicitly.
The creation of a cpu-pool is similar to the creation of a domain. In a first
step the attributes of a cpu-pool have to be defined, in the second step the
cpu-pool will be activated (started) by assigning the resources (CPUs) and
initializing the scheduler. An activated cpu-pool owns at least one physical
CPU.
A physical CPU may be removed from an activated cpu-pool. Further CPUs may be
assigned to the cpu-pool. The CPU may be assigned to a cpu-pool only if that
CPU is free (not assigned to any other activated cpu-pool). The free CPUs are
internally managed.
The poolname will be added as an additional parameter to the configfile of a
domain. If no poolname is specified the poolname is defaults to pool0. At
domain start the domain is added to its cpu-pool, which must be activated.
A started domain can be moved to another activated cpu-pool.
A cpu-pool may be deactivated if there is no active domain assigned to it. A
cpu-pool is deactivated by removing the resources (CPUs).
A cpu-pool may be deleted if it is deactivated.
The administration of the cpu-pools is done by xm subcommands.
new xm subcommands:
xm pool-new poolconfigfile [name=value]..
 define a cpu-pool.
 The pool-new sub command requires a config file and can optionally
 take a series of name value pairs that add to or override variables
 defined in the config file. See poolconfigfile description.
 poolconfigfile can either be an absolute path to a file, or a
 relative path to a file located in /etc/xen/pool.
xm pool-start <poolname>
 Activate a Xend managed cpu-pool.
 (The cpu-pool must be defined by xm pool-new (or by API). The
 cpu-pool will be activated only if the requested CPUs are
 available.)
xm pool-create poolconfigfile [name=value]..
 define a new cpu-pool and activate it.
xm pool-list [options] [poolname,...]
 List information about all/some cpu-pools.
 -l|--long Output all cpu-pool details in SXP
 output format for deactivated cpu-pools without option --long
 cpu-pool cpus sched domains
 <poolname> <# CPUs> <sched>
 output format for activated cpu-pools without option --long
 cpu-pool cpus sched domains
 <poolname> <list of CPUs> <sched> <list of active domains>
 output format with option --long
 (pool
 (name <poolname>)
 (uuid <uuid>)
 (state <activated|deactivated>)
 (cpun <number of CPUs>)
 (cpus <list of CPUs>)
 (sched <sched>)
 (domains <list of started domains running in the cpu-pool>)
 )
xm pool-destroy <poolname>
 deactivate a cpu-pool.
 (Unassign the CPUs of the cpu-pool. Delete the cpu-pool
 if it was created by xm pool-create.
 A cpu-pool may be deactivated only if there are no active
 domains added to it.)
xm pool-delete <poolname>
 Delete the cpu-pool.
 (deletion is only possible if the cpu-pool is deactivated.)
xm pool-cpu-add <poolname> <cpu>
 Add a free cpu to the activated cpu-pool.
xm pool-cpu-remove <poolname> <cpu>
 Remove a cpu from the activated cpu-pool.
 (subsequent the removed CPU may be added to another cpu-pool.
 The last CPU of the cpu-pool cannot be removed explicitly.)
xm pool-migrate <domain> <poolname>
 move the domain to the specified cpu-pool.
extended subcommands
xm list ... [--pool=<poolname>]
 select only domains added to the cpu-pool.
xm list --long|-l
 additional info:
 (cpu_pool <poolname>)
xm info
 the line
 xen_scheduler : <sched>
 shows the scheduler of pool0.
 additional info:
 free_cpus : <n>
 (number of free CPUs)
xen pool configfile
 pool configuration files live in /etc/xen/pool by default. If you
 store config files anywhere else the full path to the config file must
 be specified in the xm pool-create command.
 supported options:
 name
 A unique name for the cpu-pool. Attempting to create two cpu-pools
 with the same name will cause an error.
 sched
 Name of scheduler (Default: credit)
 cpus
 List of CPUs to be activated or
 Number of CPUs to be activated (Default: 1)
 other_config
 ["<param> = <value>" ...]
xen domain configfile
 additional option:
 pool
 Name of cpu-pool the domain is added to.
 xm create or xm start is rejected if the cpu-pool is not
 activated.
 For pinning only CPUs of the cpu-pool are taken into account.
Autostart of cpu-pools and domains
Before starting a domain automatically its cpu-pool has to be started.
By default all CPUs are assigned to the cpu-pool pool0.
As for automatically starting a cpu-pool free CPUs are needed, a new boot
parameter in /boot/grub/menu.lst is required to create pool0 with less CPUs.
To specify a cpu-pool is to be started at boot-time, its configfile (or a link
to it) has to be placed in /etc/xen/pool/auto/. The xendomains script for
automatically starting domains has to be extended. Before starting the domains
the autostart of the cpu-pools is done.
Juergen
-- 
Juergen Gross Principal Developer
IP SW OS6 Telephone: +49 (0) 89 636 47950
Fujitsu Siemens Computers e-mail: juergen.gross@xxxxxxxxxxxxxxxxxxx
Otto-Hahn-Ring 6 Internet: www.fujitsu-siemens.com
D-81739 Muenchen Company details: www.fujitsu-siemens.com/imprint.html
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel