What a PVU is.
The Processor Value Unit, the PVU, is the IBM licence metric assigned to a specific class of processor core. The metric is intended to normalise licensing cost across the range of processor architectures IBM software runs on. A single high performance Power core has a different PVU value from a single x86 core, and a single x86 core has a different PVU value depending on the model generation and the vendor. IBM publishes the PVU table on the IBM website and updates it as new processors are released.
The PVU is therefore a per core multiplier. The customer counts the cores allocated to the IBM product, looks up the PVU per core, multiplies, and the result is the licence requirement in PVUs. The customer then purchases the corresponding PVU entitlement under Passport Advantage. The PVU metric applies to most distributed IBM middleware and database products.
This guide is written from the buyer side, by independent advisors. We are not an IBM Business Partner, reseller, or affiliate. The view that follows reflects the buyer side interest only. For the underlying licensing programme, see the IBM Licensing Complete Guide. For the PVU optimization expertise practice, see the PVU optimization expertise page.
The PVU table.
The PVU table is the catalogue of processor models with their assigned PVU per core. The table is published by IBM and is the authoritative reference. Categories of processor receive different PVU values. The variation between categories is material. The table below lists representative ranges to anchor the buyer side understanding; the IBM published table is the operational source of truth.
| Processor family | Representative PVU per core | Notes |
|---|---|---|
| IBM Power, current generation | 120 PVU | Power class processors. Highest PVU per core. |
| IBM Power, older generation | 70 to 100 PVU | Older Power generations. |
| x86 multi core, current Intel and AMD | 70 PVU | Most x86 servers in enterprise. |
| x86 dual core legacy | 50 PVU | Older Intel and AMD. |
| IBM zEnterprise IFL | 120 PVU | Linux on Z. |
| ARM, current | 70 PVU | ARM server class. |
How PVU counting works.
PVU counting follows three steps. First, identify the IBM product and its eligibility under full capacity or sub capacity rules. Second, identify the cores allocated to that product. Third, multiply by the PVU per core. The arithmetic is straightforward; the operational discipline at each step is where buyer side cost leaks out.
Step one. Product identification.
The product License Information document specifies the PVU metric, the sub capacity eligibility, and any product specific rules. The buyer side discipline is to read the LI document. The summary on the product page is not the contract.
Step two. Core allocation.
Under full capacity, the cores are the physical cores of the host. Under sub capacity, the cores are the virtual cores allocated to the virtual machine that contains the IBM product, capped at the physical cores of the host. The cap is important; a virtual machine that is allocated more virtual cores than the host has physical cores does not pay for more than the physical capacity.
Step three. PVU multiplication.
Multiply core count by PVU per core. Sum across all instances of the product. The result is the licence requirement. The customer holds entitlement for at least that PVU count. Excess entitlement is acceptable, deficit entitlement is a compliance issue.
Sub capacity and PVU.
Sub capacity is the difference between licensing for the full physical host and licensing for the virtual capacity actually allocated to the IBM product. For a product running on two virtual cores in a virtual machine on a host with thirty two physical cores, the sub capacity right reduces the licence requirement by approximately ninety four percent compared to full capacity. The mechanic is the central cost lever in distributed IBM.
Sub capacity rights require ILMT, eligible virtualisation environments, and quarterly peak reporting retained for two years. The full mechanics are covered in the Sub Capacity Explained article and the ILMT guide.
PVU optimization levers.
The PVU table is not negotiated, but the customer placement decisions against the PVU table are very negotiable in their cost impact. Five repeating optimization levers apply to PVU metric products.
Lever one. Workload placement.
Run IBM workloads on hosts with the lowest PVU per core ratio that meet the performance requirement. A workload that runs on a 70 PVU core host requires forty two percent less licence than the same workload on a 120 PVU core host. The placement is operational, the licence saving is contractual.
Lever two. Hardware refresh sequencing.
Sequence hardware refresh to move workloads onto newer processors with favourable PVU per core ratios. The hardware refresh business case can carry the licence saving as a line item.
Lever three. Virtualisation rebalancing.
Rebalance virtual machines containing IBM products to minimise the peak concurrent core allocation across the measurement period. The peak is the licence; lowering the peak lowers the licence.
Lever four. Cloud Pak conversion.
Convert legacy PVU entitlement to Cloud Pak VPC entitlement where the workload mix justifies the conversion. The conversion ratio is the negotiation lever. See Cloud Pak licensing.
Lever five. Edition right sizing.
Some IBM products have multiple editions with different price points. Running the Advanced edition where the Standard edition would meet the requirement is a frequent and easily correctable overspend. The buyer side audit of edition vs feature use is high leverage.
PVU and audit.
PVU products are the most frequently audited part of the IBM distributed estate. The audit mechanics are well established. IBM requests ILMT output, Software Inventory output, and peak reports. IBM reconciles the customer reported PVU requirement against entitlement on record. Any deficit is asserted as unlicensed deployment with back charged Subscription and Support.
The buyer side discipline is to maintain ILMT health continuously, to run a quarterly self assessment, and to retain reports for the two year window. The customer who is current on all three at the moment of audit notification has a structurally easier audit. See the IBM Audit Complete Guide and the Audit Defense service.
Where to go next.
For the PVU optimization expertise practice, see the PVU optimization expertise page. For the sub capacity programme, see Sub Capacity Explained. For the ILMT operational discipline, see the ILMT guide. For the integrated cost discipline, see the IBM Cost Optimization Guide. For the in depth strategy paper, see the PVU Optimization Strategies white paper.
For a scoped advisory conversation, the contact page is the entry point. A senior advisor responds within 24 hours.
Continue reading.
IBM Sub Capacity Licensing Explained
The sub capacity programme that turns PVU full capacity into virtual capacity. The single highest leverage cost lever in distributed IBM.
Read the articleIBM Cost Optimization Guide
The integrated buyer side cost discipline. PVU optimization is one of eight levers.
Read the articlePVU Optimization Strategies
30 page guide. PVU metric, hardware refresh, workload placement, virtualisation patterns, container migration, hyperscaler IaaS.
View white paperIBM Sub Capacity Licensing Guide
40 page primer on the IBM sub capacity programme.
View white paperGet the next IBM licensing brief in your inbox.
Buyer side guidance on IBM licensing, audit defense, and renewal negotiation. Monthly, written by senior advisors. Corporate email only.
By submitting you agree to our privacy policy. Unsubscribe any time.
Ready to apply this to your IBM estate?
An independent senior advisor on your IBM estate. No resell margin, no IBM relationship to protect, no time pressure to push a product. Just the buyer side view.