IBM ILMT Compliance: Avoiding Sub-Capacity Audit Risks

IBM Processor Value Unit (PVU) licensing has long been one of the most complex — and most audited — licensing models in enterprise software. At its heart, the complexity stems from a fundamental tension: IBM's sub-capacity licensing rules offer significant cost savings for organisations running IBM software on virtualised infrastructure, but those savings are conditional on maintaining IBM License Metric Tool (ILMT) in a state of continuous, documented compliance.

IBM's Software Group audit organisation — known internally as License Compliance — has made ILMT compliance its primary audit focus. In our experience of 500+ engagements, ILMT-related findings account for more than 60% of IBM audit monetary claims. Understanding ILMT is not a technical nicety; it is a business necessity for any organisation with material IBM software investments.

What ILMT Is and Why IBM Requires It

IBM License Metric Tool (ILMT) is IBM's proprietary software asset management tool, designed specifically to track the PVU consumption of IBM software products deployed on virtualised infrastructure. ILMT scans your environment, discovers IBM software installed across physical and virtual servers, identifies the PVU rates applicable to the underlying processor hardware, and generates quarterly compliance reports that document your peak PVU consumption.

IBM's sub-capacity licensing rules state that organisations running IBM software on supported virtualisation technologies — including VMware vSphere, IBM PowerVM, Microsoft Hyper-V, and others — may licence the software based on the virtual processors allocated to the IBM workloads rather than all physical processor cores in the host server. This is the "sub-capacity" benefit, and it can reduce PVU licensing requirements by 60–90% compared to full physical capacity licensing.

IBM Sub-Capacity Licensing Rules Explained

IBM's sub-capacity licensing rules are governed by the IBM International Passport Advantage Agreement and the IBM PVU Licensing Frequently Asked Questions document (updated periodically by IBM's licensing terms team). The key rules are:

Supported Virtualisation Technologies

Sub-capacity licensing is only available for IBM software deployed on virtualisation platforms that appear on IBM's approved virtualisation list. This includes VMware vSphere/ESXi (all current versions), IBM PowerVM (LPAR), Microsoft Hyper-V, Kernel-based Virtual Machine (KVM), and several cloud hypervisors. IBM does not permit sub-capacity licensing on all virtualisation platforms — verify that your hypervisor is on the current approved list before assuming sub-capacity eligibility.

ILMT Deployment Scope

ILMT must be deployed to cover all systems in your environment where IBM software is (or could be) installed. This means: all physical servers, all virtual machines, and all containers running IBM middleware and application software. A common compliance gap: organisations deploy ILMT to cover their known IBM footprint but miss systems in departmental IT, acquired subsidiaries, or cloud environments where IBM software has been installed without central IT awareness.

Quarterly Scan and Report Requirement

IBM's contractual requirement is quarterly scanning — at minimum one scan per quarter that captures peak PVU consumption. In practice, IBM's audit teams look for monthly scans to validate that peak consumption is accurately captured. Quarterly scanning is the minimum; monthly is the defensible practice. Scan records must be retained for a minimum of 2 years, as IBM auditors request historical quarterly reports covering the entire audit period (typically 2–3 years).

Report Archival

Every ILMT scan that generates a compliance report must be archived. IBM auditors will request all quarterly reports for the audit period — typically the past 24–36 months. Missing reports are treated as periods of non-compliance, with full-capacity pricing applied for those quarters.

How PVU Calculations Work: Sub-Capacity vs. Full-Capacity

Understanding the financial stakes requires understanding how PVU calculations work in practice:

*Illustrative; based on IBM DB2 Standard Edition list pricing. Actual impact varies by product and negotiated rate.

The financial exposure from ILMT non-compliance scales rapidly with estate size. For large enterprise environments running IBM WebSphere, DB2, MQ, or Cognos across significant VMware infrastructure, the audit exposure from ILMT gaps can exceed the annual revenue of many mid-sized organisations.

The 7 Most Common ILMT Compliance Failures

1. Incomplete Coverage

ILMT is deployed to cover the IT team's known IBM footprint but misses systems in acquired subsidiaries, departmental data centres, or cloud environments (particularly lift-and-shift IBM workloads moved to AWS, Azure, or GCP). IBM auditors specifically target coverage gaps, as they represent the highest-value findings.

2. Outdated ILMT Version

IBM updates ILMT's software catalogue regularly to reflect new product versions and licence metrics. Running an outdated ILMT version means the tool cannot correctly identify newer IBM software or apply current PVU table rates. IBM auditors reject compliance reports generated by ILMT versions that pre-date significant catalogue updates — rendering those historical scans invalid for sub-capacity purposes.

3. Infrequent Scanning

Many organisations set up ILMT to scan quarterly and forget about it — until an audit triggers a review that reveals months of missed scans. IBM requires that scans be executed, reports generated, and those reports archived. Missed scan periods are treated as non-compliant periods, with full-capacity pricing applied retroactively.

4. VM-to-Host Mapping Errors

ILMT determines PVU consumption by mapping virtual machines to their underlying physical host and applying the PVU rate for that host's processor. Configuration errors in ILMT's discovery scope — particularly in VMware environments with DRS (Distributed Resource Scheduler) enabling VM live migration across hosts with different processor types — can result in incorrect PVU peak calculations. IBM auditors will scrutinise VM-to-host mapping data carefully.

5. Missing IBM Software Discovery

IBM software installed outside of standard enterprise deployment pathways — by developers, business units, or via trial licences that became production usage — often escapes ILMT discovery. Shadow IBM software is a significant audit risk, particularly for IBM Cognos, SPSS, and IBM Cloud Paks deployed without central IT oversight.

6. Retention Failures

ILMT scan reports from more than 18 months ago are often not retained — overwritten by newer scans, deleted during system migrations, or simply not archived properly. When IBM requests 36 months of quarterly reports, missing historical reports create compliance gaps that auditors exploit.

7. Incorrect Virtualisation Tier Assignment

IBM's sub-capacity rules vary by virtualisation tier. Some IBM products have different PVU entitlements depending on whether they are running in a "hard partition" (where the partition cannot access processors outside the partition) versus a "soft partition" (where the VM can be migrated to any host). Incorrect tier assignments in ILMT can under-report or over-report PVU consumption.

How IBM Identifies and Exploits ILMT Gaps

IBM's License Compliance organisation uses several methods to identify organisations with ILMT compliance gaps before initiating formal audits:

• Support portal telemetry: IBM's support portal records product registrations and version downloads, creating a dataset of IBM software in use that auditors compare against reported ILMT inventory
• Hardware registration data: IBM's hardware maintenance databases provide a map of IBM System x and Power servers in your estate, which auditors cross-reference with ILMT scan output
• Passport Advantage entitlement records: IBM's commercial systems contain your purchased entitlements; when internal signals suggest consumption above entitlement, audits follow
• ILMT-generated telemetry: ILMT itself generates anonymised telemetry that IBM receives; patterns suggesting misconfiguration or inadequate scan frequency can trigger audit interest

Building an ILMT Compliance Framework

ILMT Governance Structure

Effective ILMT compliance requires designated ownership, documented procedures, and an audit cadence. In practice, this means: a named IT asset management (ITAM) owner responsible for ILMT operation; a quarterly review process that validates scan completeness against server inventory; and an annual external review (either by your SAM tool vendor or an independent adviser) to validate ILMT output against IBM's current compliance expectations.

Remediation: What to Do If You're Already Non-Compliant

If your current ILMT deployment has known gaps — missed scans, incomplete coverage, outdated versions — the critical question is whether to remediate proactively or wait for an audit. Our strong recommendation is proactive remediation, for two reasons:

First, proactive remediation allows you to control the narrative. When IBM auditors review your ILMT records, they will find a well-maintained, gap-free record set — not a patchwork of remediated data that signals prior non-compliance. Second, remediation after an audit notice has been received changes the commercial dynamics significantly — IBM's audit team views post-notice remediation with scepticism and may not accept it as establishing sub-capacity entitlement for prior periods.

Remediation Steps

1. Immediate ILMT version upgrade: Update to the current ILMT release before taking any new scans
2. Coverage audit: Reconcile ILMT scan scope against your server inventory and cloud asset register; identify and add missing systems
3. Accelerated scanning: Execute daily scans for 30–60 days following remediation to establish a clean, documented baseline
4. Historical gap assessment: Assess whether missing historical scan records can be reconstructed from alternative data sources (server logs, vCenter history, support records)
5. IBM proactive engagement: Consider proactive disclosure of material gaps through an IBM Software Value Plus (SVP) business partner engagement — this preserves your commercial relationship and may limit IBM's retroactive claim period

Frequently Asked Questions