The PVU table is a pricing instrument. Read it carefully and cost drops by a third.
Processor Value Unit rates differ by processor architecture, by core count, and by sub capacity status. The same workload on different infrastructure can cost three times as much. We model the optimal placement and trim the bill.
Same workload, different processor, different bill.
The Processor Value Unit table assigns a per core rating to every supported processor family that IBM ships PVU priced software on. Ratings range from 30 PVU per core for some Intel Xeon parts to 120 PVU per core for the highest tier Power and Z hardware. The same workload on a 70 PVU per core part instead of a 120 PVU per core part is paying 42 percent less for the same entitlement. The arithmetic is brutal and most enterprises have never modelled it.
PVU optimization is not only sub capacity. Sub capacity reduces the count of cores that the software is allowed to use. PVU optimization reduces the PVU rating per core through placement decisions. The two stack. On a dense virtualization estate the combined effect routinely cuts the PVU bill by a third.
The placement decisions interact with sub capacity, ILMT, and the broader entitlement ledger. We model the alternatives, run the entitlement math, and quantify the saving net of any operational cost. Read the related work on sub capacity and ILMT.
The five levers.
- Move PVU heavy workloads to lower rated processor families.
- Cap virtual machines at the smallest viable vCPU count.
- Use shared processor pools where eligibility allows.
- Consolidate licensed workloads onto fewer hosts.
- Harvest unused entitlement before renewal.
How we read the PVU position and find the savings.
Baseline entitlement and consumption
Build the baseline from the Passport Advantage entitlement view, ILMT consumption reports, and the current PVU table. Compute the entitlement utilization rate for each PVU based product. Read about Passport Advantage for context on the entitlement side.
Placement modelling
For the largest PVU consumers, model the per core PVU rate on the actual hosts versus the rate on alternative supported hosts in the estate. Quantify the PVU and dollar delta if the workload moves. Flag where the move is constrained by ISV support, by data locality, or by performance.
Sub capacity stacking
On top of the placement model, validate that the sub capacity claim survives the move. ILMT health, virtualization eligibility, and the eligible product list all interact with the placement decision. The combined effect is the figure the business case is built on.
Harvesting and renewal sequencing
Sequence the harvesting moves before the next renewal so that the reduced entitlement count carries into the renewal negotiation. See the harvesting work and the negotiation practice.
What the math looks like in practice.
An enterprise runs WebSphere Application Server Network Deployment on a cluster of Power 10 hosts at 120 PVU per core. ILMT reports a quarterly peak of 64 cores consumed across the eligible footprint. Entitlement obligation is 64 multiplied by 120 equals 7680 PVU. Annual maintenance is approximately 200,000 dollars at the published PVU rate for this product.
Modelling the same workload on the existing Intel Xeon estate at 70 PVU per core, with sub capacity caps and ILMT validated, the obligation falls to 64 multiplied by 70 equals 4480 PVU. Annual maintenance falls to approximately 117,000 dollars. The placement saving is roughly 83,000 dollars per year. Stacked on top of a harvesting recovery of unused WebSphere entitlement, the combined saving on this single product line approaches 35 percent.
When the placement move is blocked.
- ISV support matrix excludes the target processor family.
- Data locality or sovereignty rules require specific regions or zones.
- Performance characteristics of the target host are insufficient.
- The workload is part of an integrated stack that has to move together.
- The target host is itself capacity constrained.
- The platform team has a sunset plan that contradicts the placement.
How clients approach PVU optimization.
How much saving can we realistically expect?
The portfolio average is 35 percent on PVU based product spend. Range is wide. Estates that have never optimized routinely see more. Estates that have already run sub capacity tightly see ten to fifteen percent additional.
Do we need to move workloads to lower rated hardware?
Not always. Many savings come from sub capacity tightening, harvesting, and report hygiene rather than physical placement moves. Placement moves are the most material lever where they apply.
How does this interact with Cloud Pak conversion?
Cloud Pak conversion replaces the PVU model with a Virtual Processor Core model for products that are in scope. The optimization model changes shape. We run the Cloud Pak conversion analysis as part of the Cloud Pak work.
Can we do this analysis with the SAM team in house?
You can. The blockers are typically time and the depth of knowledge of the PVU table interactions. Most clients use us for the diagnostic and harvest the saving themselves.
Does this apply to mainframe?
Mainframe uses a different metric. MSU. The optimization principles are different. See the mainframe expertise page.
Resources
Expertise
Services
Need an independent read on this area?
A senior advisor responds within 24 hours and scopes a credible engagement structure within a week.
Get an independent read on this area of your IBM estate.
Tell us where you are in the cycle. A senior advisor will respond within 24 hours with a scoped engagement structure and an availability window. No sales call, no pitch deck. We do not resell IBM software. We have no IBM Business Partner status. Our recommendations are constrained only by what is good for the buyer.
Read more on why independence matters or browse the services overview for engagement structures.
Request a conversation
Corporate email required. Personal email addresses are not accepted.