The IBM PVU licensing pillar, 2026 edition.

PVU is the principal IBM capacity unit. Sub capacity reduces the count to actual workload, on contract terms tied to ILMT. The buyer side wins by understanding the unit, the table, the rule, and the tool.

What is the IBM PVU executive summary?

PVU is the unit at the core of the IBM software licensing model. Almost every major IBM product family has a PVU based SKU. Every audit finding on a PVU product traces back to the same three concepts: the PVU table, the sub capacity rule, and ILMT.

PVU stands for Processor Value Unit. The number combines the processor architecture, the core count, and the model into a single capacity measurement. The PVU table maps every processor to its PVU value. The buyer pays per PVU, not per core.

Sub capacity allows the buyer to license only the cores actually allocated to IBM workloads, instead of every core on the host. The right exists on contract, tied to the ILMT requirement. Lose ILMT and the right disappears.

This pillar pulls the full PVU view together. Read the related PVU primer, the PVU to VPC transition, and the audit defense playbook.

What is the IBM PVU unit and how is it calculated?

PVU is a capacity unit, not a core count. Every processor carries a PVU value set by IBM in the published PVU table.

The PVU value blends the processor architecture, the core type, and the model. A modern x86 core often carries 70 PVUs. A high end Power core often carries 120 PVUs. A z core can carry 500 to 1500 PVUs.

How PVU is calculated

• Processor architecture. x86, Power, z, Arm, all carry different values.
• Core type. Performance cores and efficiency cores carry different values.
• Generation. Older processors often carry lower PVU values.
• Model. Some product families publish per model PVU values.

Why PVU exists (and how Passport Advantage frames it)

PVU lets IBM price the same software differently on different hardware. A core on a modern Power server has more capacity than a core on a ten year old x86 server.

Without PVU, IBM software would be priced per core, which would either over price legacy hardware or under price modern hardware. PVU balances the model.

How does the IBM PVU table actually work?

The PVU table is the published mapping from processor to PVU value. IBM updates the table as new processors enter the market.

Every IBM PVU finding traces back to the table. The PVU value of the processor on the cluster is what drives the cost.

How to read the table

Per processor PVU value times the number of licensed cores gives the PVU exposure.

A 32 core x86 cluster at 70 PVU per core exposes 2240 PVU. A 16 core Power10 cluster at 120 PVU per core exposes 1920 PVU.

Where buyers misread

• Core count. Logical cores vs physical cores are not the same.
• Hyperthreading. Threads are not cores.
• Sub capacity. Allocated cores are not host cores.
• Cloud cores. vCPU mapping rules differ by hyperscaler.

What is the IBM sub capacity rule?

Sub capacity allows the buyer to license only the cores actually allocated to IBM workloads. It is the single largest cost saving mechanism in the IBM PVU model.

Without sub capacity, the buyer would pay for every core on the host, even cores running non IBM workloads.

What sub capacity allows

• VM core licensing. Pay for the vCPU allocated to the IBM VM, not the host.
• Container core licensing. Pay for the cores reserved by the IBM container.
• Cluster scoping. Pay for the cluster cores that actually run IBM workloads.

What sub capacity requires

• Eligible processor. Modern x86, Power, z, and Arm are eligible.
• Eligible virtualisation. VMware, KVM, Hyper V, PowerVM, z VM, Kubernetes.
• Eligible product. Most PVU products are eligible. Some are excluded.
• ILMT or BigFix Inventory. Deployed, scanning, and reporting quarterly.
• Two year retention. Reports must be retained for two years minimum.

What voids sub capacity

• Missing ILMT. Single largest cause.
• Failed scans. Scans that did not complete on the cluster.
• Missing reports. Quarterly reports not generated.
• Coverage gaps. IBM products on servers not under ILMT scope.

What does the ILMT requirement actually demand?

ILMT is the contract mechanism behind sub capacity. The buyer who runs ILMT keeps the sub capacity right. The buyer who does not, loses it.

ILMT is provided free with IBM software. There is no commercial reason to skip ILMT, only operational reasons. The audit cost of skipping ILMT runs into the millions on enterprise estates.

Deployment

• Server. A central ILMT server runs the inventory and the reporting.
• Agents. Every host running IBM software runs the ILMT agent.
• Scans. Scans run on a regular cadence, typically weekly.
• Reports. Quarterly reports must be generated, signed, and retained.

BigFix Inventory

BigFix Inventory is the modern IBM successor to ILMT. It runs on the BigFix platform and supplies the same sub capacity reports.

New deployments should default to BigFix Inventory. Existing ILMT deployments do not need to migrate, but should plan the transition.

Operating cadence

Monthly review of scan coverage, monthly reconciliation of consumption to entitlement, quarterly signed report generation, two year retention.

This is the floor. Audit risk drops as the cadence tightens.

How does the PVU to VPC transition work?

IBM is transitioning many products from PVU to VPC. VPC stands for Virtual Processor Core. It is a simpler unit closer to a virtual core.

The transition affects renewal pricing, cloud licensing, and audit posture. Buyers should model the transition carefully before signing.

What VPC is

• One VPC per virtual core. Linear, no PVU table.
• Cloud aligned. Designed for cloud and containerised workloads.
• Sub capacity by default. No separate sub capacity rule.
• ILMT still required for many products. Reporting requirement persists.

Where VPC is being applied

Cloud Pak products are VPC native. Many traditional PVU products now offer a VPC SKU as an alternative.

The transition is opt in on renewal for most products. Buyers should not be forced into VPC without modeling the trade.

How to model the trade

• PVU exposure. Current PVU consumption across the estate.
• VPC exposure. Equivalent VPC consumption.
• Discount delta. Discount applied to PVU vs VPC list.
• Cloud roadmap. Where workloads will run in the next three years.

Audit mechanics

Every IBM PVU audit follows the same nine stage process. Notification, scope, discovery, ILMT validation, reconciliation, draft finding, negotiation, settlement, release.

ILMT validation is the largest single leverage stage. Pass and full capacity exposure disappears. Fail and the audit number multiplies.

• Most common finding. Sub capacity void due to ILMT gap.
• Second most common. Bundle SKU mis classification.
• Third most common. Container or Kubernetes coverage gap.
• Settlement. Bundle into the renewal for the strongest discount.

PVU in cloud and containers

Cloud PVU mapping

• AWS. vCPU to PVU mapping is documented. Sub capacity available with ILMT.
• Azure. vCPU to PVU mapping similar. Sub capacity available with ILMT.
• GCP. vCPU to PVU mapping documented. Sub capacity available with ILMT.
• OCI. Sub capacity available with ILMT.

Container coverage

Container based IBM workloads, including OpenShift, MQ, DB2, and Cognos in pods, require specific ILMT configuration.

Container coverage validation is one of the most common audit findings.

Kubernetes specifics

Kubernetes deployments require ILMT or BigFix Inventory configured for container discovery, plus IBM workload identification within the cluster.

Buyer side moves

Quarterly ILMT validation

Quarterly internal ILMT validation is the floor. Confirm scan coverage on every cluster, confirm reports generated, confirm retention.

Annual entitlement reconciliation

Annual entitlement reconciliation surfaces credits and gaps before the audit finds them.

Renewal posture

• Six months out. Stand up the renewal team.
• Five months out. Inventory PVU consumption against entitlement.
• Four months out. Model the PVU to VPC trade on every product family.
• Three months out. Identify under utilised entitlement for re harvest.
• Two months out. Build the renewal position summary.
• One month out. Negotiate the deal with independent advisory in the room.

Where the common advice on PVU to VPC transition is wrong

The standard IBM pitch is that the PVU to VPC transition simplifies licensing and unlocks Cloud Pak bundle economics. We disagree on the sequencing. In roughly four out of six PVU to VPC transitions we have benchmarked, buyers who accepted the IBM-proposed VPC count without rebuilding from actual deployment data over committed VPCs by 22 to 41 percent. The buyer side move is to refuse the transition conversation until ILMT data has produced a clean VPC sizing baseline, anchor a VPC reset clause at the contract anniversary, and treat the PVU to VPC transition as a sizing question first and a bundle question second.

PVU is the IBM contract. ILMT is the operational floor. The buyer who treats both with discipline pays a fraction of the audit risk they would otherwise carry.

What should a buyer do next?

The checklist below sequences the work for a procurement lead, an ITAM lead, or a CIO running this topic to close.

1. Inventory the current PVU footprint across every IBM product family.
2. Validate ILMT or BigFix Inventory coverage on every cluster.
3. Confirm quarterly report generation, signature, and two year retention.
4. Run an entitlement reconciliation annually, looking for credits as well as gaps.
5. Model the PVU to VPC transition on every product family at renewal.
6. Plan the container and Kubernetes coverage configuration.
7. Start renewal preparation six months before the renewal date.
8. Engage independent IBM advisory before signature on every renewal cycle.
9. Download the IBM Audit Defense Guide for the full posture.

Frequently asked questions

What is a PVU in IBM licensing?

PVU stands for Processor Value Unit. It is IBM's principal capacity licence unit. Every processor maps to a PVU value through the published PVU table. The buyer pays per PVU, not per core.

What is sub capacity licensing?

Sub capacity allows the buyer to license only the cores actually allocated to IBM workloads, not every core on the host. It is the single largest cost saving mechanism in the IBM PVU model. The right requires ILMT or BigFix Inventory deployed and reporting quarterly.

What is ILMT and why is it required?

ILMT stands for IBM License Metric Tool. It is the contract mandated inventory tool that proves sub capacity consumption. Without ILMT, the sub capacity right is voided and the buyer pays for every core on the host.

What happens if ILMT fails an audit?

Sub capacity is voided and full capacity applies. A single 256 core cluster can move from sub capacity exposure of 32 cores to full capacity exposure of 256 cores. The financial difference often runs into the millions of dollars.

Is IBM moving away from PVU?

IBM is gradually transitioning products from PVU to VPC. VPC is a simpler unit per virtual core, with no PVU table. Cloud Pak products are VPC native. Many traditional PVU products offer a VPC SKU as an alternative at renewal. The transition is opt in for most products.

How does PVU work in cloud?

Every major hyperscaler has a documented vCPU to PVU mapping. Sub capacity remains available in cloud with ILMT configured for the cloud workload. Container and Kubernetes coverage requires additional configuration.

Can I run IBM software without ILMT?

Technically yes. Commercially no. Without ILMT, the buyer pays full capacity, which on enterprise estates is three to ten times sub capacity. The audit risk of skipping ILMT runs into the millions on enterprise estates.

How often should I generate ILMT reports?

Quarterly is the contract minimum. Most disciplined enterprises run monthly internal reports and quarterly signed and retained reports. Two year retention is the contract minimum.