A Processor Value Unit is IBM's per-core pricing unit for processor-based software. This guide explains the per-core ratings of fifty to one hundred and twenty, how IBM counts cores under full and sub-capacity licensing, and how to calculate a PVU requirement.
A PVU, or Processor Value Unit, is the unit in which IBM prices most of its processor-based software, including WebSphere, MQ, Db2 and Cognos. The requirement is simple to state: you license the number of cores the software can use, multiplied by a per-core rating drawn from IBM's published table. Admodum is an independent, buyer-side software licensing advisory firm, and this page explains the PVU metric so you can calculate, and defend, your own requirement.
IBM introduced the PVU because raw processor counts stopped tracking processing power once multi-core chips arrived. A single modern socket can deliver many times the throughput of an older one, so pricing per socket would have under-charged dense chips and over-charged sparse ones. The PVU re-bases pricing onto a unit that scales with delivered capacity: more powerful chip families carry a higher per-core rating, so the licence cost rises with the processing power exposed to the software.
This page is part of the IBM sub-capacity licensing pillar, which sets out the wider compliance model. For how the metric is actually measured in practice, read it alongside ILMT deployment and the 90-day rule; the contract that governs the whole arrangement is covered in the Passport Advantage agreement structure.
IBM publishes a Processor Value Unit table that maps each supported processor family to a per-core rating. The ratings are not arbitrary; they encode IBM's assessment of the relative processing power a core in that family delivers.
| Processor family (illustrative) | Typical per-core PVU rating |
|---|---|
| Mainstream x86 (Intel Xeon, AMD EPYC) | 70 PVUs per core |
| High-end IBM Power | 100 or 120 PVUs per core |
| Entry / constrained processors | 50 PVUs per core |
| Certain older or low-core-count chips | 50 to 70 PVUs per core |
The figures above are illustrative of the bands; the authoritative value for any specific processor is whatever IBM's current table assigns to that exact part. The practical lesson is that the same logical workload can carry materially different PVU costs depending on the silicon it lands on, which is why hardware decisions and licensing decisions cannot be made in isolation. A migration onto a higher-rated Power platform, for instance, raises the PVU requirement even if the number of cores is unchanged.
Because the rating is per core and modern servers carry many cores, PVU requirements scale quickly. A two-socket server with sixteen cores per socket at 70 PVUs is 2,240 PVUs at full capacity before a single additional host is considered, which is why estate-wide counting, not single-server intuition, is the only reliable way to size an IBM position.
The PVU figure is only as meaningful as the core count it multiplies, and the core count depends entirely on whether you are licensing at full capacity or sub-capacity. This is the single most consequential decision in IBM processor-based licensing.
Under full capacity, IBM counts every activated core in the physical server on which an eligible product is installed, regardless of how much of that capacity the product can actually use. Under sub-capacity, IBM counts only the virtual cores made available to the product, capped at the physical capacity. The difference is frequently several-fold: a product pinned to four virtual cores on a thirty-two-core host is 280 PVUs at sub-capacity but 2,240 PVUs at full capacity, an eight-fold gap on one machine.
Sub-capacity is not automatic. To count only the virtual cores you must run an eligible product on an eligible virtualisation technology and substantiate the virtual allocation with the IBM License Metric Tool, reporting within the ninety-day window and retained for two years. Absent that evidence, IBM is entitled to the full-capacity figure. The full mechanics sit in ILMT deployment and the 90-day sub-capacity rule and the sub-capacity pillar.
The arithmetic is simple once the inputs are clear: countable cores multiplied by the per-core rating. The difficulty is always in establishing the correct core count.
Example one, a single sub-capacity workload. Db2 runs in a virtual machine allocated four virtual cores, on hosts with 70-PVU processors, with valid ILMT reporting. The requirement is 4 × 70 = 280 PVUs. The same Db2 instance without ILMT evidence, on a thirty-two-core host, reverts to full capacity: 32 × 70 = 2,240 PVUs.
Example two, a Power platform. WebSphere runs on eight cores of an IBM Power server rated at 120 PVUs per core. The requirement is 8 × 120 = 960 PVUs. The higher per-core rating means the Power deployment costs more in PVUs than an equivalent core count on x86, a fact that belongs in any platform business case.
Example three, an estate. Ten hosts, each two sockets of sixteen 70-PVU cores, running WebSphere across virtual machines totalling forty virtual cores. Sub-capacity is 40 × 70 = 2,800 PVUs. Full capacity is 10 × 32 × 70 = 22,400 PVUs. The roughly nineteen-and-a-half-thousand-PVU gap is what a single missing ILMT deployment can put on an audit finding.
Most PVU errors are not arithmetic; they are errors of core counting and evidence. The recurring ones are worth naming so they can be designed out.
The buyer-side discipline is to hold a current map of every deployed product, the processor family and rating it runs on, the countable core basis, and the ILMT evidence that supports it. That map is the foundation for both audit defence and renewal leverage. The defensive playbook is in surviving an IBM software licence review; the wider engagement sits at the IBM practice and the aggregated reading at the IBM knowledge hub. To put a senior advisor on your PVU position, get in touch.
A PVU, or Processor Value Unit, is IBM's pricing unit for processor-based software such as WebSphere, MQ and Db2. Each processor core is given a per-core rating from IBM's published table, and the licence requirement is the number of cores the software can use multiplied by that rating. The rating reflects the relative processing power of the chip family, not its clock speed.
It depends on the chip family. IBM's Processor Value Unit table assigns each core a rating, almost always between 50 and 120 PVUs. A typical x86 core is rated at 70 PVUs, many IBM Power cores at 100 or 120, and some constrained chips at 50. You multiply the per-core rating by the number of countable cores to get the PVU requirement.
Multiply the number of countable cores by the per-core PVU rating for that chip family. For example, four cores on a 70-PVU processor require 4 x 70 = 280 PVUs. Whether you count the full physical core count or only the virtual cores depends on whether you qualify for sub-capacity licensing with valid ILMT reporting.
Not because of clock speed. The PVU rating is set per chip family in IBM's table, so a higher-frequency core in the same family carries the same rating. What raises the requirement is more cores, or a chip family with a higher per-core rating, which is why denser, higher-core-count servers can sharply increase the PVU count for the same workload.
No. PVUs are the classic per-core metric for traditional IBM software, weighted by the chip family. Virtual Processor Cores (VPCs) are the simpler metric used for IBM Cloud Paks in containerised environments, counting virtual cores directly without a per-core weighting. A hybrid estate may carry both metrics at once and must satisfy each separately.
The full processor-based compliance model this metric sits inside.
Our white paper sets out the PVU and sub-capacity model in full, with the evidence IBM auditors test against. A senior Admodum IBM advisor will then read your core counts and ILMT records before IBM does. Renewal moments route to the Renewal Programme; sign up for the newsletter for vendor-policy alerts.