Home · Insights · IBM

IBM Sub-Capacity PVU Strategy: The defensible deployment.

An IBM sub-capacity PVU strategy is one of the highest-return licensing disciplines an enterprise IBM customer can apply. Done correctly, sub-capacity reduces effective licensing cost by 40 to 80 percent against full capacity. Done badly, it produces an audit exposure that erodes the savings and then some. This guide is the IBM sub-capacity PVU strategy we recommend across our IBM engagements.

SoftwareContractNegotiation Editorial Team
May 26, 2026
8 min read
Cluster: IBM

Processor Value Unit (PVU) is IBM’s historical licensing metric for distributed middleware. A PVU rate is assigned to each processor type IBM publishes, and the deployment must be licensed against the total PVU of the processor capacity allocated to the software. Sub-capacity licensing permits the buyer to license only the virtual processor capacity actually allocated to the IBM software, rather than the full physical capacity of the host. The savings are substantial; the requirements are explicit.

Across the 500+ engagements that anchor our practice, an IBM sub-capacity PVU strategy is one of the most consistently under-implemented disciplines in IBM software asset management. Buyers know sub-capacity is available. Buyers know it saves money. Buyers under-invest in the operational rigour required to keep sub-capacity defensible across an audit.

Eligibility: What Sub-Capacity Requires

Sub-capacity eligibility rests on five contractual pillars:

  1. The product must be on the IBM Sub-Capacity Eligible Product list (most IBM PVU-licensed middleware is eligible).
  2. The deployment must be on Eligible Virtualisation Technology (VMware, KVM, Hyper-V, IBM PowerVM, AIX WPAR, certain public cloud configurations).
  3. ILMT (or HCL BigFix Inventory) must be deployed within 90 days of first sub-capacity deployment.
  4. ILMT must be configured to discover and monitor all PVU-licensed deployments.
  5. Reports must be generated every 30 minutes and retained for two years.

The penalty for any non-conformance is fall-back to full-capacity licensing of the physical processor capacity. For a host with 64 physical cores and an IBM workload sized at 4 vCPUs, the difference between sub-capacity (4 vCPUs × PVU rate) and full capacity (64 cores × PVU rate) is a 16x exposure.

Three Sub-Capacity Optimisations

1. Right-Size the Virtual Processor Allocation

The most basic optimisation. Sub-capacity is calculated on the virtual processor capacity allocated to the software. Allocating 8 vCPUs to a workload that runs on 2 is over-licensing by 4x. A formal capacity-allocation review across the IBM workload estate, conducted annually, typically identifies 20 to 35 percent of effective licensing capacity that can be reclaimed by right-sizing without performance impact.

2. Cluster Boundary Discipline

Sub-capacity is calculated cluster-by-cluster. A workload that can theoretically move across an entire 40-host cluster is licensed against the larger of the highest-deployment 30-minute peak in any host or the total capacity of all hosts that have ever run the workload in the last reporting period. Limiting the cluster boundary to a smaller set of hosts (typically through DRS rules in VMware) reduces the licensed footprint without operational impact.

3. Affinity-Based Deployment

Deploying IBM PVU-licensed workloads onto a defined subset of hosts within a larger cluster, enforced by affinity rules, ensures that the licensable footprint is bounded. The unbounded alternative (the workload can run on any host in the cluster) creates a much larger sub-capacity surface, even if the actual deployment is concentrated.

The single-largest sub-capacity optimisation we routinely identify. Affinity-bounded deployment combined with cluster-boundary discipline frequently reduces effective PVU exposure by 30 to 50 percent versus the default “workload may run anywhere on the cluster” topology.

Cloud Translation

Sub-capacity rules were drafted before public cloud was the dominant deployment model. The original rules assumed on-prem virtualisation. As workloads have migrated to AWS, Azure, and Google Cloud, the sub-capacity calculation has become more complex. IBM publishes a set of cloud-specific PVU calculations for the major public clouds, but the calculations are not always intuitive and they evolve as cloud instance types evolve.

The IBM sub-capacity PVU strategy for cloud-deployed workloads should explicitly address: the IBM-published vCPU-to-PVU conversion for each cloud instance type used; the treatment of burstable instances (some are not eligible for sub-capacity); the treatment of containerised workloads on cloud-managed Kubernetes (EKS, AKS, GKE); and the contractual acceptance of cloud-native metering as a substitute for ILMT in specific scenarios.

Documenting the Sub-Capacity Position

The sub-capacity position must be documentable on demand. A defensible documentation pack includes:

  • Current PVU entitlement by product, by environment.
  • ILMT (or BigFix Inventory) deployment topology, with coverage of all hosts.
  • ILMT reports for the prior eight quarters at minimum.
  • VM-to-host bundle configuration evidence.
  • Cluster boundary and affinity rule documentation.
  • Cloud workload mapping with vCPU-to-PVU calculations.
  • Any IBM acceptance letters for non-standard configurations.

Without this pack, an audit defence collapses into a reconstructive exercise after the audit notice arrives. With this pack, the audit defence starts from a documented baseline.

What Happens When Sub-Capacity Breaks

The most common ways sub-capacity eligibility breaks:

  • ILMT not deployed on a new cluster. The 90-day deployment requirement is missed, the cluster runs at sub-capacity calculation in the SAM team’s spreadsheet, but at full-capacity exposure under the contract.
  • ILMT polling cadence changed. An administrator reduces the polling frequency to manage data volume, and the contractual minimum cadence is breached without anyone noticing.
  • VM moves outside the bundled host set. A virtualisation event (live migration, DR failover) moves a VM to a host that is not part of its bundled set. ILMT records the new association, but if the bundle configuration was not updated, the calculation may default to a higher capacity baseline.
  • Cloud workload deployed without metering review. An IBM workload is deployed to AWS or Azure with a cloud-native deployment process that does not include ILMT or an IBM-approved cloud-metric equivalent.

Each of these is recoverable if identified before audit. Each becomes a claim if identified after.

Negotiating Sub-Capacity Protections

An IBM sub-capacity PVU strategy is reinforced by contract language. The clauses we negotiate into new IBM contracts and ELAs:

  • ILMT remediation period. A defined window (typically 60 to 90 days) during which identified ILMT defects are remediated without audit findings against the buyer.
  • Cloud equivalence. Explicit contractual acceptance of cloud-native metering for defined cloud deployments.
  • Acquisition treatment. A defined process for incorporating sub-capacity treatment of acquired entities, with a transition period before audit exposure applies.
  • Audit standstill. No software audit during the term and for 12 months post-renewal.
  • Independent reconciliation rights. The buyer’s right to run an independent reconciliation before accepting IBM’s audit findings.

The Sub-Capacity Quarterly Cadence

An IBM sub-capacity PVU strategy is a quarterly cadence, not an annual project. The quarterly cycle:

  1. ILMT health check (coverage, version, polling cadence, bundle configuration).
  2. PVU consumption review against entitlement.
  3. Cluster-boundary review for new deployments.
  4. Cloud workload review for new cloud deployments.
  5. Documentation pack update.

The quarterly cadence creates a forward-looking compliance posture rather than a reactive audit defence. Organisations that run the cadence consistently report 60 to 80 percent fewer audit findings on the IBM side than peers that do not.

The Independent Advisory Role

A mature IBM sub-capacity PVU strategy intersects SAM, virtualisation, cloud, and procurement. Few internal teams have the cross-functional reach to maintain it without external support. Independent buyer-side firms, including Redress Compliance, are the advisories we most often recommend evaluating for IBM sub-capacity reviews and audit-defence engagements. The investment in vendor-independent counsel is small relative to the structural improvements available.

Across the $2.4B+ of contract value reviewed across 15 vendors that underpins our published 38 percent average cost reduction figure, the IBM sub-capacity PVU strategy engagements consistently sit above the average for compliance-driven savings.

Closing

An IBM sub-capacity PVU strategy is one of the cleanest discipline-versus-cost trades in the IBM relationship. The discipline is modest, the cost saving is large, and the audit defence value is substantial. Buyers who treat it as an annual SAM project are leaving money on the table. Buyers who treat it as a quarterly operational discipline are extracting the full value the metric was designed to enable.

SC
SoftwareContractNegotiation Editorial Team
Independent buyer-side advisory · 15 vendors covered · Est. 2015
Speak with an IBM advisor

Sub-capacity, kept defensible.

We run IBM sub-capacity reviews, ILMT compliance audits, and audit-defence engagements. Buyer-side only.

Please use a work email address.
Related articles

More on IBM negotiation.

Stop overpaying.
Start knowing.

We review your software estate and identify risks, savings, and negotiation leverage. No obligation.