IBM sub capacity licensing and ILMT, the conditional discount
Sub capacity is the right to license IBM software to the virtual cores it uses instead of the full physical host. The right is conditional on the License Metric Tool being deployed, scanning, and reported, and when the condition breaks, IBM bills the whole host. The gap between the two numbers is the largest avoidable finding in IBM audits.
Prepared by Redress Compliance · August 6, 2026 · IBM licensing advisory. Based on 15 to 25 audits and reviews supported 2024 to 2026.
Executive summary
For core based IBM products, PVU and its siblings, sub capacity licensing counts the virtual cores the product can use; full capacity counts every core in the physical host.
On a consolidated virtualization estate the difference is routinely 4 to 8 times, which makes sub capacity the single most valuable right in the IBM contract, and the most fragile.
The right is conditional, and the conditions are operational, not contractual: the IBM License Metric Tool installed within 90 days of the first sub capacity eligible deployment, scanning the estate on its half hour cycle, with quarterly reports generated and retained for two years.
Miss any leg and the fallback is automatic: IBM prices the host at full capacity, for the whole period the condition was broken.
The failure is rarely total absence.
Across the IBM audits and reviews we supported, ILMT was deployed but not scanning every host in 1 estate out of 3, creating partial exposure nobody had priced, and quarterly reports existed but had not been retained in 2 estates out of 5.
Breaking the audit trail that proves the discount was ever earned.
The boundary is moving. Containerized and Cloud Pak deployments meter on Virtual Processor Cores through the IBM License Service, because ILMT cannot see inside Kubernetes.
Estates that modernized workloads without extending measurement have quietly recreated the missing tool problem on a platform where the audit playbook is newer and the counting rules are stricter.
How sub capacity actually works
The PVU metric assigns a value per core by processor type, and a product's license requirement is the sum across the cores it can use. Full capacity sums every core in the physical machine.
Sub capacity sums only the virtual cores allocated to the product, capped at the physical host, and on modern consolidation ratios that cap is where the saving lives. The counting mechanics per metric sit in the PVU sub capacity guide.
| Counting basis | What is licensed | When it applies |
|---|---|---|
| Sub capacity | The virtual cores allocated to the product, measured at peak within each quarter | Only while every eligibility condition holds: tool, scanning, reporting, retention |
| Full capacity | Every physical core in the host, regardless of what the product touches | The automatic fallback whenever a condition breaks, applied to the whole broken period |
| Container licensing, VPC | Virtual Processor Cores metered by the IBM License Service | Cloud Paks and containerized deployments, where ILMT cannot measure |
Full capacity is not a penalty clause, it is the default. The contract grants sub capacity as an exception you must continuously earn.
That framing decides audits: IBM does not have to prove you owe full capacity, you have to prove you earned the discount, quarter by quarter, with reports you still possess.
The ILMT conditions, all four legs at once
Eligibility is a chain, and the chain is only as strong as its weakest quarter:
- Installed in time. ILMT must be deployed within 90 days of the first sub capacity eligible deployment. A tool installed late earns the discount from installation forward, not backward.
- Scanning everything. The agent must cover every host running PVU products, on the tool's half hour scan cycle. Every unscanned host is a full capacity host, whatever the rest of the estate does.
- Reported quarterly. Reports must be generated at least every quarter. The report is what converts scan data into an auditable license position.
- Retained for two years. The reports must exist when the audit arrives. Generation without retention earns nothing, and in 2 of 5 estates we reviewed that is exactly what had happened.
A narrow manual reporting exception exists for the smallest estates, but for any enterprise seriously virtualizing IBM software the practical rule is absolute: ILMT everywhere, always current, always archived. The tool is free; the discipline is the price of the discount.
The IBM audit defense playbook
The complete defense sequence: the ILMT health check, the sub capacity evidence pack, the full capacity counterarguments, and the settlement structures that close IBM claims.
Get the white paper →The audit arithmetic, why this finding leads every IBM claim
IBM audits, typically executed by third party firms on IBM's behalf, open with the ILMT question because it is the highest yield finding available: it converts a compliant looking estate into a full capacity assessment without proving a single over deployment.
A product using 8 virtual cores on a 64 core host reprices from 8 cores to 64 the moment the tool coverage fails, and the assessment reaches back across the whole unproven period.
In our engagement file, hosts running PVU products without ILMT coverage were assessed at 4 to 8 times real consumption, and the partial coverage estates were the expensive surprises: the tool was deployed, dashboards were green.
And a third of hosts were silently outside the scan scope through agent failures, network segmentation, or new clusters nobody registered.
The claims stack from there: back license fees at full capacity, plus back support at roughly 20 percent per year on those fees. The audit penalties guide works the full claim construction, and the audit defense playbook covers the response sequence once a letter arrives.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
The container boundary, where ILMT cannot follow
Cloud Paks and containerized IBM software meter on the Virtual Processor Core metric, measured by the IBM License Service running inside the cluster, because ILMT cannot see Kubernetes workloads.
The sub capacity logic is the same, license to what the workload uses, but the tooling, the reports, and the audit trail are a parallel system with its own deployment and retention duties.
The modernization trap follows directly: an estate that moves WebSphere or Db2 workloads into containers has not escaped the measurement obligation, it has doubled it. ILMT keeps covering the VM estate, the License Service must cover the clusters, and the quarterly evidence pack now has two sources.
The Cloud Pak licensing guide covers the VPC mechanics and the ratios that govern Cloud Pak entitlements, and the Red Hat integration analysis explains how OpenShift sits underneath it all.
What we saw across IBM engagements, 2024 to 2026
Across roughly 15 to 25 IBM audits and reviews Morten Andersen and the Redress team supported between 2024 and 2026, missing or broken ILMT was the most expensive single finding, ahead of every genuine over deployment:
Hosts running PVU products without tool coverage were assessed at the whole physical machine, a large multiple of actual consumption.
ILMT deployed but not scanning every host, through agent failures, segmentation, and unregistered clusters. Green dashboards, broken eligibility.
The pattern behind the pattern was ownership: the tool belonged to nobody. It was installed by a project, inherited by no team, and discovered broken by an audit.
The estates that fared best treated ILMT output as a quarterly financial control, reviewed with the same discipline as the invoices it protects, because commercially that is exactly what it is.
Your first five moves
- Reconcile scan coverage against the deployment inventory quarterly. Every host running a PVU product, matched to a reporting ILMT agent. The delta is your full capacity exposure.
- Archive the quarterly reports for two years, somewhere an audit can reach. Generation without retention earns nothing, and 2 in 5 estates we reviewed learned that from a letter.
- Extend measurement to the clusters. Deploy the IBM License Service wherever Cloud Paks and containerized products run; ILMT does not see them and the discount rules apply there too.
- Assign the tool an owner with a financial mandate, not just an operational one. ILMT is a discount control worth multiples of its running cost.
- Price your own full capacity exposure before IBM does. Run the worst case math on every coverage gap, fix the cheap ones, and take the evidence pack into any audit or renewal. The IBM practice and the IBM assessment tools run the reconciliation with you.
Frequently asked questions
What is IBM sub capacity licensing?
The right to license core based IBM products, PVU, RVU MAPC, and VPC metrics, to the virtual cores the product can use rather than every core in the physical host.
On consolidated virtualization estates the difference runs 4 to 8 times, which is why eligibility discipline is worth more than most negotiated discounts.
Is ILMT mandatory for sub capacity licensing?
Effectively yes. Sub capacity eligibility requires the IBM License Metric Tool installed within 90 days of the first eligible deployment, scanning every relevant host, with quarterly reports generated and retained for two years.
A narrow manual exception exists for the smallest estates, but enterprise virtualization without ILMT is full capacity exposure.
What happens if ILMT is missing or broken during an IBM audit?
The affected hosts reprice at full capacity, every physical core, for the period coverage cannot be proven, with back support layered on top at roughly 20 percent per year.
In our engagements that assessment ran 4 to 8 times real consumption, and partial coverage, one in three estates, was priced the same way per uncovered host.
Can we install ILMT after the fact to fix exposure?
Installation fixes the future, not the past. A remediation window exists to deploy the tool, but sub capacity applies from when eligibility is actually met, so the broken period remains exposed.
The practical move is to install immediately, then negotiate the historical layer, which trades far better alongside a demonstrably fixed control.
How does sub capacity work for containers and Cloud Paks?
Through the Virtual Processor Core metric, measured by the IBM License Service deployed inside the cluster, because ILMT cannot see Kubernetes workloads. The same evidence discipline applies: deployment, quarterly reporting, and retention.
Estates that containerized without extending measurement have recreated the missing tool problem on a newer platform.
How often should ILMT reports be generated and kept?
At least quarterly, retained for two years, and reconciled against the deployment inventory each cycle so unscanned hosts surface before an audit finds them.
In 2 of 5 estates we reviewed, reports had been generated but not retained, which breaks the audit trail as thoroughly as never running the tool.
