IBM Sub-Capacity Licensing Rules

IBM sub-capacity licensing lets you license the virtual cores a product is allocated rather than the full physical capacity of the host, which on a modern virtualized server cuts the licensable core count by two to four times, but the right is conditional on running the IBM License Metric Tool to a strict standard, and a single lapse forfeits it retroactively. Sub-capacity is the most valuable cost control in the IBM PVU and VPC world, and the easiest to lose through an administrative gap.

This guide explains the sub-capacity rules, the ILMT requirements that protect them, and how to keep the right at audit. It pairs with our IBM licensing complete guide, the IBM PVU licensing analysis, and the firm's IBM advisory practice.

What sub-capacity means

Full capacity, IBM's default, counts every physical core in the server a product could run on, regardless of how few the product actually uses. Sub-capacity instead counts only the virtual cores allocated to the product, so a product confined to four virtual cores on a thirty-two-core host is licensed for four, not thirty-two. On consolidated, virtualized infrastructure the difference is large, which is why sub-capacity is the single biggest lever on a PVU or VPC bill.

The principle is that you pay for the capacity the product is allocated rather than the capacity it happens to sit on, which aligns the license to the deployment. The catch is that IBM grants this only when the buyer proves the allocation with the IBM License Metric Tool, because without continuous measurement IBM cannot verify the virtual-core count and reverts to the physical total. The measurement requirement is the price of the saving, and our IBM advisory team verifies it on every sub-capacity estate.

The ILMT requirements are strict

Sub-capacity eligibility depends on the IBM License Metric Tool, and the rules are specific and unforgiving. ILMT must be installed within 90 days of the first sub-capacity-eligible deployment, it must scan the environment for the relevant capacity data at least every 30 minutes, it must generate quarterly subcapacity reports, and those reports must be retained for at least two years. Each of these is a condition of the right, not a guideline.

A buyer who deploys sub-capacity but misses any of these conditions can lose the right for the affected period, and an audit will recount that period at full capacity. The discipline is to treat ILMT as a continuous compliance obligation with named ownership, not a tool installed once and forgotten, the same discipline detailed in our IBM ILMT and ILMT configuration guides.

Eligible technology and approved virtualization

Sub-capacity is available only on approved virtualization technologies, and IBM publishes a list of eligible processor technologies and virtualization environments that qualify. A product running on an unapproved virtualization layer does not qualify for sub-capacity even with ILMT, and is counted at full capacity. Before relying on sub-capacity, the buyer confirms that the hypervisor and processor technology are on IBM's eligible list.

This matters when infrastructure changes, because a migration to a new hypervisor or a new processor technology can move a deployment off the eligible list and silently revert it to full capacity. The check belongs in any infrastructure change that touches a sub-capacity-licensed product, alongside the ILMT scope update, so that a virtualization decision does not unknowingly forfeit the sub-capacity right. Our advisors fold this check into every infrastructure and migration review.

Sub-capacity under VPC and Cloud Paks

The sub-capacity principle carries into the Virtual Processor Core metric and into Cloud Paks, where you license the virtual cores allocated to the entitlement rather than the full host. The same dependence on accurate measurement applies, and for Cloud Paks the VPC pool is counted against the allocated cores across the included components. A buyer running Cloud Paks must track the VPC allocation as carefully as a PVU buyer tracks ILMT, because the pool is sized to the measured allocation.

The interaction between sub-capacity counting and the Cloud Pak entitlement model is covered in our Cloud Paks licensing guide, and the principle is consistent: you pay for allocated virtual capacity, and you must measure and prove the allocation. Whether the product is on PVU, VPC, or inside a Cloud Pak, the measured allocation is the count, and accurate measurement is the saving.

Sub-capacity at audit

Sub-capacity is where most IBM audit claims originate, because it is the right most easily lost and the one IBM most readily challenges. An auditor confronted with incomplete ILMT reports, hosts outside the scan scope, or a gap in the retention period will recount the affected deployments at full capacity, and the resulting claim can reach several times the genuine entitlement. The defense is the evidence: continuous, complete, retained ILMT reports covering the audited period.

A buyer who has maintained ILMT to standard walks into the audit with the sub-capacity position already proven, while one with gaps spends the audit trying to reconstruct a position that should have been documented. The link between ILMT discipline and audit outcomes is direct and detailed in our IBM license audit guide, and it is the reason sub-capacity maintenance is an audit defense, not just a cost control.

Carrying the sub-capacity saving into the renewal

The sub-capacity saving is realized in the count, but it only holds in the contract when the renewal is negotiated on the sub-capacity position rather than the full-capacity default. A renewal that quotes against full capacity, or against an unverified count, can carry forward a larger entitlement than the maintained sub-capacity position justifies. The buyer brings the verified sub-capacity count to the renewal as the basis for the entitlement.

A buyer arriving with clean ILMT reports and a documented sub-capacity count negotiates the renewal on the smaller, proven number, while one without that evidence negotiates on whatever IBM asserts. The verified count is bargaining power, the same way a consolidated footprint is, and it is what our IBM negotiation team takes into the renewal on the runway logic of our IBM renewal strategy guide.

Sub-capacity on distributed and the mainframe

The sub-capacity rules described here apply to distributed deployments tracked by ILMT, while the mainframe environment follows its own capacity-based licensing models with different mechanics. An organization running IBM software on both distributed and mainframe platforms has to apply the correct model to each, because the ILMT-based sub-capacity discipline that governs the distributed estate does not transfer directly to the mainframe. Treating both as one problem leads to misapplied rules and either overspend or audit exposure.

The control is to separate the two environments and manage each under its own model, applying the ILMT and eligible-virtualization discipline to the distributed estate and the appropriate mainframe capacity models to z/OS workloads. Each environment is optimized on its own terms, and the sub-capacity saving on the distributed side is realized through the ILMT rigor covered throughout this guide. Keeping the platforms distinct prevents the common error of generalizing one model across both.

Infrastructure change and re-validation

Sub-capacity eligibility is not a one-time grant, it is a state that has to be re-validated whenever the infrastructure changes, because a migration, a hypervisor upgrade, or a new host can move a deployment outside the eligible technology list or outside the ILMT scan scope. A change that improves the infrastructure can silently forfeit the sub-capacity right if the ILMT coverage and the eligibility are not updated alongside it. The most common cause of a lost sub-capacity position is an infrastructure change that nobody mapped to the licensing.

The discipline is to treat every infrastructure change that touches a sub-capacity-licensed product as a licensing event, with a checklist that confirms the new environment is on the eligible list, that ILMT covers the new hosts, and that the reports continue without a gap. Folding the licensing check into the change process, rather than discovering the gap at audit, is what keeps the sub-capacity saving intact through the life of the estate. This is the same change-control discipline our advisors build into every IBM infrastructure review.

Naming an owner for ILMT

The most reliable predictor of whether a sub-capacity position survives an audit is whether a named person owns ILMT, because the tool fails silently when responsibility is diffuse. An organization where ILMT is everyone's job and no one's job is the organization that discovers, at audit, that the scans stopped, a host fell out of scope, or the reports were never retained. Clear ownership is the operational control that makes the technical requirement hold.

The practice is to assign ILMT to a named owner with a defined cadence: verify coverage, confirm report generation, reconcile against the deployment, and retain the output. This turns sub-capacity from a hope into a maintained state, and it is the cheapest insurance available against a full-capacity recount. Our advisors confirm the ownership and the cadence on every sub-capacity estate, because the saving is only as durable as the discipline that maintains the evidence behind it.

Sustaining the position across the estate

Sub-capacity is sustained at the estate level by treating ILMT compliance, eligible-virtualization checks, and infrastructure change control as one continuous discipline rather than three separate tasks. The organizations that never lose a sub-capacity recount are the ones where every new deployment, every hypervisor change, and every host addition automatically triggers the licensing checks, so a gap never opens. This continuous posture is far cheaper than the periodic firefighting that follows a lost position, and it is the standing discipline our advisors install so the saving holds term after term rather than being rebuilt under audit pressure each time.

The bottom line

IBM sub-capacity licensing cuts the licensable core count by two to four times versus full capacity, but the right depends on running ILMT to a strict standard: installed within 90 days, scanning every 30 minutes, quarterly reports retained for two years. Verify ILMT coverage on a schedule, confirm eligible virtualization, track the VPC and Cloud Pak allocation, and bring the proven count to both the audit and the renewal. A single lapse forfeits the saving retroactively. Our advisors protect and negotiate sub-capacity positions across the IBM portfolio and the firm's licensing advisory practice.