>
Virtualization & Cloud Licensing

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.

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.

What this means under audit

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.

Sub-Capacity Defense
We defend the virtual capacity claim where IBM has defaulted you to full-capacity charging on Power and LPAR.
Get audit help now →
Keep reading.

Do not face the IBM audit alone.

$250M+ in exposure defended. 500+ engagements. We mobilize within 48 hours of your audit notice. Independent and buyer side, every time.

Get audit help now →

The IBM Audit Brief

Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.

IBM Audit

Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.

Services
Audit DefenseAudit NegotiationILMT RemediationSub-Capacity Defense
Products
WebSphereDb2CognosCloud Pak
Company
AboutContactJournalWhite Papers
Independent. Not affiliated with IBM Corporation.Buyer Side · Est. 2019