IBM Sub Capacity Licensing and ILMT Compliance Defense
Miss the 90 day ILMT deadline or a quarterly Audit Snapshot, and IBM relicenses your whole virtualized estate at full capacity, often 5 to 10 times the sub capacity position.
Prepared by Redress Compliance · June 2026 · Representative IBM middleware estate (benchmark scenario, not a quote)
Executive Summary
Sub capacity licensing is the difference between paying for the cores your IBM software actually uses and paying for every physical core in the cluster. On dense virtualization that gap runs 50 to 80 percent of the bill. It is also conditional, and the conditions are technical.
IBM grants sub capacity only when you deploy the IBM License Metric Tool (ILMT) within 90 days of the first eligible product going live, generate an Audit Snapshot at least once a quarter, and retain two years of those snapshots. Miss any one condition and IBM is contractually entitled to charge full capacity for the affected period.
The trap most buyers do not see is the vMotion high water mark. An unpinned VMware cluster lets a virtual machine reach every host, so IBM counts every host. In the benchmark estate that rule turns a 1,680 PVU sub capacity position into an 8,960 PVU full capacity claim, a 5.3 times exposure before back support.
This paper covers why ILMT determines defensibility, the VMware, PowerVM and Nutanix rules, how Audit Snapshots and the mainframe SCRT report carry your defense, the cure mechanics when ILMT lapses, and how to hold readiness between audit cycles.
Why does ILMT compliance decide sub capacity defensibility?
Sub capacity is not a discount you buy. It is a measurement right you earn by running IBM's tooling correctly. Full and sub capacity are the same license metric, the Processor Value Unit, applied to two different core counts. Full capacity counts every physical core in the server or cluster. Sub capacity counts only the cores your software can reach.
IBM grants the sub capacity right through the Passport Advantage Virtualization Capacity Licensing terms. Three conditions carry it, and an audit tests all three.
| Condition | What IBM requires | Consequence of a miss |
|---|---|---|
| Deploy ILMT in time | Install and run ILMT within 90 days of the first eligible product going live. | Full capacity for every period before ILMT ran. |
| Generate snapshots | Produce an Audit Snapshot at least every quarter, with fixlets current. | Full capacity for any quarter with no valid snapshot. |
| Retain the record | Keep at least two years of Audit Snapshots and hand them to IBM on request. | IBM reconstructs missing periods at full capacity. |
The first non obvious mechanic lives in that top row. The 90 day clock starts at first deployment, not at the audit notice, and it runs per product family. A team that adds a new PVU licensed product two years after the last ILMT rollout starts a fresh 90 day clock for that product, and few asset teams track it.
Benchmark scenario, not a quote. 24 vCPUs at 70 PVU per core versus 128 physical cores at 70 PVU per core. Source line below.
How do the VMware, PowerVM and Nutanix sub capacity rules differ?
Sub capacity eligibility depends on the virtualization technology and the boundary you can prove. IBM publishes the eligible technologies and reserves the right to remove them, so the list is a moving target you should track through IBM's sub capacity FAQ. The boundary mechanics are what decide your count.
| Technology | Capping boundary | Where buyers lose PVUs |
|---|---|---|
| VMware vSphere | vCPUs allocated to the VM, capped by ILMT, if the VM cannot roam the cluster. | vMotion and DRS let the VM reach every host, so IBM counts every host. |
| IBM PowerVM | Entitled capacity of the shared processor pool and the LPAR. | Uncapped partitions default to the pool or frame maximum, not the desired value. |
| Nutanix AHV | vCPUs of the VM, capped by ILMT, within the eligible technology window. | Falling off the eligible list, or running an ILMT version that cannot scan AHV. |
The second non obvious mechanic is the vMotion high water mark. IBM's rule is explicit: where a VM can move across hosts, you license the most expensive configuration of all servers in the cluster. ILMT measures actual peak, but the contract only honors that measurement when your boundaries are technically enforced.
The third mechanic follows from it. Host affinity and DRS host group rules are not housekeeping, they are the legal boundary of your license. Pin the IBM workload to a defined subset of hosts and you cut the cluster IBM can count, as the chart shows.
Benchmark scenario, not a quote. 128 physical cores unpinned, 64 cores pinned to two hosts, 24 vCPUs measured, all at 70 PVU per core.
How do Audit Snapshots and SCRT reports support audit defense?
Your defense is documentary. In a distributed estate the evidence is the ILMT Audit Snapshot, the signed quarterly report that fixes your PVU peak per product.
On the mainframe the equivalent is the Sub Capacity Reporting Tool (SCRT) report that IBM uses for monthly license charges on z/OS. Both answer one auditor question: what did you run, and can you prove it.
The fourth mechanic is retention as a contract term, not a habit. A clean current snapshot does not cure a missing past one. IBM tests two years of history, so a gap in the snapshot trail lets the auditor reconstruct that window at full capacity even when today's deployment is compliant.
Retain at least two years of Audit Snapshots. Treat a missing quarter as an open exposure, because IBM will price it at full capacity.
Across IBM audits we have defended in 2024 to 2025, disciplined snapshot evidence and parallel remediation routinely resolved claims at roughly a third to under two thirds of the first number.
Snapshots also protect you on processor value. The same core can carry 70, 100 or more PVUs depending on the chip generation, per IBM's PVU table. A snapshot that records the correct processor stops an auditor applying a higher per core value to your estate.
What are the cure mechanics when ILMT fails?
When ILMT lapses, the question is not whether you breached a condition. You did. The question is how much of the lapsed period you can rebuild with defensible evidence before IBM prices it at full capacity.
Where the common advice on an ILMT lapse is wrong
The standard reseller advice is to true up to full capacity the moment a gap appears, or to pre buy entitlements to be safe. We disagree. In the IBM audits Morten Andersen and the Redress team defended in 2024 to 2025, a pre emptive full capacity true up hands IBM the maximum number before reconstruction is attempted.
The buyer side move is a 90 day remediation sprint that rebuilds interim evidence from vCenter, hypervisor logs and inventory, then settles on the measured position. Capitulation is not a defense, it is the auditor's opening offer accepted.
Stabilize and scope
Reinstall or repair ILMT agents, confirm fixlets are current, and map every PVU and VPC licensed product against where it actually runs.
Rebuild the record
Reconstruct the lapsed quarters from hypervisor and vCenter history, enforce host affinity, and generate a clean Audit Snapshot.
Settle on measurement
Present the measured position, contest full capacity periods with interim evidence, and structure any shortfall as a forward subscription.
The fifth mechanic sits in the 2023 Passport Advantage update, which narrowed the manual calculation allowance. ILMT is now effectively mandatory. A spreadsheet only survives where ILMT genuinely cannot scan a technology, and it must be recalculated every quarter, so it is a fallback, not a strategy.
Benchmark scenario, not a quote. 1,680 PVU and 8,960 PVU from the charts above, priced at an illustrative 120 USD per PVU.
| Line | Sub capacity | Full capacity |
|---|---|---|
| PVU required | 1,680 | 8,960 |
| License at 120 USD per PVU | $201,600 | $1,075,200 |
| Annual support at 20 percent | $40,320 | $215,040 |
| Exposure on the license line | $873,600, a 5.3 times multiple | |
How do you maintain ILMT readiness between audit cycles?
Readiness is a quarterly operating rhythm, not an audit week scramble. The estates that defend cleanly treat ILMT as a controlled system with named owners, not a tool someone installed once. Four habits carry it.
- Run and sign the snapshot every quarter. Update fixlets, clear bundling and component errors, then generate and archive the Audit Snapshot before quarter end.
- Govern the cluster boundary. Keep host affinity and DRS host group rules current, and review them whenever the VMware or Nutanix estate changes.
- Watch the eligibility list. Subscribe to IBM notifications so a technology leaving the eligible list does not silently move you to full capacity.
- Track every new PVU product. Each new deployment starts its own 90 day ILMT clock, so onboarding a product is also an ILMT task.
Our recommendation
Treat ILMT as the legal boundary of your IBM spend and govern it like one. Two moves protect the most money for the least effort.
- Lock the boundary before the snapshot. Enforce host affinity and confirm ILMT can scan every eligible technology, so the measured position is the position IBM must accept.
- Defend the lapse, do not concede it. If a gap exists, run the 90 day remediation sprint and settle on measured peak, never on a pre emptive full capacity true up.
We are glad to tie a meaningful part of the fee to delivered value.
Benchmark ranges: Redress Compliance advisory engagement file, 2024 to 2025. The worked estate is a representative benchmark scenario, not a quote, sized for illustration at 120 USD per PVU.
