IBM PVU Sub-Capacity Optimization: The ILMT Compliance Guide 2026

IBM's sub-capacity PVU licensing model is one of the most financially significant licensing decisions in the enterprise software world. The difference between correctly implemented sub-capacity licensing and full-capacity licensing for a large IBM estate on modern high-core-count servers can be millions of dollars per year. Yet most enterprise IT teams deploy sub-capacity IBM licensing without adequate assurance that their ILMT implementation would survive an IBM audit — creating enormous risk for apparently large savings.

This article is part of our IBM Software License Negotiation Guide. It covers the technical and commercial mechanics of sub-capacity PVU licensing in detail — who qualifies, what ILMT must do, what virtualization environments are eligible, and how to build a defensible position. For IBM audit defense specifically, see our audit defense advisory and the Audit Defense Guide.

PVU Full Capacity vs. Sub-Capacity: The Basics

IBM licenses its distributed software products using the Processor Value Unit (PVU) metric. Each physical or virtual processor core on which IBM software can run requires a specific number of PVUs depending on the processor type. IBM's PVU table assigns different values to different processor families — IBM Power processors use higher PVU values than x86, reflecting the relative processing power.

Full Capacity Licensing

Under full capacity rules, you must license every physical processor core in any physical server on which IBM software is installed. This applies regardless of how many cores are actually used by IBM software — even if IBM software runs in a single 2-vCPU virtual machine on a 128-core server, full capacity requires licensing all 128 cores (at the appropriate PVU value per core). Full capacity is the default licensing basis and applies whenever sub-capacity eligibility conditions are not met or not maintained.

Sub-Capacity Licensing

Sub-capacity licensing allows IBM software to be licensed based only on the virtual processor cores (vCPUs) allocated to the virtualized environment running IBM software — not the full physical capacity of the host server. This is where the cost savings materialize: on a 128-core server hosting a 4-vCPU VM running IBM Db2, sub-capacity licensing requires 4 PVUs (4 vCPUs × the applicable PVU value) rather than 128 PVUs.

Sub-capacity licensing is optional — it is a right that Passport Advantage customers can exercise, not a default condition. To exercise this right, IBM requires that specific conditions be continuously met, with IBM's License Metric Tool (ILMT) as the primary compliance mechanism.

ILMT: The Mandatory Compliance Requirement

IBM License Metric Tool is the cornerstone of any sub-capacity licensing position. IBM's standard Passport Advantage terms make clear: sub-capacity licensing is only valid while ILMT (or an approved equivalent like BigFix/HCL BigFix Inventory) is deployed, continuously scanning all systems in the sub-capacity environment, and generating reports that document the software deployment and PVU consumption data.

What ILMT Must Do

ILMT's job is to continuously collect software scan data from every system in scope for sub-capacity licensing and produce PVU consumption reports that IBM auditors can review. Specifically, ILMT must:

• Discover all virtualization hosts and virtual machines in the sub-capacity environment via the ILMT agent
• Scan for all IBM software installed on each VM and map installations to specific products and versions
• Record the maximum vCPU count assigned to each VM during each billing period (ILMT tracks peak vCPU allocation, not average)
• Calculate PVU consumption based on vCPU × PVU value for each IBM software product deployed
• Generate quarterly (or more frequent) PVU consumption reports that document the sub-capacity position
• Maintain audit-ready records for the full retention period (IBM typically requires 2 years of ILMT data)

ILMT Agent Deployment Requirements

ILMT agents must be installed on every virtual machine and physical server in the sub-capacity scope — not just the machines running IBM software. IBM's position is that a server hosting both IBM and non-IBM workloads in a virtualized environment requires ILMT visibility across the entire host to accurately determine the maximum vCPU allocation to IBM-running VMs. Gaps in agent deployment — servers or VMs without ILMT agents — convert that host's IBM software to a full-capacity position.

Eligible Virtualization Technologies

Not all virtualization technologies are eligible for IBM sub-capacity licensing. IBM maintains a list of eligible virtualization technologies in the IBM Software License Agreements and sub-capacity licensing documentation. The key distinction is between virtualization technologies that provide "hard partitioning" (guaranteed isolation of processor resources that IBM recognizes as creating a defensible license boundary) and those that provide "soft partitioning" (shared pool virtualization where IBM takes a more conservative position).

Fully Eligible Virtualization Technologies

Technologies with clear sub-capacity eligibility and straightforward ILMT implementation include VMware vSphere/ESXi, Microsoft Hyper-V, Oracle VM Server, Red Hat KVM, and IBM PowerVM (LPAR). For these platforms, ILMT can accurately track vCPU assignments and IBM accepts the sub-capacity position when ILMT data is complete.

Container and Kubernetes Environments

This is where IBM PVU licensing becomes most complex in 2026. As enterprises move IBM software workloads into containers on Kubernetes (particularly on Red Hat OpenShift), the traditional ILMT agent-based model does not directly translate. IBM has introduced specific guidance for containerized IBM software that uses CPU Request and CPU Limit configurations in Kubernetes to define the sub-capacity license position — but the implementation requirements are substantially more complex than traditional VM-based ILMT deployment.

For IBM software deployed in containers, IBM requires that CPU resources be properly controlled using Kubernetes resource quotas and limits, that IBM's Cloud Pak Metering service be deployed alongside ILMT, and that the metering data be integrated into the overall ILMT reporting. Many organizations that have containerized IBM workloads without completing this implementation are unknowingly in full-capacity positions despite believing they have sub-capacity coverage.

Common ILMT Configuration Failures

Based on our experience defending IBM audits, the following ILMT configuration failures account for the majority of sub-capacity compliance issues that IBM auditors find:

Failure 1: Incomplete Host Coverage

The most common issue — ILMT agents are deployed on virtual machines but not on the underlying virtualization hosts. IBM requires visibility into the entire virtualization environment to validate vCPU assignments. Missing agent coverage on even one host in a VMware cluster can invalidate the sub-capacity position for that entire cluster.

Failure 2: ILMT Scan Gaps

ILMT must produce continuous scan data. Gaps in scanning — caused by ILMT server outages, agent connectivity issues, or configuration drift — convert the unscannable period to a full-capacity position. IBM auditors specifically look for periods where scan data is missing or incomplete, as these represent potential underpayment windows. Regular ILMT health monitoring and alert configurations are essential to prevent scan gaps from going undetected.

Failure 3: New Infrastructure Not Added to Scope

As organizations add new servers, VMs, or cloud environments, they frequently fail to add these to ILMT's scan scope in a timely manner. New IBM software deployments on infrastructure not yet in ILMT scope default to full capacity from the deployment date. M&A activity is a particularly high-risk scenario — acquired companies often have IBM software deployments with no ILMT coverage at all.

Failure 4: Incorrect Product Recognition

ILMT's software recognition (based on IBM's software catalog) must correctly identify each IBM product and version deployed. For products with complex bundling — where one license covers multiple sub-products — incorrect product identification in ILMT can result in either under-reporting (audit exposure) or over-reporting (unnecessary compliance actions). IBM regularly updates its software catalog, and organizations running older ILMT versions may have product recognition gaps.

Failure 5: Cloud and Container Environments Not Covered

As noted above, cloud-deployed IBM software in BYOL configurations and containerized IBM workloads require specific ILMT configurations that many organizations have not implemented. This failure is increasingly common as enterprises modernize infrastructure — IBM software originally deployed on-premises is migrated to cloud or containers without corresponding ILMT configuration updates.

Maximizing Sub-Capacity Savings: Infrastructure Strategy

Beyond maintaining ILMT compliance, there are proactive infrastructure strategies that maximize the savings available under sub-capacity licensing.

Consolidate IBM Workloads onto Fewer, Larger Hosts

Sub-capacity licensing savings are greatest when IBM software runs in small vCPU allocations on large physical hosts. Consolidating IBM workloads from multiple smaller servers onto fewer, high-core-count servers — and keeping vCPU allocations at the minimum needed for performance — maximizes the ratio of physical capacity to licensed capacity and reduces PVU spend per workload unit.

Right-Size vCPU Allocations

Because ILMT tracks peak vCPU allocations, over-provisioned virtual machines — VMs allocated more vCPUs than workloads actually use — incur unnecessary PVU costs. IBM vCPU allocations should be reviewed periodically against actual CPU utilization metrics. For IBM databases and middleware, vCPU right-sizing based on observed performance data can reduce PVU counts by 20–40% without impacting application performance.

Use IBM Power with LPAR for High-Intensity IBM Workloads

For organizations with heavy IBM Db2, MQ, or WebSphere deployments, IBM Power systems with dedicated LPAR configurations provide a highly predictable and auditable sub-capacity position. Power LPAR dedicated partitions are recognized by IBM as hard partitions, giving a defensible full-capacity reduction without requiring ILMT in some configurations — though ILMT is still best practice for auditability.

Sub-Capacity Licensing in IBM Negotiations

Sub-capacity optimization is not just a compliance activity — it is a negotiation tool. Organizations that can demonstrate a credible, well-maintained ILMT implementation and an optimized PVU position have significant leverage in IBM Passport Advantage renewals.

Specifically: if your ILMT data shows that your actual sub-capacity PVU consumption is materially lower than your contracted entitlement, you have evidence to support a reduction in your IBM license count at renewal. IBM will resist this — they prefer renewals at flat or growing entitlement levels — but a documented, ILMT-verified reduction in deployed PVUs is a legitimate basis for contract right-sizing.

Conversely, if your ILMT implementation is incomplete and you know IBM software is running in environments not in ILMT scope, you have an audit liability that reduces your negotiating posture. Remediating ILMT gaps before entering any IBM commercial negotiation is therefore both a compliance imperative and a commercial preparation step.

For the full IBM negotiation picture — including Passport Advantage strategy, Red Hat optimization, and Cloud Pak economics — see the IBM Software License Negotiation Guide. For support with your specific PVU or ILMT situation, contact our IBM advisory team or take a free licensing assessment.