The Capacity on Demand PVU trap on Power.
Power servers let you activate capacity on demand to ride out peaks. The licensing question is what happens to that capacity after the peak passes. Activate cores the wrong way and IBM can count them against your PVU long after the workload that needed them is gone.
Capacity on Demand, often shortened to CoD, is the Power feature that lets you turn on additional processor capacity that ships inside the machine but starts inactive. It is meant for flexibility: activate cores when you need headroom, and in some forms turn them off again. For IBM software licensing, the trap is that activated capacity can count toward your PVU position, and capacity that was activated and not cleanly deactivated can keep counting.
Why CoD interacts with PVU at all
On Power, PVU follows the cores the IBM software is entitled to run on, and on LPAR configurations allocated cores count even when idle. CoD changes how many cores are available to be allocated. When activated cores become part of the pool an LPAR can draw on, they can fall inside the boundary the sub-capacity calculation measures. The peak capacity the software could run on, not the average it actually used, is what an auditor looks for, and CoD is precisely a mechanism for raising that peak.
The trap in three forms
- Permanent activation left in place. Cores activated for a project are never turned back down, so they sit in the allocable pool and count indefinitely.
- Temporary capacity captured at the wrong moment. On demand or trial capacity active during the measurement window is read as available to the software, lifting the count for that period.
- Sub-capacity boundaries drawn too loosely. If the LPAR can reach activated cores, those cores can be pulled into the count even if the workload rarely touches them.
The PVU position on Power is built from the capacity the software was entitled to run on, including capacity that CoD made available during the period. A peak that lasted a weekend can set the number for the quarter. Utilization is not the measure; allocable capacity is.
How we defend the Power position
The defense is evidence about what capacity was genuinely available to the IBM software and when. We reconstruct the activation history, separate capacity that was truly part of the allocable pool from capacity that was activated for unrelated workloads or other partitions, and show where the sub-capacity boundary actually fell. Where activation was temporary, the record of when it started and stopped scopes the exposure to that window rather than letting it color the whole lookback. The aim is to count the cores the software could reach during each period, no more, and to document why everything else sits outside the boundary.
Capacity on Demand can quietly raise the cores that count toward your Power PVU, and activated capacity left in place keeps counting after the peak. Reconstruct the activation history and define the sub-capacity boundary precisely before IBM measures the machine at its high water mark.