Counting cores on LPAR and Power systems.
Power is the platform where intuition about licensing fails most often. On LPAR, IBM counts the cores allocated to a partition, not the cores the workload actually uses. An idle allocation costs exactly the same as a busy one, and the gap between what you think you run and what IBM counts is where the PVU exposure lives.
Allocation, not utilization
The principle that surprises most Power estates is that sub capacity on LPAR counts allocation, not utilization. If a partition is allocated four cores and the workload only ever drives one, IBM still counts four. The metric is the virtual processors made available to the partition, bounded by the physical cores in the shared pool, taken at the maximum over the reporting period. Trimming CPU usage does not trim the licence. Trimming the allocation does.
Capped, uncapped and the shared pool
Power partitions can be capped, holding them to a defined entitlement, or uncapped, letting them draw spare capacity from the shared pool up to their virtual processor count. For licensing, the figure that matters is the maximum the partition could reach: its virtual processors, limited by the physical cores in the pool it draws from. An uncapped partition with eight virtual processors on a sixteen core pool is counted at eight, even if it rarely climbs past two. This is why uncapped partitions quietly accumulate exposure that no utilization graph reveals.
The PVU rate still applies
Once the core count is set, the PVU calculation is unchanged. Each Power core carries a PVU per core value for its processor generation, and total PVU is cores times that rate. A misread of the allocation therefore multiplies straight through to the licence position. On Power, where per core rates are high, a single partition counted at its allocation rather than a smaller true need can move the number materially.
Where the count goes wrong
The common errors are consistent. Partitions over allocated at build time and never trimmed. Uncapped partitions assumed to be counted at their average draw. ILMT not reading the LPAR configuration correctly after a frame migration or a dynamic reconfiguration. Decommissioned partitions still present in the inventory. Each of these is a correctable reconciliation item, and each is one an auditor will resolve in IBM's favour if you have not resolved it in yours first.
On Power and LPAR, the licence follows the cores allocated to the partition, including idle and uncapped headroom, not the cores the workload uses. Confirm the allocation ILMT reads matches the partitions you actually run, trim over allocations before the lookback captures them, and recalculate PVU on the corrected count. The difference between allocated and needed cores is the exposure, and it is yours to find first.
Power partitions counted at allocation?
Our PVU Reconciliation engagement reads your LPAR configuration the way IBM does, recalculates PVU on the cores actually allocated, and flags the over allocations and uncapped headroom inflating your position. We mobilize within 48 hours of your audit notice.
See PVU Reconciliation →The IBM Audit Brief
Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.
Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.