IBM ILMT Compliance Guide: Sub-Capacity Licensing Explained

What ILMT Is and Why It Matters

IBM License Metric Tool (ILMT) is a software asset management tool developed and maintained by IBM that automatically discovers and tracks IBM software deployments across virtual and cloud environments. Its purpose, from IBM's perspective, is to provide an auditable record of the PVU (Processor Value Unit) or RVU (Resource Value Unit) consumption used to calculate sub-capacity licence requirements.

The commercial significance of ILMT is substantial. IBM's sub-capacity licensing programme allows organisations to licence software based only on the processing capacity actively available to a virtual machine — not the full physical capacity of the underlying server. For organisations running IBM middleware, databases, or infrastructure software on virtualised infrastructure, the difference between sub-capacity and full-capacity pricing can be enormous. A single IBM WebSphere or Db2 deployment on a large server farm could carry a full-capacity obligation worth hundreds of thousands of pounds more than the equivalent sub-capacity position.

The contractual requirement is clear: to claim sub-capacity pricing, ILMT must be deployed, properly configured, and generating reports at least every 30 days. If you cannot produce ILMT reports covering the period under audit review, IBM's position is that full-capacity pricing applies retroactively. The Software Audit Defense Playbook covers the full audit response process — this article focuses specifically on the ILMT compliance requirements that determine your exposure before an audit begins.

How Sub-Capacity Licensing Works

IBM's PVU-based licensing assigns a PVU value to each processor core based on the processor type and brand. Full-capacity licensing requires you to licence every processor core on every physical server where eligible IBM software could theoretically run. Sub-capacity licensing instead requires you to licence only the virtual processors allocated to the specific virtual machines where IBM software is actually deployed.

The sub-capacity calculation is complex because it must account for peak consumption — the maximum number of virtual processors allocated to IBM software at any point during the reporting period. ILMT tracks this peak across all scanned endpoints and generates a compliance report that documents the maximum observed deployment footprint. The compliance report is the primary document IBM auditors request first when opening an audit of a virtualised environment.

Eligible Virtualisation Technologies

Not all virtualisation technologies qualify for sub-capacity pricing. IBM's eligible virtualisation list has historically been narrower than most organisations assume. Confirmed eligible technologies include IBM PowerVM, IBM z/VM, VMware vSphere (with specific configuration requirements), Microsoft Hyper-V, and KVM. Public cloud environments — AWS, Azure, and GCP — are eligible only under IBM's specific cloud programme terms, which differ from standard sub-capacity rules and require separate analysis.

Organisations running IBM software on non-eligible virtualisation technologies — older Solaris containers, certain Docker configurations, or unsupported hypervisors — are obligated to licence at full capacity regardless of ILMT configuration. This is a common source of unexpected audit exposure when organisations migrate to new container or cloud-native architectures without reviewing IBM licence implications.

Common ILMT Compliance Failures

Based on IT Negotiations' work across IBM licence advisory engagements, the most common ILMT compliance failures fall into three categories: deployment gaps, configuration errors, and reporting failures.

Deployment Gaps

ILMT is not automatically installed on all servers — it requires deliberate deployment to each endpoint that hosts eligible IBM software. Organisations that grow through acquisition, migrate workloads between data centres, or adopt new cloud environments frequently create deployment gaps when new infrastructure is not added to the ILMT programme. The result is that IBM software running on unscanned servers defaults to full-capacity, often without anyone in the IT or procurement team realising the gap exists.

This is particularly acute in private cloud and containerised environments where virtual machines may be created and destroyed rapidly. IBM has taken an aggressive position on container deployments — in many configurations, all cores available to the container host must be licenced at full capacity unless ILMT is deployed and configured to track container resource allocation specifically.

Software Signature Updates

ILMT relies on software signatures to identify and classify IBM products running on scanned endpoints. IBM releases signature updates periodically, and failure to apply these updates means that newer IBM products or product versions may not be correctly detected. An incomplete product catalogue in ILMT produces a compliance report that appears clean but does not accurately represent actual deployment — a position that fails audit scrutiny and may be treated as a deliberate compliance failure by IBM auditors.

30-Day Reporting Cadence

The ILMT report must be generated every 30 days at minimum. Many organisations set up ILMT and generate initial reports but then allow the reporting cadence to lapse — particularly after personnel changes in the SAM or infrastructure team. Months or even years of reporting gaps are not uncommon in IT Negotiations' experience. When IBM auditors request historical ILMT reports as part of an audit, gaps in the reporting archive are treated as periods of full-capacity obligation, often generating the largest single line items in audit findings.

Maintaining Continuous ILMT Compliance

A defensible ILMT position requires more than initial deployment — it requires active programme management. The core elements are: complete endpoint coverage, current software signatures, consistent 30-day reporting, secure report archiving, and integration with change management processes so that infrastructure changes automatically trigger ILMT coverage review.

IBM's licence advisory engagements at IT Negotiations typically begin with an ILMT health check — a structured assessment of the current ILMT deployment scope, reporting history, software catalogue accuracy, and gap analysis. In most environments, this assessment identifies material compliance gaps that can be remediated before any audit. Remediation after an audit starts is significantly more difficult and expensive than prevention.

For organisations that lack internal SAM capability, third-party ILMT managed services are available. These services take ownership of ILMT deployment, signature updates, and monthly reporting. While this adds a cost, it is typically a fraction of the exposure created by a single audit finding arising from an ILMT compliance gap.

ILMT in the Context of an IBM Audit

When IBM initiates an audit, the first formal request is almost always for the ILMT compliance report and supporting documentation. The quality and completeness of your ILMT archive determines the starting position of the audit negotiation. A complete, well-maintained archive puts you in a position to challenge IBM's findings using your own data. An incomplete or absent archive places you in a position where IBM's estimates — typically based on full-capacity assumptions — become the baseline that you must disprove.

The strategic implication is clear: ILMT compliance is not a technical box-ticking exercise. It is a commercial asset that determines your negotiating position in an audit. Organisations that treat ILMT as a routine operational task rather than a strategic compliance investment typically pay significantly more in audit settlements than those that maintain it with discipline. For detailed guidance on the full audit response process, see the Software Audit Defense Playbook and the guidance on IBM PVU sub-capacity optimisation.