Labels

hpunix (63) marathi kavita (52) linux (21) solaris11 (11) AWS (5) numerology (5)

Monday, July 13, 2026

Dynamically Expanding CPU Resources for a Production Zone


Oracle Solaris Resource Pools: Dynamically Expanding CPU Resources for a Production Zone

One of the powerful capabilities of Oracle Solaris is the ability to allocate dedicated CPU resources to critical workloads using Resource Pools and Processor Sets. Recently, I had to increase the CPU allocation for a clustered production zone without causing any downtime.

This article walks through the process of reviewing the existing configuration, backing up the resource pool configuration, modifying the processor set, and activating the changes online.


Environment Overview

The server hosts multiple Solaris zones:

root@solaris-node01# zoneadm list -cv

ID NAME STATUS PATH BRAND IP
0 global running / solaris shared
1 appzone01 running /zones/appzone01 solaris10 excl
2 prodcluster01 running /zones/prodcluster01 solaris excl
3 clonezone01 running /zones/clonezone01 solaris excl
4 clonezone02 running /zones/clonezone02 solaris excl


Reviewing the Production Zone Configuration

The target zone was prodcluster01.

root@solaris-node01# zonecfg -z prodcluster01 info

zonename: prodcluster01
zonepath: /zones/prodcluster01
brand: solaris
autoboot: true
pool: prodpool
scheduling-class: FSS

[max-shm-memory: 64G]
[max-shm-ids: 4096]
[max-sem-ids: 4096]

net:
physical: vnic0
net:
physical: vnic1

attr:
name: cluster
type: boolean
value: true
``

Notable configuration items:

  • Dedicated Resource Pool
  • Fair Share Scheduler (FSS)
  • Cluster-enabled zone
  • 64 GB shared memory allocation
  • Multiple network interfaces for cluster traffic

Reviewing Current Pool Allocations

Before making any resource changes, check the current pool distribution.

root@solaris-node01# poolstat

pset
id pool size used load
1 prodpool 32 0.00 2.93
0 pool_default 80 0.00 1.38
2 dbpool 16 0.00 0.56

Current CPU allocation:

PoolCPUs
prodpool32
dbpool16
pool_default80

The production zone currently owns a dedicated processor set containing 32 CPUs.


Verify Processor Set Configuration

Check the current processor set definition.

poolcfg -c 'info pset prodpset'

Output:

pset prodpset

uint pset.min 32
uint pset.max 32

This indicates that the processor set is statically configured with 32 CPUs.


Backup the Existing Configuration

Before making changes, always save the current configuration.

pooladm -s /var/tmp/poolcfg-backup-$(date +%Y%m%d)

Verification:

ls -lrt /var/tmp/poolcfg-backup-20260427

-rw-r--r-- 1 root root 19.7K Apr 27 14:18
/var/tmp/poolcfg-backup-20260427

Having a backup provides a quick rollback option if necessary.


Increasing CPU Allocation

The requirement was to increase CPU resources allocated to the production cluster zone.

Current allocation:

32 CPUs

Target allocation:

48 CPUs

Modify the processor set:

poolcfg -c 'modify pset prodpset (uint pset.min=48; uint pset.max=48)'

At this point, the change is stored in the configuration repository but has not yet been activated.


Verify Before Activating

Checking immediately after the modification:

poolstat

pset
id pool size used load
1 prodpool 32 0.00 3.92
0 pool_default 80 0.00 1.26
2 dbpool 16 0.00 0.58

The active configuration still shows 32 CPUs because the updated configuration has not yet been committed.


Activate the New Configuration

Apply the modified resource pool configuration.

pooladm -c

This operation dynamically reallocates CPUs without requiring a system reboot.


Verify the Results

Check the allocations again:

poolstat

pset
id pool size used load
1 prodpool 48 0.00 4.42
0 pool_default 64 0.00 1.58
2 dbpool 16 0.00 0.56

Success.

The production processor set increased from:

32 CPUs → 48 CPUs

and the CPUs were automatically taken from the default pool:

pool_default: 80 CPUs → 64 CPUs

All changes were made online with no interruption to the running zone.


Lessons Learned

Always Backup First

Before modifying any resource pool configuration:

pooladm -s <backup_file>

Having a rollback option is a best practice in production environments.

Changes Are Not Active Until Committed

Modifying the processor set changes only the configuration database.

poolcfg ...

To activate the change:

pooladm -c

Online Resource Reallocation

Oracle Solaris allows CPUs to be reassigned between processor sets dynamically, enabling administrators to respond quickly to changing workload demands without requiring downtime.

Resource Pools Simplify Capacity Management

Dedicated pools provide predictable performance and workload isolation for critical applications.


Command Summary

# Review zone configuration
zonecfg -z prodcluster01 info

# Review active pool allocations
poolstat

# Review processor set configuration
poolcfg -c 'info pset prodpset'

# Backup current configuration
pooladm -s /var/tmp/poolcfg-backup-$(date +%Y%m%d)

# Increase allocated CPUs
poolcfg -c 'modify pset prodpset (uint pset.min=48; uint pset.max=48)'

# Apply configuration
pooladm -c

# Verify results
poolstat

Conclusion

Oracle Solaris Resource Pools provide a powerful framework for workload isolation and capacity management. In this example, a production cluster zone's dedicated CPU allocation was increased from 32 CPUs to 48 CPUs using online pool reconfiguration, demonstrating how Solaris can dynamically adapt system resources to meet evolving business demands without impacting application availability.