IBM on Power LPAR: Allocated Cores Count Even When Idle
A common and expensive misunderstanding on IBM Power is that licensing follows usage. It does not. On a Power LPAR, sub-capacity counts the cores assigned to the partition running the IBM software, whether those cores are pinned at full load or sitting idle. Capacity allocated, not capacity used, is what IBM charges.
Allocation is the metric, not utilization
PVU is a capacity metric. It multiplies the value units per core by the number of cores available to the IBM software, not by the average load those cores carried over the quarter. On a dedicated LPAR, that means every core assigned to the partition is in scope from the moment the software can run there, regardless of how lightly the workload actually used it. Teams that size partitions for peak headroom and assume the quiet hours reduce the bill discover the gap only when the audit report lands.
Dedicated, capped, and uncapped partitions
How the partition is configured changes what counts. A dedicated partition counts its assigned physical cores. A shared pool partition is governed by the rules for that pool, and a capped partition can limit the countable cores to the cap, while an uncapped partition that can borrow from the shared pool is measured against the cores it is entitled to consume. Getting this classification right is the difference between a defensible number and a full-capacity surprise.
- Dedicated: the physical cores assigned to the LPAR, idle or not
- Capped shared: bounded by the entitlement cap when configured correctly
- Uncapped shared: measured against the cores the partition can reach in the pool
- Virtual processors set above need: a frequent and avoidable source of overcount
Why ILMT still has to see it
Power and LPAR are eligible virtualization technologies for sub-capacity, but eligibility is not automatic. The sub-capacity claim still depends on ILMT, or an approved tool, deployed within 90 days of first eligible deployment, running continuously, with quarterly reports retained for two years. If ILMT cannot read the partition correctly, or the agent lapsed during the lookback, IBM defaults that period to full-capacity charging against the entire physical host. On a large Power frame, the difference between partition cores and frame cores is enormous.
How buyers defend the number
The defensible position is built from the partition configuration and the continuous ILMT record together. We reconcile the cores actually allocated to each LPAR against what ILMT reported, correct virtual processor settings that inflate the count, and confirm the partitions were capped where the design intended. Where a finding charges full host capacity, the counter is the configuration evidence plus the retained reports that show the real allocated cores for each quarter in scope.
On Power and LPAR, the question is never how busy the cores were, it is how many cores the partition could use. Right size virtual processors, cap partitions where appropriate, and keep ILMT running continuously so the allocated cores are documented quarter by quarter. Without that record, IBM charges the full physical frame, and on Power that is the most expensive default in the metric.