IBM PVU Licensing: A Practical Guide for Enterprise IT Teams

What Is a Processor Value Unit?

A Processor Value Unit (PVU) is a unit of measure IBM uses to differentiate the licensing cost of software running on different processor technologies. IBM introduced PVUs in 2006 as a more nuanced alternative to simple per-processor licensing. The principle is that software running on a more powerful processor should cost more to licence than the same software running on a less capable processor — and PVUs operationalise that principle by assigning different PVU-per-core values to different processor families and generations.

IBM maintains a published PVU table that assigns specific PVU-per-core values to every processor type on which IBM Passport Advantage software can run. IBM Power processors carry higher PVU ratings than Intel or AMD processors, reflecting Power's historically stronger single-thread performance. Current IBM POWER10 processors carry 120 PVUs per core, while a typical Intel Xeon Gold series carries 70 PVUs per core.

To calculate a PVU licence requirement for full-capacity licensing: multiply the number of physical processor cores by the PVU-per-core value for that processor type. A 16-core Intel Xeon server running IBM Db2 requires 16 × 70 = 1,120 PVUs under full-capacity licensing. The same software on a 16-core POWER10 server requires 16 × 120 = 1,920 PVUs.

Full Capacity vs Sub-Capacity PVU Licensing

Full Capacity Licensing

Under full-capacity PVU licensing, you must licence IBM software for every physical processor core on the server where that software is installed — regardless of how many cores are actively used by the software or allocated to a virtual machine running the software. Full capacity is the default mode. It requires no special tools, no configuration, and no ongoing measurement — just the purchase of enough PVU entitlements to cover all physical cores on all servers where IBM software is installed or potentially could run.

Full-capacity licensing is appropriate for bare-metal deployments where IBM software runs directly on the physical hardware without virtualisation, and for virtualised environments where the organisation chooses not to meet the ILMT requirements needed for sub-capacity eligibility. While administratively simpler, full capacity is dramatically more expensive in virtualised environments where the software footprint represents only a fraction of total server capacity.

Sub-Capacity (Virtualisation Capacity) Licensing

Sub-capacity PVU licensing allows you to licence IBM software only for the processor cores assigned to the virtual machine or LPAR where that software runs — not for every core on the physical host. This is the critical financial lever in IBM middleware licensing: sub-capacity licensing can reduce the number of PVUs required by ten to twenty times in environments where IBM software runs on a small fraction of a large physical server's capacity.

Sub-capacity licensing is available for IBM software products running in qualifying virtualisation environments, including VMware, Hyper-V, IBM PowerVM (LPARs), and container platforms. However, eligibility for sub-capacity rates depends on meeting IBM's technical and administrative requirements — most critically, the correct deployment and operation of IBM License Metric Tool (ILMT).

ILMT: The Gateway to Sub-Capacity PVU Savings

IBM License Metric Tool (ILMT) is IBM's designated tool for measuring and reporting PVU sub-capacity usage. To qualify for sub-capacity PVU licensing, ILMT must be deployed as an agent on every virtual machine or LPAR where IBM sub-capacity eligible software runs. ILMT agents discover IBM software installations, determine the PVU metric applicable to each product, track the maximum number of processor cores used by each VM or LPAR over each quarter, and generate audit snapshot reports at quarter-end.

IBM's sub-capacity terms are explicit: ILMT must be operational and generating reports throughout the period for which you wish to claim sub-capacity rates. If ILMT was not deployed during a period, or if it was deployed but not generating reports, IBM treats that period as full-capacity for all IBM software deployed during that time. Back-charges for full-capacity periods can be significant — particularly if they cover multiple years of a complex IBM middleware estate.

ILMT Operational Requirements

Beyond basic deployment, ILMT must be correctly configured to generate accurate sub-capacity data. Key operational requirements include: regular software catalogue updates (IBM releases catalogue updates to recognise new IBM product versions — an outdated catalogue means software goes unrecognised and unreported); continuous ILMT agent coverage (every VM where IBM software runs must have an agent — new VMs created after initial deployment must be added to ILMT scope immediately); and retention of quarterly audit snapshots for a minimum of two years (IBM can request historical snapshots during an audit, and missing records are treated as non-compliance for the relevant periods).

For IBM Power Systems running AIX, ILMT must additionally account for processor pool configurations where LPARs share physical cores dynamically. The sub-capacity count tracks peak concurrent usage, not minimum configured allocation — dynamic processor sharing can result in higher ILMT readings than expected if LPARs draw from a shared pool during peak workload periods.

The PVU to VPC Transition: What Changed and Why It Matters

IBM's shift from PVU to Virtual Processor Core (VPC) licensing reflects the architectural change from traditional VM-based deployments to containerised workloads. PVUs are hardware-weighted — a Power core is worth more PVUs than an Intel core because Power historically delivers more per-core throughput. VPCs are hardware-neutral — one VPC equals one virtual CPU core regardless of the underlying processor type or generation.

IBM Cloud Pak products — IBM's containerised software bundles built on Red Hat OpenShift — are primarily licensed under VPC metrics rather than PVUs. As enterprises migrate traditional IBM middleware workloads from VM environments (PVU-licensed, ILMT-measured) to containerised Cloud Pak environments (VPC-licensed, IBM License Service-measured), they move between two different metric systems that require separate entitlements and separate measurement tools.

Compliance Gaps Created by the PVU to VPC Transition

The PVU to VPC transition created compliance gaps that IBM audit teams actively target. The most common gap occurs when an organisation migrates IBM middleware to containers but either does not deploy IBM License Service (the container-equivalent of ILMT) or does not formally execute the PVU-to-VPC conversion through Passport Advantage. Both gaps can result in IBM asserting that the containerised deployment is unlicensed.

A second compliance gap arises during migration overlap periods, when IBM software runs simultaneously in both the old VM environment (PVU-measured by ILMT) and the new container environment (VPC-measured by IBM License Service). If only PVU entitlements exist, the container deployment may be outside licence scope. If the VPC entitlements were purchased as a conversion of PVU licences, the old PVU licences may have been cancelled, leaving the VM-side deployment unlicensed during the overlap. Careful orchestration of licence conversion timing with the infrastructure migration schedule is required to avoid either scenario.

PVU Optimisation Strategies

Right-Size ILMT Scope

The most immediate PVU cost optimisation opportunity is ensuring that ILMT is generating accurate sub-capacity readings — not inflated ones. Common sources of ILMT over-reporting include: VMs included in ILMT scope that no longer run IBM software (abandoned deployments that were never removed from ILMT management), dynamic processor pool configurations that allow VMs to temporarily draw more cores than their baseline allocation, and ILMT catalogue recognition issues that misidentify products as more expensive editions.

Consolidate IBM Middleware to Fewer, Larger VMs

Under sub-capacity licensing, the cost is determined by the maximum processor cores allocated to each VM — not by the number of VMs. Consolidating IBM middleware workloads from many small VMs onto fewer larger VMs (where the aggregate core allocation is lower) can reduce the sub-capacity PVU count. This strategy requires careful workload compatibility analysis but can deliver meaningful licence reductions in environments with excessive VM sprawl.

Hard Partition Processor Allocation

In virtualised environments, configuring hard resource limits for VMs running IBM software — rather than allowing dynamic scaling — produces predictable, stable PVU measurements that match licence inventory planning. Dynamic resource allocation may improve VM performance during peak periods, but at the cost of higher peak PVU readings in ILMT, which drive licence requirements upward.

Audit PVU Entitlement Inventory

Many IBM PVU environments carry excess entitlements from historical deployments that have been decommissioned but whose licences were never formally retired through Passport Advantage. A PVU entitlement audit — comparing active ILMT readings against Passport Advantage licence inventory — often reveals shelfware positions that can be applied against growth, reducing new licence purchases. IBM does not proactively notify customers of excess entitlements; that identification requires the customer's own analysis.

IBM Fiscal Year and PVU Negotiation Timing

IBM's fiscal year ends on 31 December. IBM's licensing sales teams face significant fourth-quarter targets, creating pricing flexibility for enterprise customers negotiating PVU entitlement packages in October through December. Enterprises that time their annual PVU reviews or ELA renewals to coincide with IBM's fiscal year-end consistently report better pricing outcomes than those who renew mid-year.

The combination of ILMT-based sub-capacity data as a negotiation anchor — particularly when your data shows actual usage significantly below purchased entitlements — and fourth-quarter IBM commercial pressure provides the most productive conditions for PVU licence rationalisation and cost reduction negotiations.