IBM ILMT Guide: Deploy, Configure and Maintain Sub-Capacity Compliance

What ILMT Actually Is — and Why IBM Requires It

IBM License Metric Tool (ILMT) is a software asset management agent that IBM mandates for any customer wishing to exercise sub-capacity licensing rights on its Passport Advantage products. Sub-capacity licensing allows an organisation to pay only for the processor cores actually allocated to IBM workloads inside a virtualised environment, rather than licensing every physical core on the host server. The savings are substantial — typically 50 to 70 percent below full-capacity cost on large, densely-configured hosts — but IBM extends those savings only on one non-negotiable condition: that the customer continuously and accurately measures those allocations using an IBM-approved tool.

ILMT fulfils that measurement role. It deploys a lightweight agent on every server, virtual machine, LPAR, or cloud instance running IBM software under a PVU or VPC metric, connects to the underlying virtualisation layer to map VM-to-host relationships, and produces standardised sub-capacity audit reports that IBM accepts as evidence of compliant measurement. Without ILMT — or one of the small set of IBM-approved alternatives such as IBM BigFix Inventory or Flexera One with IBM Observability — sub-capacity rights are contractually invalid, regardless of how accurately a customer believes it has tracked its own consumption.

IBM formalised this requirement progressively across multiple Passport Advantage Agreement updates. The 2022 revision extended the mandatory ILMT rule to cover VPC metrics, not just PVU; and from May 2023 onwards IBM removed virtually all remaining exceptions. Understanding this history matters because many enterprises still operate under assumptions formed under the older, more lenient regime — and those assumptions now represent active compliance risk.

The 90-Day Deployment Rule: Your First Critical Deadline

Any new customer deploying IBM software under a sub-capacity-eligible product for the first time must have ILMT running within 90 days of that first installation. This is a contractual deadline, not a recommendation. Customers who miss the 90-day window technically forfeit sub-capacity rights for the period of non-compliance. IBM has the ability to declare that full-capacity charges apply from day one of deployment through to the point where ILMT is correctly operational.

The 90-day rule catches organisations in several predictable scenarios. A development team evaluates an IBM Db2 or WebSphere product under a proof-of-concept engagement and installs it on a virtualised server without notifying the SAM team. By the time procurement becomes aware, three months have elapsed. A cloud migration team spins up IBM workloads on AWS or Azure VMs as part of a lift-and-shift project without adding those cloud instances to the ILMT scope. A merger or acquisition brings in a subsidiary that runs IBM software outside the parent company's ILMT estate — and the clock has already been running.

Each of these scenarios creates a window of exposure. IBM's Compliance and Revenue Recovery team, which manages audit activity, is aware that these transitions create gaps. Audit triggers often follow precisely the moments when new IBM workloads go live — ELA amendments, new product deployments, data centre migrations, and cloud adoption projects all correlate with periods of elevated audit risk.

The practical implication is that ILMT deployment must be embedded into every IBM workload onboarding process as a day-zero task, not an afterthought. The 90-day window is sufficient time to deploy and configure ILMT correctly, but it requires organisational awareness that the clock starts ticking on the first day of eligible product installation.

PVU and VPC: The Two Metrics ILMT Must Track

ILMT must measure consumption in two distinct metrics depending on which IBM products are licensed: Processor Value Units and Virtual Processor Cores. Understanding the difference is important because the PVU-to-VPC transition that IBM conducted from 2020 to 2023 created a category of misconfiguration risk that persists today.

Processor Value Units (PVU)

PVU licensing prices IBM software based on the type and quantity of processor cores it runs on. IBM assigns a PVU value to each processor model — ranging from 70 PVU per core for older x86 chips to 120 PVU per core for high-end IBM POWER processors. Under sub-capacity rules, ILMT measures only the cores actually allocated to the VM running IBM software, not the full physical host. A workload running on 4 vCPUs of a 32-core host with 70 PVU cores requires only 280 PVU rather than 2,240 PVU — a ratio of 8:1 in favour of the customer. That ratio illustrates precisely why sub-capacity discipline matters financially, and why IBM requires rigorous third-party measurement before accepting it.

Virtual Processor Cores (VPC)

IBM began transitioning newer product lines to the VPC metric from around 2020. Under VPC, each virtual processor core allocated to a licensed workload counts as one VPC, regardless of the underlying processor model. The metric is architecturally simpler than PVU but requires the same ILMT-based measurement discipline. As of May 2022 IBM extended the mandatory sub-capacity measurement requirement to cover VPC products, meaning organisations that deployed new IBM products on the VPC metric without ILMT were — in some cases — already non-compliant before becoming aware of the requirement.

The PVU-to-VPC transition created a particular compliance gap for enterprises running hybrid estates where older IBM products remained on PVU while newer deployments moved to VPC. ILMT supports both metrics simultaneously, but the configuration must explicitly cover both product families. Many ILMT estates were originally configured for PVU-only tracking and were never updated to capture VPC consumption when new products were introduced. In an audit, IBM can treat that gap as evidence of non-compliance across the entire VPC portfolio.

Deploying ILMT: Architecture and Coverage Requirements

ILMT operates on a client-server architecture. A central ILMT server collects data from agents deployed on every endpoint in scope. IBM requires that ILMT agents be installed on all servers, VMs, LPARs, or cloud instances where IBM software is running under a sub-capacity-eligible metric. The coverage requirement is absolute — partial coverage is treated as non-coverage for any untracked installation.

What Must Be in Scope

The coverage obligation is broader than most organisations initially assume. IBM's sub-capacity terms explicitly require that ILMT agents cover production environments, development and test environments, quality assurance environments, and disaster recovery environments. There is no carve-out for non-production IBM workloads. An IBM WebSphere instance running in a dev environment at 4 vCPUs on a 32-core host contributes to sub-capacity measurement in the same way a production instance does. IBM audits routinely identify non-production exclusions as one of the most common ILMT coverage gaps.

Virtualisation Layer Integration

One of the most consequential ILMT configuration tasks is integrating the tool with the underlying virtualisation management layer. ILMT must be able to map virtual machines to their physical host servers in order to apply sub-capacity calculations correctly. Without this mapping, ILMT defaults to counting the full physical host capacity for every workload it discovers — which eliminates the sub-capacity benefit entirely.

For VMware environments, ILMT must be connected to vCenter. This requires credentials with sufficient read access to enumerate the VM-to-host topology. For IBM PowerVM environments, ILMT integrates with HMC (Hardware Management Console). For Microsoft Hyper-V, integration with SCVMM or direct Hyper-V host enumeration is required. Public cloud environments — AWS, Azure, and GCP — require specific ILMT configuration to correctly identify VM sizes and map them to PVU or VPC values.

If the virtualisation integration is misconfigured or missing, the resulting ILMT reports will overstate consumption — sometimes dramatically. Some organisations discover this during internal audits; others discover it when IBM provides an audit finding based on incorrectly generated ILMT data.

Approved Alternative Tools

ILMT is not the only tool IBM accepts. As of the 2022 Passport Advantage Agreement, IBM recognises IBM BigFix Inventory, Flexera One with IBM Observability IT Asset Management, and Flexera One IT Asset Management as approved alternatives. These tools produce equivalent sub-capacity reports in the format IBM requires. Organisations that already run BigFix Inventory as their primary SAM platform may find it more operationally efficient to use that tool for ILMT compliance rather than maintaining a parallel ILMT estate. The output requirements — quarterly sub-capacity reports in IBM's standard XML format — are identical regardless of which approved tool is used.

Containers and Cloud Paks: Where ILMT Ends

ILMT is designed for traditional virtualised environments — VMware VMs, IBM LPARs, and cloud VMs. It was not built for containerised workloads running on Kubernetes or OpenShift. IBM Cloud Paks, which bundle containerised IBM software on top of Red Hat OpenShift Container Platform, use a separate compliance instrument: IBM License Service.

IBM License Service runs as a pod within the Kubernetes cluster and continuously measures the vCPU consumption of IBM containerised products in real time. One instance per cluster is required. Without IBM License Service deployed and operational, IBM defaults to licensing the full physical capacity of every node in the cluster — a potentially enormous exposure for large Cloud Pak deployments.

The critical operational implication is that organisations running hybrid estates — some IBM workloads on traditional VMs under PVU or VPC, others on Cloud Pak on OpenShift — must maintain both ILMT and IBM License Service simultaneously. The two tools operate independently and cover different workload types. Neither replaces the other. IBM License Service feeds compliance data for containerised workloads; ILMT covers the traditional VM and LPAR estate. Failing to recognise this creates a compliance blind spot in whichever environment is not covered.

Cloud Pak deployments also carry a well-documented double-licensing risk. IBM Cloud Paks include an entitlement to Red Hat OpenShift Container Platform as part of the bundle. Organisations that licensed OpenShift separately — before or after procuring a Cloud Pak — must verify that their IBM and Red Hat agreements correctly reflect the bundled entitlement. IBM audits have identified double-licensing of OpenShift as a compliance issue in both directions: some organisations are paying twice, others have deployed OpenShift using Cloud Pak entitlements that technically cover only the IBM Cloud Pak workloads, not any additional OpenShift usage beyond those boundaries.

Quarterly Reporting: The Ongoing Obligation

Deploying ILMT is necessary but not sufficient. IBM's sub-capacity terms impose a continuing quarterly reporting obligation that persists for as long as any eligible IBM product is in use. Organisations must generate and archive a sub-capacity audit snapshot at least once per calendar quarter — four times per year minimum. Each snapshot must be retained for a minimum of two years.

The quarterly snapshot is not simply a data export. It is a structured report in IBM's prescribed XML format that captures, for each discovered IBM product, the peak sub-capacity consumption during the measurement period, the hardware and virtualisation topology at the time of measurement, and the ILMT configuration parameters used. IBM's audit team reviews these reports for internal consistency — mismatches between topology data and consumption figures trigger follow-up queries.

The two-year retention requirement exists because IBM audits can cover any period within the statute of limitations for software licence non-compliance, which under most Passport Advantage agreements is three to five years. When IBM initiates an audit, it requests historical ILMT snapshots for the full audit period. Organisations that cannot produce four quarters of snapshots per year for the audit window are treated as unable to substantiate their sub-capacity claims for those periods — effectively conceding full-capacity pricing for quarters where evidence is missing.

What Breaks the Quarterly Cycle

Several operational scenarios disrupt quarterly reporting without the SAM team realising it. ILMT's internal scheduler can lose its configuration after an OS patch or ILMT server upgrade. The vCenter credentials used for virtualisation integration can expire or be rotated without the ILMT configuration being updated, breaking the host-VM topology discovery. Agents installed on VMs that were subsequently decommissioned leave orphan records that inflate the reported scope. New VMs deployed with IBM software after the most recent agent deployment cycle are not automatically added to ILMT's coverage.

Regular ILMT health checks — at minimum before each quarterly snapshot generation — should verify that: all known IBM workloads are present in the ILMT discovery scope; the virtualisation integration is active and returning current topology data; the scheduled snapshot generation is configured and has run successfully within the last quarter; and the output files have been archived in a location that is backed up and accessible independently of the ILMT server itself.

Common ILMT Misconfiguration Traps

IBM audits consistently surface the same categories of ILMT failure. Understanding them helps organisations prioritise where to focus ILMT health assessments.

ILMT and Audit Defence

When IBM initiates an audit — typically via a formal letter from IBM's Compliance and Revenue Recovery group — ILMT data becomes the primary evidence base for your defence. IBM will request export files from ILMT covering the audit period, typically the most recent three to four years. The quality and completeness of those files determines whether sub-capacity claims for each period are accepted or disputed.

A well-maintained ILMT estate provides a strong audit defence position. Complete quarterly snapshots covering the audit period allow the IBM auditor to verify consumption figures independently. Correct virtualisation topology mapping means that sub-capacity calculations are defensible on a host-by-host basis. Current ILMT software versions ensure that the product catalogue rules used to identify IBM software are consistent with IBM's own published licence definitions.

Conversely, an ILMT estate with gaps, stale data, or misconfiguration gives IBM's audit team leverage. IBM can argue — and often does — that any period where ILMT was not correctly configured or where quarterly snapshots are missing should be assessed at full-capacity pricing. In a large enterprise with hundreds of IBM workloads across dozens of hosts, even a single quarter of missing coverage can translate into a significant retrospective charge.

There is an important nuance in how IBM handles ILMT data during audits. IBM's auditors are trained to examine not just whether ILMT was running, but whether it was running correctly. An ILMT deployment that was technically operational but had the vCenter integration broken — resulting in full-host counts for all VMs — does not constitute a valid sub-capacity measurement. IBM will use the incorrectly high figures from such a deployment as the basis for its audit claim, not the lower figures the customer believes were the actual consumption. Organisations that discover this type of misconfiguration mid-audit are in a difficult position, since correcting the configuration prospectively does not retroactively validate the historical reports.

Maintaining ILMT: Software Updates and Product Catalogue Currency

IBM releases ILMT software updates periodically, and these updates are not optional from a compliance perspective. Each major update includes refreshed product catalogue definitions — the data tables ILMT uses to identify which IBM products are installed on each endpoint and which licence metric applies. As IBM changes product names, introduces new products, or modifies bundling rules (for example, adding Cloud Pak entitlements to an existing product family), those changes must be reflected in the ILMT catalogue before the next quarterly snapshot is generated.

Organisations running outdated versions of ILMT risk generating snapshots based on obsolete product definitions. This can cause IBM products to be categorised incorrectly — either misidentified as a different product with a different metric, or missed entirely if the catalogue definition does not include a product that was introduced after the last update. IBM's audit team uses current catalogue definitions to interpret the ILMT data, creating a potential discrepancy between what the customer's outdated ILMT reports show and what IBM's own analysis produces.

IBM provides update notifications via the My Notifications subscription service. Every ILMT administrator should subscribe to receive alerts for ILMT software releases and catalogue updates. Major ILMT releases — moving from version 9 to version 9.x, for example — sometimes require database schema migrations that cannot be deferred; running an unsupported ILMT version may result in IBM declining to accept the resulting reports as valid evidence in an audit.

Sub-Capacity Eligibility: What Changed in 2024

IBM introduced eligibility restrictions in 2024 that removed sub-capacity rights for IBM software running on certain older operating system versions. Specifically, IBM removed sub-capacity eligibility for deployments on operating system versions that had reached end-of-support status and were no longer receiving security updates from their vendors. The stated rationale was that unpatched operating systems represent an increased security and compliance risk in IBM's licensing ecosystem.

For organisations still running IBM workloads on older Linux distributions or AIX versions that lost OS vendor support before the 2024 eligibility change, this means that full-capacity licensing applies to those specific workloads. ILMT will continue to report sub-capacity figures for those deployments, but IBM's position is that the reported sub-capacity figures are not contractually valid. Organisations should audit their ILMT estate against the current sub-capacity eligibility matrix and identify any workloads that may have lost eligibility due to OS version restrictions.

ILMT in the Context of IBM ELA Management

For organisations with IBM Enterprise License Agreements, ILMT plays a role that extends beyond individual product compliance. ELA structures typically include annual true-up provisions and, in some cases, true-down rights at renewal. The accuracy of ILMT data directly determines the consumption figures used in both processes.

At true-up, IBM compares the ILMT-reported peak consumption against the licensed entitlement quantities. If ILMT data shows consumption below entitlement, the true-up charge is zero — but if ILMT data is incomplete or incorrect, IBM may challenge the figures and use its own assessment methodology instead. Under IBM's standard audit methodology, a disputed ILMT dataset can result in IBM substituting a full-capacity calculation for any period where ILMT data is considered unreliable.

At ELA renewal, the ILMT consumption history for the preceding agreement period becomes the baseline for renewal scope discussions. Clean, complete, correctly configured ILMT data is one of the strongest commercial assets an organisation can bring into an ELA renewal negotiation. It establishes an indisputable consumption baseline, prevents IBM from inflating scope projections based on estimated rather than measured usage, and supports the argument for true-down rights where consumption has decreased below licensed entitlements.

IBM's fiscal year ends on December 31. Q4 is the optimal period for ELA renewals and the moment when IBM's sales organisation is under the most pressure to close deals. ILMT data that clearly demonstrates entitlement surplus — documented across multiple quarterly snapshots — gives the customer the most leverage at exactly the moment when IBM is most motivated to negotiate.

The Commercial Case for ILMT Excellence

The cost of maintaining ILMT correctly — a skilled SAM administrator's time, the server infrastructure to host ILMT, and the process overhead of quarterly snapshots and two-year archiving — is modest compared with the financial exposure that a poorly maintained ILMT estate creates. To put concrete figures on this: for an organisation running IBM software on 50 virtualised hosts, the difference between sub-capacity and full-capacity pricing can range from £1 million to £5 million annually depending on the products licensed and the virtualisation density. A single year of lost sub-capacity rights due to ILMT non-compliance at that scale would be a material financial event.

IBM's Compliance and Revenue Recovery team operates on a commercial basis. When it identifies customers with ILMT gaps, it presents remediation proposals that include back-maintenance charges and retroactive true-up amounts calibrated to the period of non-compliance. Negotiating those proposals down requires contemporaneous ILMT evidence — which is precisely what an organisation without a complete quarterly archive cannot provide. The negotiating asymmetry is stark: IBM has a contractual position and a methodology; the customer has incomplete data and a retrospective argument.

The practical recommendation from twenty years of supporting IBM-licensed enterprises is straightforward: treat ILMT as business-critical infrastructure. Assign it to a named owner. Budget for its maintenance. Include it in change management processes so that every new IBM workload, every virtualisation migration, and every cloud adoption project automatically triggers an ILMT scope review. The organisations that do this consistently are the ones that arrive at IBM audit or ELA renewal with clean data, a clear picture of their entitlement position, and the leverage to negotiate on their own terms.

Summary: What Every IBM Customer Needs to Know About ILMT

IBM License Metric Tool is the instrument that determines whether your organisation pays sub-capacity or full-capacity prices for IBM software. The difference can be 50 to 70 percent of your IBM software spend. ILMT must be deployed within 90 days of the first eligible product installation, must cover all environments without exception including development and disaster recovery, must be integrated with the virtualisation layer to produce valid host-VM topology mapping, and must generate and archive quarterly snapshots for a minimum of two years.

The PVU-to-VPC transition created ongoing misconfiguration risk. Cloud Pak and containerised IBM workloads require IBM License Service, not ILMT. Sub-capacity eligibility changed in 2024 for workloads on certain OS versions. ILMT software and product catalogue must be kept current. A named administrator and documented quarterly review process are the minimum governance requirements for an ILMT estate that can withstand scrutiny in an IBM audit.

Organisations that treat ILMT as an afterthought pay for it — sometimes years after the fact, when IBM initiates an audit and the historical evidence base is incomplete. Those that invest in maintaining ILMT correctly hold the commercial leverage: clean data, defensible sub-capacity claims, and a credible position at ELA renewal negotiation where IBM's fiscal year ends on December 31 and Q4 pressure creates the best terms available.