Advanced POWER Virtualization on IBM System p5 - Previous ...

To remove a Capacity Upgrade on Demand processor (for example, when using
On/Off Capacity Upgrade on Demand, which enables users to temporarily
activate processors), you have to make sure that there are enough processing
units left to deactivate the processor. You can dynamically remove the needed
capacity entitlement from the partitions.
A type of Capacity Upgrade on Demand is named Reserve CUoD. It represents
an autonomic way to activate temporary capacity. Reserve CUoD enables you to
place a quantity of inactive processors into the server's Shared Processor Pool
which then become available to the pool's resource manager. When the server
recognizes that the base (purchased/active) processors assigned across
uncapped partitions have been 100% utilized, and at least 10% of an additional
processor is needed, then a Processor Day (good for a 24 hour period) is
charged against the Reserve CUoD account balance. Another Processor Day will
be charged for each additional processor put into use based on the 10%
utilization rule. After a 24-hour period elapses, and there is no longer a need for
the additional performance, so no Processor Days will be charged until the next
performance spike.
2.4.4 Dynamic processor de-allocation and processor sparing
If a physical processor in the shared processor pool reaches a failure threshold
and needs to be taken offline (guarded out), the <strong>POWER</strong> Hypervisor will analyze
the system environment to determine what action will be taken to replace the
processor resource. The options for handling this condition are the following:
►
►
If there is a CUoD processor available, the <strong>POWER</strong> Hypervisor will
transparently switch the processor to the shared pool, and no partition loss of
capacity would result.
If there is at least 1.0 unallocated processor capacity available, it can be used
to replace the capacity lost due to the failing processor.
If not enough unallocated resource exists, the <strong>POWER</strong> Hypervisor will determine
how much capacity each partition must lose to eliminate the 1.00 processor units
from the shared pool. As soon as each partition varies off the processing
capacity and virtual processors, the failing processor is taken offline by the
service processor and Hypervisor.
The amount of capacity that is requested to each micro-partition is proportional
to the total amount of entitled capacity in the partition. This is based on the
amount of capacity that can be varied off, which is controlled by the minimum
processing capacity of the partition defined in the attribute min in the partition
profile.
Chapter 2. <strong>Virtualization</strong> technologies on System p servers 41