What Sub-Capacity PVU Licensing Actually Is

IBM sub-capacity PVU licensing allows organisations to license IBM software based on the virtual processor cores (VPCs) allocated to virtual machines, rather than every physical core in the host server. If a server has 32 physical cores but you allocate only 8 cores to the VM running IBM software, you license only those 8 cores. This is the fundamental difference from full-capacity licensing, where you must license all 32 cores.

The math is straightforward but the complexity lies in the metrics. IBM measures this in Processor Value Units (PVUs). Each processor type has a different PVU-per-core multiplier. A POWER8 core costs 120 PVUs, while an x86 core costs 70 PVUs. So an 8-core x86 allocation equals 560 PVUs. This can legitimately reduce your licensing footprint by 60-75 percent compared to licensing the full physical server.

However, sub-capacity licensing is conditional on one non-negotiable requirement: ILMT (IBM License Metric Tool) must be correctly deployed, functioning, and producing quarterly reports that are retained for two years minimum. Without this tool, IBM automatically reverts all calculations to full-capacity licensing. And once you lose sub-capacity rights, you owe retroactive licences for typically the past two years, plus support penalties.

ILMT: The Mandatory Foundation

The IBM License Metric Tool is not optional. It is the enforcement mechanism that proves you are entitled to sub-capacity discounts. ILMT must be deployed on every server running IBM software, not just a sample. It collects data on CPU allocation, usage patterns, and actual virtual processor core assignments.

Here is what the deployment looks like in practice:

  • ILMT agent must be installed on every physical host running virtual machines with IBM software
  • Quarterly data collection and reporting is mandatory (four reports per year minimum)
  • Two-year data retention is mandatory (24 months of raw ILMT data must be kept on hand)
  • Reports must be accurate and complete; missing data on even one server forfeits sub-capacity rights across your entire environment
  • IBM auditors review ILMT logs for consistency, gaps, and evidence of false reporting

The most common failure point is incomplete deployment. Many organisations install ILMT on 90 percent of servers but skip older or test systems. IBM considers this a failure. If data is missing from even one server, you lose sub-capacity for the entire account. This is not a negotiable point during audits.

"Missing ILMT data on even one server forfeits all sub-capacity rights and triggers full-capacity recalculation—potentially 10-20x the cost."

PVU Values Across Processor Types

IBM has published specific PVU rates for different processors. Understanding these is essential because mixing processor types across environments requires careful tracking.

  • POWER8: 120 PVU per core
  • POWER9: 120 PVU per core
  • x86 (Intel/AMD): 70 PVU per core
  • IBM System Z (mainframe): Different metrics entirely (does not use sub-capacity)

The implication is significant: a 16-core POWER server allocation equals 1,920 PVUs, while a 16-core x86 allocation equals only 1,120 PVUs. If you migrate from POWER to x86 infrastructure, your licensing costs typically fall. If you add POWER systems, they rise sharply. Many organisations underestimate this when planning infrastructure refreshes.

The PVU-to-VPC Transition: IBM's Long-Term Strategy

IBM is actively pushing customers away from PVU-based licensing toward Virtual Processor Core (VPC) licensing, primarily through IBM Cloud Paks and containerised deployments. This transition is important to understand because it affects your long-term licensing strategy.

VPC licensing simplifies the model: 1 VPC equals 1 virtual core, regardless of processor type. A POWER8 core and an x86 core both cost the same in VPC terms. This eliminates the POWER premium and creates price transparency.

However, there is no automatic conversion. If you are running IBM software under PVU licenses and want to switch to VPC-based Cloud Paks, you must negotiate a conversion ratio. IBM typically does not offer one-to-one equivalents. You may need to acquire additional VPCs to replace your existing PVU licenses, depending on the workload and vendor mood during Q4 fiscal year (when IBM fiscal year ends and negotiations are most flexible).

For hybrid environments running both traditional IBM software and Cloud Paks, dual tracking is required. You need separate ILMT configurations for each model, and they don't align in cost.

Common Compliance Pitfalls That Trigger Audits

We have completed over 150 IBM sub-capacity assessments, and patterns emerge. Here are the most frequent failures:

ILMT Agent Failures

ILMT agents crash or stop reporting without notice. A server might be missing data for 6 months, and nobody discovers it until audit time. The agent may fail due to storage space issues, permission problems, or simply outdated installation. During an audit, IBM auditors examine agent logs. If the logs show gaps, you lose sub-capacity rights retroactively.

Legacy Operating System Eligibility Loss

IBM periodically removes sub-capacity eligibility for older operating systems. As of 2024, Windows Server 2012 and Red Hat Enterprise Linux 6 lost sub-capacity eligibility. If you are still running these systems with IBM software and reporting sub-capacity metrics via ILMT, you are reporting false data. IBM auditors check this meticulously. You owe retroactive full-capacity licenses plus penalties.

Cloud Deployment Tracking

Many organisations have migrated workloads to AWS, Azure, or Google Cloud. These cloud environments require explicit BYOL (Bring Your Own License) tracking and often fall outside standard ILMT deployment. Without proper BYOL reporting and reconciliation, you are either under-licensed (exposing you to penalties) or over-licensed (wasting budget).

Cloud Pak Double-Licensing Trap

IBM Cloud Paks often bundle Red Hat OpenShift. If your organisation is also running standalone OpenShift clusters outside Cloud Paks, you may be licensing OpenShift twice: once as part of the Cloud Pak subscription and once as an independent product. This is a common mistake that IBM auditors specifically look for because it inflates their audit findings in their favour.

What Happens When IBM Audits Sub-Capacity

IBM conducts sub-capacity audits with intense scrutiny on ILMT data. Here is the typical flow:

  1. IBM requests all ILMT reports for the past two years, monthly or quarterly depending on your agreement
  2. IBM auditors verify that reports cover all servers and that data is continuous with no gaps
  3. They check CPU allocation against actual VPC assignments in your hypervisor (VMware, KVM, etc.)
  4. They verify that all operating systems running IBM software are still eligible for sub-capacity under current IBM policies
  5. They cross-check license counts against your actual deployment
  6. If they find discrepancies, missing data, or ineligible operating systems, they recalculate full-capacity for the entire historical period (typically two years)
  7. They bill retroactive licenses plus support and penalty fees

The financial impact is severe. A typical finding might show that you owe 10-20 times the PVU licenses you thought you needed, backdated 24 months. Support costs are applied retroactively as well. We have seen organisations face six-figure bills from a single audit failure.

Audit Risk Mitigation: The Proactive Approach

The best defence against sub-capacity audit penalties is aggressive proactive management:

  • Complete ILMT deployment: Deploy to 100 percent of servers, not 90 percent. Leave no gaps.
  • Monitor ILMT agent health continuously: Set up alerting for agent failures, storage issues, or reporting gaps.
  • Maintain 24+ months of ILMT data: Archive data securely and verify quarterly that it is retrievable.
  • Validate OS eligibility annually: Check IBM's current support matrix for each operating system version and IBM software version.
  • Reconcile cloud deployments: If you have BYOL workloads in cloud environments, maintain separate tracking and reconcile quarterly against ILMT.
  • Audit OpenShift licensing: If you use Cloud Paks with embedded OpenShift, verify that standalone OpenShift is not being double-licensed.
  • Prepare for audit proactively: Before IBM requests an audit, conduct your own internal audit using the same methodology.

Need expert guidance on IBM sub-capacity compliance?

Our assessments identify gaps before IBM auditors do.
IBM Advisory Services →

Q4 Fiscal Year: Your Best Negotiation Window

IBM's fiscal year ends on December 31. In Q4 (October-December), IBM licensing teams are incentivised to close deals and resolve disputes. If you are facing a sub-capacity audit finding or planning a PVU-to-VPC conversion, Q4 is when IBM is most flexible on conversion ratios, amnesty for historical non-compliance, and multi-year volume discounts.

Do not wait for an audit notice to negotiate. If you suspect sub-capacity gaps, reach out during Q4. IBM's willingness to negotiate drops sharply in Q1 after fiscal year closes.

Moving Forward: Sub-Capacity Best Practices

Sub-capacity PVU licensing works, but only with operational discipline. The model is not forgiving. One missing ILMT agent, one unsupported operating system, one gap in quarterly reporting can cost your organisation tens of thousands in retroactive fees.

The path forward is clear: deploy ILMT completely, monitor continuously, maintain data rigorously, validate eligibility annually, and audit proactively. If you plan to transition to VPC licensing via Cloud Paks, begin that conversation during Q4 when IBM is most negotiable.

Sub-capacity licensing offers genuine cost savings. But those savings evaporate instantly if compliance is compromised. The investment in ILMT deployment and management is trivial compared to the cost of an audit failure.