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.

Tuesday, April 21, 2026

How to Add LUN to a Non-Global Zone in Solaris Using ZFS

How to Add LUN to a Non-Global Zone in Solaris Using ZFS

Introduction

In Solaris environments, disk management for non-global zones follows a controlled and secure approach. Unlike global zones, non-global zones cannot directly access physical disks or LUNs. Instead, storage must be provisioned at the global zone level and then delegated to the non-global zone using ZFS datasets.

This blog walks you through the complete process of adding a LUN to a non-global zone by:

  • Creating a ZFS pool in the global zone
  • Delegating a dataset to the non-global zone
  • Creating and mounting a filesystem inside the zone

⚠️ Important Note:
This activity requires a zone reboot. Please plan an appropriate downtime for the non-global zone before proceeding.


Scenario Details

For this walkthrough, we are using the following example values:

  • Zone Name: test-live-fo1
  • ZFS Pool Name: test_logpool
  • LUN WWID: 600601608AE24E00D1B5E96550D021DE

Step 1: Prechecks on the Global Zone

Log in to the global zone and collect baseline information before making any changes.

Shell
df -h
cat /etc/vfstab
ifconfig -a
cat /etc/passwd ; cat /etc/passwd | wc -l
cat /etc/group ; cat /etc/group | wc -l
netstat -in
netstat -rn
svcs -xv
zpool list
zfs status
zfs status -xv
ps -ef | grep -i pmon
echo | format
zoneadm list -iv
zonecfg -z test-live-fo1 info

These prechecks help in:

  • Validating system health
  • Confirming existing pool and zone configuration
  • Capturing a rollback reference if needed

Step 2: Prechecks on the Non-Global Zone

Log in to the activity (non-global) zone and run the same precheck commands listed in Step 1.

This ensures:

  • Consistency between zones
  • No pre-existing filesystem or mount conflicts

Step 3: LUN Assignment and Detection (Global Zone)

The storage team will assign the LUN to the physical server (global zone). Once the LUN is presented, rescan the disks and identify the new LUN.

Shell
echo | format
cfgadm -al
devfsadm -c disk
echo | format

Identify the LUN using its WWID:

Shell
echo | format | grep -i 600601608AE24E00D1B5E96550D021DE
format c0t600601608AE24E00D1B5E96550D021DEd0

Make sure the correct disk is identified before moving forward.


Step 4: Create a New ZFS Pool in the Global Zone

Once the LUN is confirmed, create a ZFS pool.

Shell
zpool create test_logpool c0t6006016080E24E005F34DCxxxxxxxxxxxxxFd0
zpool list
zpool status test_logpool

At this stage:

  • The pool exists only in the global zone
  • It is not yet accessible to the non-global zone

Step 5: Delegate the Dataset to the Non-Global Zone

Now, delegate the dataset to the required zone.

Shell
zonecfg -z test-live-fo1
zonecfg:test-live-fo1> add dataset
zonecfg:test-live-fo1> set name=test-live-fo1/test_logpool
zonecfg:test-live-fo1> end
zonecfg:test-live-fo1> verify
zonecfg:test-live-fo1> commit
zonecfg:test-live-fo1> exit

This step authorizes the non-global zone to use the dataset derived from the global pool.


Step 6: Create ZFS Filesystem and Mount It (Inside the Zone)

Log in to the non-global zone and create a filesystem.

Shell
zfs create test_logpool/logs
mkdir /logs
zfs set mountpoint=/logs test_logpool/logs
df -kh /logs

The filesystem is now visible inside the zone with the specified mount point.


Step 7: Set Directory Permissions

Adjust ownership and permissions as per application requirements. In this example, we assign ownership to the weblogic user and group.

Shell
chown -R weblogic:weblogic /logs
ls -ld /logs

Step 8: Verify and Apply Zone Configuration Changes

Back in the global zone, verify and apply the zone configuration.

Shell
zonecfg -z test-live-fo1 info
zoneadm -z test-live-fo1 verify
zoneadm -z test-live-fo1 apply

Reboot the activity zone (planned downtime required):

Shell
zoneadm -z test-live-fo1 reboot

After reboot, log in and verify:

Shell
zlogin test-live-fo1
zoneadm list -iv

If required, reset mount properties:

Shell
zfs set mountpoint=none olfo1_logpool

Step 9: Final Verification

Confirm that the filesystem is correctly mounted and accessible inside the non-global zone.

Shell
zlogin test-live-fo1
df -kh /logs

Conclusion

By following this approach:

  • Physical storage is securely managed in the global zone
  • Non-global zones receive controlled access via ZFS datasets
  • Best practices for Solaris zone isolation are maintained

This method ensures flexibility, security, and maintainability when managing storage for Solaris non-global zones.