IBM PVU Licensing and the Processor Value Unit
How the PVU metric weights cores by processor type, why ILMT decides the count, and how to hold the PVU total down.
IBM PVU licensing assigns a Processor Value Unit weighting to every processor core based on its type, commonly 70 to 120 PVUs per core, and because a deployment without a maintained IBM License Metric Tool is counted at full physical capacity rather than the allocated virtual cores, a missing ILMT routinely inflates the PVU requirement by two to four times. The PVU table and the sub-capacity rules, not the raw core count, are what decide an IBM PVU bill, and both reward buyers who manage them deliberately.
This guide explains how the PVU metric counts, why ILMT controls the total, and how to hold a PVU position down. It pairs with our IBM licensing complete guide, the sub-capacity rules, and the firm's IBM advisory practice.
What a Processor Value Unit is
The Processor Value Unit is IBM's weighted core metric: rather than counting cores equally, IBM assigns each processor type a PVU value per core, published in the PVU table, and you license the sum of PVUs across the cores a product runs on. A core on one processor type might be rated at 70 PVUs while a core on another is rated at 100 or 120, so the same number of cores can carry a different PVU total depending on the hardware. The product price is then quoted per PVU.
This weighting means hardware choice affects the license cost, because two servers with the same core count can carry different PVU totals if their processors are rated differently in the table. A buyer refreshing hardware should check the PVU rating of the target processors, since a chip with a lower PVU-per-core rating reduces the license requirement for the same compute. The PVU table is a cost input that most buyers ignore, and our IBM advisory team checks it on every PVU-metered refresh.
Sub-capacity is the difference between paying for cores you use and cores you own
By default, IBM counts PVUs at full capacity, meaning every physical core in the server the product could run on, regardless of how few the product actually uses. Sub-capacity licensing lets you instead count only the virtual cores allocated to the product, which on a virtualized host is usually a fraction of the physical total. The catch is that sub-capacity is conditional: it requires running and maintaining the IBM License Metric Tool and retaining its reports.
| Counting basis | What is counted | Requirement |
|---|---|---|
| Full capacity (default) | All physical cores in the host | None, but the most expensive |
| Sub-capacity | Virtual cores allocated to the product | ILMT running and reports retained |
| Lapsed ILMT | Reverts to full capacity | Penalty exposure at audit |
The gap between full capacity and sub-capacity on a modern virtualized host is large, frequently a factor of two to four, which is why a lapsed or misconfigured ILMT is one of the most expensive mistakes in IBM licensing. Holding the sub-capacity count is worth more than most negotiated discounts, the same point made across our full versus sub-capacity and IBM ILMT guides.
Compliance warning: ILMT is not optional for sub-capacity, and the requirement is strict. The tool must be installed within 90 days of the first sub-capacity deployment, must scan the environment at least every 30 minutes for the relevant data, and must retain reports for at least two years. A buyer who deploys sub-capacity but lets ILMT lapse, misconfigures the scan, or discards the reports loses the sub-capacity right retroactively, and an audit will recount the entire period at full capacity. The cost of maintaining ILMT is trivial against the two-to-four-times exposure of losing it, which is why it is the first control our advisors verify on any PVU estate.
PVU versus VPC
IBM has been moving newer products from PVU to the Virtual Processor Core metric, which counts virtual cores more directly and is designed for container and cloud deployments. Many estates now run a mix, with legacy products on PVU and newer ones on VPC, and the two metrics count differently even when the underlying compute is the same. A buyer with a mixed estate has to track both, and a migration that moves a product from PVU to VPC can change the licensable total in either direction.
The decision when a product offers both metrics is to model the count under each and choose the cheaper for the specific deployment, the same metric-choice discipline that runs through our VPC licensing and Db2 licensing guides. Do not assume the newer metric is always cheaper, because for a given deployment shape either can win, and the only way to know is to calculate both.
Consolidation and right-sizing the PVU count
Because PVUs scale with the cores a product runs on, consolidating workloads onto fewer, denser hosts reduces the PVU total directly. An estate spread across many lightly used servers carries more licensable PVUs than the same workloads consolidated onto fewer hosts running closer to capacity, and the difference is real license cost. A consolidation exercise ahead of a renewal lowers the count and produces the utilization evidence that supports a smaller footprint.
Consolidation compounds with sub-capacity: fewer hosts, each tracked by ILMT, means a smaller virtual-core count held against smaller physical capacity. The work is operational, but it changes the baseline the renewal is negotiated against, which is why the deployment shape should be examined before the price. A right-sized PVU estate is both cheaper to license and a stronger negotiating position, the same logic our advisors apply across the IBM core-metered portfolio.
PVU in the cloud
Running PVU-metered products in public cloud changes the counting, because cloud instances expose virtual cores and the sub-capacity rules apply to how those cores are counted and tracked. IBM publishes guidance on how cloud vCPUs map to its metrics, and a buyer moving a PVU product to cloud must confirm whether ILMT or an accepted alternative covers the cloud environment, since a cloud deployment that falls outside sub-capacity tracking reverts to a full-capacity count. A migration that looks cost-neutral on infrastructure can shift the licensing basis against the buyer.
Before migrating, model the PVU count in the target cloud environment, confirm the sub-capacity tracking, and check whether bring-your-own-license terms apply, because the licensing impact can dominate the infrastructure saving. Modeling the licensing and the infrastructure together, the way we do in cloud contract negotiation, keeps a cloud move from quietly raising the license bill.
Locking the PVU position into the contract
The savings from sub-capacity, consolidation, and metric choice only hold when they are written into the renewal. An optimization that corrects the deployment but renews on the old, full-capacity-anchored terms carries the overspend forward, while a renewal negotiated on the corrected PVU position resets the baseline. The contract should reflect the optimized, sub-capacity-tracked, consolidated estate, not the one that accumulated before the cleanup.
A buyer arriving at the renewal with clean ILMT records, a consolidated footprint, and a documented PVU count holds a stronger hand than one negotiating on an unexamined estate. Every correction is a defensible reason the number should fall, the bargaining power our IBM negotiation team carries into the renewal, on the same runway logic as our IBM renewal strategy guide.
PVU products inside bundles and packs
Many PVU-metered products are also available inside bundles and Cloud Paks, where the entitlement covers the product as part of a larger pool, and a buyer running the same product both standalone and inside a pack risks counting it twice. A PVU product entitled under a Cloud Pak should not also carry a separate standalone PVU license for the same deployment, yet this double-counting is a common error when packs are adopted on top of an existing standalone estate. The pack entitlement and the standalone entitlement have to be reconciled so each deployment is counted once.
The control is to map every PVU-metered deployment to the single entitlement that covers it, standalone or pack, and remove the redundant license where a deployment is covered twice. This reconciliation often surfaces genuine savings, because the move to Cloud Paks frequently leaves legacy standalone entitlements in place that the pack has superseded. The pack-versus-standalone reconciliation is detailed in our Cloud Paks licensing guide.
Why PVU persists on legacy estates
IBM has steered new licensing toward the Virtual Processor Core metric, but PVU persists across large legacy estates because migrating a product's metric is a contractual event, not an automatic upgrade. An organization can run PVU-metered products for years after newer VPC options appear, and the PVU table and sub-capacity rules continue to govern those products. Understanding PVU is therefore not a historical exercise, it is a live requirement for any estate with established IBM middleware.
The decision facing such estates is whether to migrate products from PVU to VPC, which depends on whether the VPC count for the specific deployment is lower than the PVU count. The migration can save money or cost it, and only a per-product calculation reveals which, so a buyer should model both metrics before agreeing to any vendor-proposed conversion. This is the same metric-choice discipline that governs the Db2 licensing decision, applied across the legacy PVU portfolio.
Non-production PVU treatment
PVU-metered products often qualify for reduced or no-cost entitlement in development, test, and certain disaster-recovery environments, yet these copies are frequently licensed at full production PVU rates because nobody claimed the non-production terms. On a large estate with many non-production copies, this is a recurring and recoverable overspend independent of the sub-capacity question. The PVU count should reflect the entitled treatment of each environment, not a blanket production rate.
The control is to classify every PVU-metered instance by its actual role and apply the non-production and disaster-recovery terms the contract grants, so that idle standbys and qualifying test copies do not carry full production PVUs. This is the same role-based classification that protects against audit overcounts, and it pairs with the sub-capacity discipline to bring the PVU total down to genuine production need. Claiming the non-production terms is one of the cleanest PVU savings available.
The bottom line
IBM PVU licensing weights every core by processor type at 70 to 120 PVUs per core, and a missing or lapsed ILMT inflates the requirement two to four times by reverting to full capacity. Maintain ILMT to hold the sub-capacity count, check the PVU table on hardware refreshes, model PVU against VPC for each product, consolidate to lower the core total, and lock the position into the renewal. Buyers who hold sub-capacity routinely cut the count by half or more. Our advisors model and negotiate PVU positions across the IBM portfolio and the firm's licensing advisory practice.