In my last entry, I described how to change the memory configuration of a running zone.  The natural next question is of course, if that also works with CPUs that have been assigned to a zone.  The answer, of course, is “yes”.

You might wonder why that would be necessary in the first place.  After all, there’s the Fair Share Scheduler, that’s extremely capable of managing zones’ CPU usage.  However, there are reasons to assign dedicated CPU resources to zones, licensing is one, SLAs with specified CPU requirements another.  In such cases, you configure a fixed amount of CPUs (more precisely, strands) for a zone.  Being able to change this configuration on the fly then becomes desirable.  I’ll show how to do that in this blog entry.

In general, there are two ways to assign exclusive CPUs to a zone.  The classic approach is by using a resource pool with an associated processor set.  One or more zones can then be bound to that pool.  The easier solution is to use the parameter “dedicated-cpu” directly when configuring the zone.  In this second case, Solaris will create a temporary pool to manage these resources.  So effectively, the implementation is the same in both cases.  Which makes it clear how to change the CPU configuration in both cases: By changing the pool.  If you do this in the classical approach, the change to the pool will be persistent.  If working with the temporary pool created for the zone, you will also need to change the zone’s configuration if you want the change to survive a zone restart.

If you configured you zone with “dedicated-cpu”, the temporary pool (and also the temporary processor set that goes along with it) will usually be called “SUNWtmp_<zonename>”.   If not, you’ll know the name of the pool…  In both cases, everything else is the same:

Let’s assume a zone called orazone, currently configured with 1 CPU.  It’s to be assigned a second CPU.  The current pool configuration is like this: 
root@benjaminchen:~# pooladm                
system default
string
system.comment 
int
system.version 1
boolean
system.bind-default true
string
system.poold.objectives wt-load
pool pool_default
int
pool.sys_id 0
boolean
pool.active true
boolean
pool.default true
int
pool.importance 1
string
pool.comment 
pset
pset_default
pool SUNWtmp_orazone
int
pool.sys_id 5
boolean
pool.active true
boolean
pool.default false
int
pool.importance 1
string
pool.comment 
boolean
pool.temporary true
pset
SUNWtmp_orazone
pset pset_default
int
pset.sys_id -1
boolean
pset.default true
uint
pset.min 1
uint
pset.max 65536
string
pset.units population
uint
pset.load 687
uint
pset.size 3
string
pset.comment 
cpu
int
cpu.sys_id 1
string
cpu.comment 
string
cpu.status on-line
cpu
int
cpu.sys_id 3
string
cpu.comment 
string
cpu.status on-line
cpu
int
cpu.sys_id 2
string
cpu.comment 
string
cpu.status on-line
pset SUNWtmp_orazone
int
pset.sys_id 2
boolean
pset.default false
uint
pset.min 1
uint
pset.max 1
string
pset.units population
uint
pset.load 478
uint
pset.size 1
string
pset.comment 
boolean
pset.temporary true
cpu
int
cpu.sys_id 0
string
cpu.comment 
string
cpu.status on-line
As we can see in the definition of pset SUNWtmp_orazone, it has been assigned CPU #0.  To add another CPU to this pool, you’ll need these two commands: 
root@benjaminchen:~# poolcfg -dc 'modify pset SUNWtmp_orapset \
                     (uint pset.max=2)' 
root@benjaminchen:~# poolcfg -dc 'transfer to pset \
                     orapset (cpu 1)'

To remove that CPU from the pool again, use these:

root@benjaminchen:~# poolcfg -dc 'transfer to pset pset_default \
                     (cpu 1)'
root@benjaminchen:~# poolcfg -dc 'modify pset SUNWtmp_orapset \
                     (uint pset.max=1)'

That’s it.   If you’ve used “dedicated-cpu” for your zone’s configuration, you’ll need to change that before the next reboot.  If not, you’d have to use the pool name you assigned to the zone.

Further details: