IBM PVU licensing: how Processor Value Units really work.
The Processor Value Unit is the metric behind most IBM middleware bills, and it is the number auditors lean on hardest. Understand how PVU is built, where sub-capacity changes it, and where the math quietly goes against you, and the audit becomes a calculation you can check rather than a verdict you accept.
PVU is a capacity based metric. It ties the cost of IBM software to the processing power of the hardware it can run on, rather than to users or installs. The idea is simple, but the way the number is assembled, and the conditions that decide whether you pay for part of a server or all of it, are where most audit exposure lives.
The core formula
Every processor core carries a PVU rating from the IBM Processor Value Unit table. You multiply the PVU per core by the number of cores the IBM software is entitled to run on, and that product is the licensing requirement. As a working figure, a typical Intel core rates around 70 PVU, so a product entitled to run on ten such cores needs roughly 700 PVU of entitlement. The exact rating depends on the processor family and model, which is why the table, not a single number, governs the result.
PVU per core (from the IBM table) times the number of cores allocated to the IBM software equals the PVU you must license. Change either input and the bill changes with it, which is exactly where audits are won and lost.
Full-capacity versus sub-capacity
By default, IBM can charge for every physical core in the server where the software is installed. That is full-capacity. Sub-capacity licensing lets you instead license only the virtual cores the software is actually allocated, which on a large host is dramatically cheaper. The difference is not small. WebSphere using four of a host's thirty two cores is 480 PVU under sub-capacity and 3,840 PVU at full-capacity, the same software priced eight times higher purely on which rule applies.
Sub-capacity is not automatic. It requires the IBM License Metric Tool, or an approved alternative, deployed within 90 days of first eligible deployment, running continuously, with quarterly reports retained for two years. Eligible virtualization technology is also required. Miss any condition and IBM is entitled to revert that environment to full-capacity for the affected period.
Where the PVU math goes wrong
- Wrong core counts. Allocated cores, not physical cores, drive sub-capacity, but reports often pick up the host total and inflate the number.
- Wrong PVU rating. Applying the wrong processor family rating from the table lifts every core in the calculation.
- Lost sub-capacity standing. A tooling gap flips an environment to full-capacity, multiplying the result even though nothing was over-deployed.
- Bundled engines double counted. An engine licensed under a parent product gets counted again as a standalone PVU charge.
- Entitlement offsets ignored. Owned entitlements that should net against the deployment are left out of IBM's position.
Beyond PVU: RVU and VPC
PVU is not the only metric. RVU, the Resource Value Unit, is usage based and tied to a resource quantity such as client devices or managed users rather than to CPU. VPC, the Virtual Processor Core, applies to a growing set of products, and since Passport Advantage v11 sub-capacity reporting and ILMT now apply to VPC metered products too, with manual counting no longer permitted. Knowing which metric governs each product is the first step in checking whether the bill is even built on the right unit.
PVU is PVU per core times allocated cores, but the two inputs IBM chooses, the core count and the rating, plus whether sub-capacity standing holds, decide whether you owe a manageable number or one many times larger. Recalculate it independently before you accept it, because the default assumptions almost always run in IBM's favor.