IBM ILMT: Everything You Need to Know.

Why ILMT exists.

The IBM License Metric Tool, ILMT, is the only IBM authorised mechanism by which a customer can claim sub capacity licensing rights on PVU metric products. Without a correctly configured ILMT deployment, an IBM product that is otherwise eligible for sub capacity falls back to full capacity, which can multiply the licence requirement by a factor of five to ten on a typical virtualised host. ILMT is therefore not an optional reporting tool. It is the legal evidence required to claim the sub capacity discount built into Passport Advantage pricing.

This guide is written from the buyer side, by independent advisors. We are not an IBM Business Partner, reseller, or affiliate. We do not earn revenue from any IBM product line. The view that follows reflects the buyer side interest only. For the underlying licensing programme, see the IBM Licensing Complete Guide. For the sub capacity programme that ILMT supports, see Sub Capacity Explained. For the operational expertise practice, see the ILMT expertise page.

A short history of ILMT.

ILMT was introduced in 2007 as the operational engine of the IBM sub capacity programme. The mechanism is straightforward in principle. ILMT scans virtualised hosts on a continuous cycle. It identifies which IBM products are installed, which processors and cores are allocated to which virtual machines, and what the highest concurrent virtual core allocation was in each measurement period. The customer reports the peak as the licence requirement. The customer retains the report for two years. IBM audits the report on demand.

In practice the simple principle has produced a long list of operational failure modes. ILMT versions have evolved across major releases, the scanner methodology has changed several times, the bundle file mechanism that identifies products has changed semantics, and the supported virtualisation environments have expanded with each release. A customer that deployed ILMT in 2014 and has not actively maintained it is almost certainly out of sub capacity compliance today. The remediation cost is real but bounded; the audit cost of unremediated drift is much larger.

ILMT architecture.

ILMT runs on a central server with an underlying Db2 database, scanner agents deployed on each virtualised host or container host, and a regular bundle file refresh that tells the scanner which signatures correspond to which IBM products. The architecture is straightforward but the operational discipline required to keep all three components healthy across thousands of hosts is non trivial.

Central server.

The central server runs the ILMT application, hosts the Db2 database, and produces the audit reports. The server itself is licensed at no charge for IBM customers who run it solely for the purpose of sub capacity reporting. Sizing of the central server is documented in the ILMT product documentation and scales with the agent count.

Scanner agents.

Scanner agents run on each managed host. There are two architectural choices. The IBM BigFix agent, which provides scanner functionality alongside its broader endpoint management capability, is the recommended choice for any customer that has BigFix in operation. The standalone ILMT agent is the choice for customers who do not run BigFix. Either path delivers identical sub capacity evidence.

Bundle file.

The bundle file is the catalogue that maps signatures to products. IBM publishes bundle file updates approximately every two weeks. The customer is required to apply the bundle file updates promptly. Stale bundle files produce two failure modes. First, newly licensed products may not be detected at all. Second, product editions may be misclassified, producing under or over reporting.

Deployment in practice.

ILMT deployment is sequenced in four phases. Sizing and architecture, central server installation, agent rollout, and ongoing operations. The sequence is straightforward; the discipline required at each phase is the determinant of long term reliability.

Phase one. Sizing and architecture.

Inventory all virtualised hosts that contain or might contain IBM PVU metric products. The list will be longer than the SAM team expects because dynamic infrastructure frequently spins up IBM workloads in environments that were not initially listed. The buyer side discipline is to scope wider than necessary and trim during agent rollout, not the reverse.

Phase two. Central server installation.

The central server installation is the simplest part. The Db2 database, the ILMT application, and the bundle file scheduler are stood up. The architectural choice between BigFix and standalone is locked at this phase. The central server must be backed up and the backup must be tested.

Phase three. Agent rollout.

Agent rollout is where most ILMT projects stumble. The discipline is to deploy agents on every host that has, or might have, an IBM PVU metric product. The buyer side cost is to lose the sub capacity right on any host that does not have an agent. Agent gaps on dynamic infrastructure are the most common cause of audit findings.

Phase four. Operations.

Operations is the perpetual discipline. Bundle file refresh on the published cadence. Scanner health monitoring. Quarterly peak reporting. Two year report retention. Annual end to end audit dry run.

Reporting: what to produce and when.

ILMT produces three reports that matter for sub capacity compliance. The PVU subcapacity report, the Software Inventory report, and the Audit Snapshot. The PVU subcapacity report is the primary sub capacity evidence. It documents the highest concurrent virtual processor core allocation by product across the measurement period. The customer reports this peak as the licence requirement.

Measurement period and peak.

The measurement period in standard sub capacity terms is the quarter. The peak is the highest concurrent allocation at any point in the quarter. The peak is reported, not the average and not the median. A workload that runs at fifty percent allocation for ninety days and spikes to one hundred percent for one hour reports the one hundred percent peak.

Retention.

Reports must be retained for two years. IBM audit can request the reports on demand within the two year window. The retention discipline is therefore archival, not operational. The buyer side practice is to archive each quarterly report to a separate location with documented retention.

The seven common failure modes.

Across hundreds of ILMT engagements we have observed seven repeating failure modes. Each one invalidates sub capacity rights on some portion of the estate. The combined effect can be catastrophic if not actively monitored.

• Stale ILMT version. ILMT support lifecycle is published by IBM. Running an out of support ILMT version invalidates sub capacity claims.
• Bundle file lag. Bundle file older than thirty days produces detection gaps.
• Scanner agent gaps. Hosts with no agent produce no evidence, which means no sub capacity right.
• Misclassified virtualisation environment. ILMT must be configured against the supported virtualisation environment list. Misconfiguration falls back to full capacity.
• Container scan gaps. Containerised IBM workloads require specific scan configuration. The Cloud Pak License Service is the parallel mechanism for some Cloud Pak products. See Cloud Pak expertise.
• Two year retention gap. Reports lost or unretained invalidate sub capacity claims for the lost period.
• End user error in peak reporting. The customer reports the wrong peak from a correct ILMT output.

ILMT optimization opportunities.

A well run ILMT deployment produces optimization opportunities beyond pure compliance. The data ILMT captures is the same data needed for PVU placement modelling, virtualisation rebalancing, and Cloud Pak conversion analysis. The buyer side discipline is to mine ILMT output for these opportunities, not stop at the bare audit evidence.

PVU placement.

ILMT documents the PVU per core ratio of every host in the scan. Placing IBM workloads on hosts with the lowest PVU per core ratio reduces the licence requirement on the same physical capacity. The placement decision is operational, not contractual, but the data that drives it comes from ILMT. See the PVU optimization expertise page.

Cloud Pak conversion.

Cloud Pak conversion analysis requires a deployment inventory in PVU and a target deployment plan in VPC. ILMT is the source of the deployment inventory. The conversion modelling is the planning exercise.

Audit defense baseline.

ILMT output is the foundation of the audit defense baseline self assessment. The customer who runs a quarterly self assessment against ILMT data is materially better prepared for an IBM audit. See the self assessment guide.

Governance: who owns ILMT.

ILMT ownership is the question that determines long term reliability. The three common ownership patterns are SAM led, Infrastructure led, and Cross functional. Each has its trade offs.

SAM led.

Software asset management owns ILMT outright. This is the cleanest accountability model, but only works if SAM has operational access to all virtualised hosts. In practice SAM teams frequently lack the operational rights to deploy agents at the speed dynamic infrastructure requires.

Infrastructure led.

The infrastructure or platform engineering team owns the agent deployment and operations, while SAM owns the report consumption and the audit response. This pattern is operationally robust but requires explicit handoff disciplines.

Cross functional.

A named cross functional ILMT board with representation from SAM, Infrastructure, Procurement, and Security. The board owns the operating model and meets quarterly. This is the most resilient pattern for very large estates.

Where to go next.

For the operational expertise practice, see the ILMT expertise page. For the sub capacity programme that ILMT supports, see Sub Capacity Explained. For the underlying licensing programme, see the IBM Licensing Complete Guide. For audit defense, see the IBM Audit Complete Guide. For the in depth playbook on ILMT deployment, see the ILMT Deployment Playbook.

For a scoped advisory conversation about your ILMT deployment, the contact page is the entry point. A senior advisor responds within 24 hours.