What a Processor Value Unit Measures
A Processor Value Unit (PVU) is IBM's unit of processor-based licensing. IBM publishes a fixed table assigning a PVU-per-core rating to each supported processor family — commonly 70, 100, or 120 PVUs per core depending on the chip. Your entitlement requirement is the PVU-per-core rating multiplied by the number of cores the program counts. The per-core rating itself is non-negotiable; what you can influence is the core count IBM is entitled to charge for — and that is the entire game.
The discount applied to PVU pricing is negotiable too: large enterprises typically secure 20–40% off IBM list through an Enterprise Licence Agreement or point-licence deal layered on their Passport Advantage relationship. But discount on the wrong core count still overcharges you — counting comes first.
Sub-Capacity vs Full-Capacity Counting
Under full capacity, IBM requires PVU entitlements for every activated core in the physical server, regardless of how few the software actually uses. Under sub-capacity, you license only the activated cores made available to the program — the virtual cores allocated to the partition or VM where the product runs. On a heavily virtualised host, the difference is routinely a 40–70% reduction in the required entitlement.
Sub-capacity is the default expectation for any modern virtualised estate, but it is a conditional right, not an automatic one. Fail the conditions and IBM reverts the affected workloads to full capacity — the most expensive outcome in distributed IBM licensing.
The Three Eligibility Conditions
Sub-capacity eligibility rests on three simultaneous conditions, all of which must hold:
| Condition | Requirement |
|---|---|
| Eligible product | The program must appear on IBM's Eligible Sub-Capacity Products list |
| Eligible technology | Hypervisor and processor must be on IBM's approved virtualisation and processor lists (current cut-offs: 20 March 2026 and 1 October 2025) |
| Approved tracking tool | ILMT (or an IBM-validated tool such as BigFix Inventory or Flexera One) installed within 90 days, with quarterly reports retained two years |
The tracking-tool condition is the one organisations break most often. Our ILMT configuration guide covers the 90-day deadline, quarterly reporting, and the retention rule in detail — it is the operational backbone of every sub-capacity claim.
Hard Caps, Soft Caps and LPAR Counting
How you cap a partition decides how many cores IBM counts. A hard cap enforces a fixed maximum of cores a partition can ever consume; IBM counts the capped figure. A soft cap allows bursting above the entitlement, and IBM counts the higher of the cap or observed peak. On IBM Power, micropartitioning lets you allocate fractional (sub-core) processor entitlements, and AIX counts the allocated entitlement rather than the whole physical core — a powerful lever covered in our Power Systems licensing guide.
The single most common sub-capacity overpayment is an uncapped or soft-capped partition that occasionally bursts. ILMT records the peak, IBM bills the peak, and you pay for capacity you used for minutes. Enforce hard caps wherever the workload allows and the meter follows the cap, not the spike.
A Worked Example: 64-Core Host
Take a 2-socket server with 64 activated cores at a PVU rating of 70 per core, running one Db2 instance hard-capped to 8 cores. Under sub-capacity, the requirement is 8 × 70 = 560 PVUs. Lose eligibility — a missing ILMT agent, a lapsed quarterly report — and IBM counts all 64 cores: 64 × 70 = 4,480 PVUs, an eight-fold increase for identical usage. At enterprise PVU pricing, that single host can swing six figures, and a data centre full of them swings into the millions. This is why Db2 cost reduction and middleware rationalisation always start with the counting position, not the discount.
Optimising Your PVU Position
Three levers move your PVU bill without touching usage: enforce hard caps so the meter follows the cap; consolidate eligible workloads onto fewer, correctly-capped hosts rather than spreading them across uncapped capacity; and keep ILMT current so eligibility never lapses. Rebaselining at hardware refresh typically removes 10–30% of entitlement that no longer maps to real workloads. These moves compound with a negotiated discount — and the evidence they produce strengthens every IBM conversation, from Cloud Paks to subscription migration. To pressure-test your PVU position, request a confidential briefing.
The Five Most Common PVU Counting Errors
Across hundreds of IBM positions, the same five errors recur — and each quietly converts a sub-capacity entitlement into a full-capacity liability. First, uncapped or soft-capped partitions: ILMT records the peak and IBM bills the peak, so a workload that bursts for minutes is licensed as if it ran at that level all month. Second, stale or missing ILMT: a lapsed quarterly report or an unpatched scanner reverts the affected hosts to full capacity for the period, regardless of actual usage.
Third, unlisted virtualisation or processor technology: running a hypervisor or processor that is not on IBM's approved list invalidates sub-capacity for that partition even when ILMT is otherwise perfect. Fourth, bundle and part-number mis-mapping, where a product deployed as part of a bundle is catalogued incorrectly and the audit re-rates the difference at full capacity. Fifth, assuming sub-capacity without proving it — treating the lower number as the default rather than as a conditional right that must be evidenced every quarter — and never rebaselining at hardware refresh, so entitlement drift accumulates unchecked. Eliminate these five and the vast majority of PVU overpayment disappears before any discount is even discussed.
This guide is one of eleven in our IBM licensing cluster. To connect PVU counting to the rest of your IBM estate, read it with the IBM master guide, ELA negotiation, Passport Advantage, ILMT configuration, Db2 cost reduction, Cloud Paks licensing, watsonx pricing, mainframe MLC and zIIP, Power Systems and AIX, and subscription migration.
One area that repeatedly surprises buyers is how IBM treats mobile workloads. Under the Virtualization Capacity counting rules, if an eligible product can move across hosts, for example a VM able to vMotion anywhere in a VMware cluster, IBM may require you to license every host the workload could land on, not just where it currently runs. Pinning workloads to defined host-affinity groups, and documenting that restriction, is what keeps the counted capacity bounded. The same logic applies to clustered Power frames and to live-partition mobility. Getting the cluster boundary and affinity rules right is often worth more than any negotiated discount, because it changes the size of the entitlement IBM is entitled to count in the first place, and it is precisely the area auditors probe hardest.
Where PVU Counting Fits
PVU counting governs IBM's distributed middleware and is the foundation beneath ILMT compliance and most ELA negotiations. It does not apply to the mainframe, where MLC and MSU metrics rule, nor to consumption platforms like watsonx. Read it with the IBM master guide, the IBM vendor hub, and the IBM Licensing Guide white paper.