HP Instant Capacity Version 10.x User Guide (762794-001, March 2014)

redistribution, it remains in compliance. Make sure that you have proper licensing for all proprietary
and nonproprietary software when performing load balancing.
Understanding and managing intended active values
The iCAP software maintains a value for each nPartition of a complex called intended active.
Fundamentally, the intended active value is the number of cores intended to be active after a reboot
of the nPartition.
The concept and proper manipulation of intended active is critical because:
• It determines the number of cores which will be active upon the boot of an nPartition.
• The value is used to establish the allocation of core usage rights for an nPartition within the
total number of core usage rights purchased for the complex. That is, it represents the intended
distribution of core resources for each nPartition.
When the intended active value changes, the distribution of usage rights across the hard partitions
is changed, and the core resources originally intended for one nPartition might be diverted to
another nPartition. In fact, this is the mechanism that allows for load balancing of resources to
occur. Within a GiCAP group, changes to the intended active value allow resources to be load
balanced across the entire group. Naturally, it is important to be sure that this is an intentional
redistribution of resources.
Note that even inactive nPartitions have an intended active value that represents a “reservation”
of usage rights for that partition. This is necessary to ensure every configured nPartition has core
resources to boot.
IMPORTANT: An nPartition that was created but never booted to HP-UX will implicitly reserve
usage rights for all configured cores, regardless of any intended active value set for the nPartition.
Within a virtual partition environment, the intended active value is especially critical because a
value that does not conform to the virtual partition assignments can result in a virtual partition
environment that cannot be booted. For more information see “Boot time compliance” (page 46).
In a virtual partition environment, the behavior of the icapmodify -a, -d and -s options is
different when there is unused capacity represented by an intended active value that exceeds the
sum of the cores assigned to the virtual partitions in an nPartition, as described in “Activations and
deactivations in a virtual partition environment” (page 44).
Activations and deactivations in a virtual partition environment
iCAP can be present on HP-UX systems or partitions where virtual partition technology is employed.
In a virtual partition environment, cores that are not assigned to any virtual partition are considered
inactive (in addition to other classes of inactive cores). Unassigned cores can be assigned (activated)
or assigned core can be deassigned (deactivated) using either the icapmodify command or the
vparmodify command, depending on the type of adjustment needed and the level of logging
or reporting desired.
One important consideration is that vparmodify can be used to activate or deactivate cores in
other virtual partitions within the nPartition; icapmodify only activates or deactivates cores within
the current virtual partition (the partition where the command is invoked). The vparmodify
command does not change the value for the number of intended active cores for the nPartition.
Another consideration is that core assignment via the vparmodify command does not result in
iCAP logging of the activation, email configuration change notification, or transmission of an asset
report to HP.
44 Using iCAP to manage processing capacity