The Solaris Resource Pools facility allows you to take the resources of a large system and split them into chunks that can be allocated to users or groups.
Configuration has two distinct components: the setting up of pools with the appropriate allocation of resources, and the setting up of projects to associate users or groups with resource pools.
You can use pools and projects to fairly allocate resources on a shared machine. (Particularly when coupled with the Fair Share Scheduler.) Another possibility is to partition a large machine to comply with licensing terms, if you're only licensed for a small number of processors. Unfortunately this last one really requires Solaris 10 and Zones to actually work.
This document describes how to set up pools in Solaris 9. The procedure is slightly different in Solaris 10.
As an example of using Solaris 10 with containers to partition a machine for licensing purposes, this document explains how to do it for Oracle. If you're using Solaris 10 (which you should be), you're better off looking at that document than this one.
The pool configuration file is /etc/pooladm.conf. If it
doesn't exist (this is the default), start things off with:
poolcfg -c discover
I'll create a sample pool, that has two processors in it. First you configure the processor set, then create the pool, then associate the processor set with the pool:
poolcfg -c 'create pset peter_set (uint pset.min=1 ; uint pset.max=2)' poolcfg -c 'create pool peter_pool' poolcfg -c 'associate pool peter_pool (pset peter_set)'
Assuming that all went OK, you can enable the configuration with:
pooladm -c
Projects are defined in the /etc/project file.
This looks like the passwd or group or shadow file - it's a colon separated file. The first field is the project name. There are a couple of special names that are important. If the project name consists of the string "user." followed by a username, then that's the project associated with that username. If the project name consists of the string "group." followed by a group name, then that's the project associated with that group.
So, as an example, if my username is ptribble then I
can define a project entry for myself as follows:
user.ptribble:2001:Peter:::project.pool=peter_pool
Not only does this define a project for me, it also associates me
with the pool peter_pool I set up earlier.
Just to summarize what I've done here: I've created a resource pool that contains a 2-cpu processor set, and then - by means of the project definition - associated processes belonging to a specific user to that pool, and hence to that processor set.
I can then log in as that user and run programs to my heart's content, and I get my allocated processors but no more.