Table of Contents
What is ILMT?
ILMT stands for IBM License Metric Tool. It is a free software tool provided by IBM that tracks how much IBM software you are running across your infrastructure and calculates your license consumption in PVU (Processor Value Units). If you run IBM software on virtual machines and want to pay only for what you actually use rather than the full physical capacity of your servers, ILMT is how you prove that to IBM.
Why Does ILMT Exist?
To understand ILMT, you need to understand how IBM licenses its middleware products. Most IBM software sold through Passport Advantage is licensed per processor core, measured in PVUs. The PVU value per core depends on the processor family and, in some cases, how many sockets the server has. A Power10 core is 120 PVU. An Intel Xeon core on a two-socket server is typically 70 PVU, the same core in a four-socket server is 100 PVU, and in an eight-socket server it climbs to 120 PVU. Older multi-core x86 and workstation-class chips are often 50 PVU per core. IBM publishes the official PVU table and ILMT reads it to calculate consumption. You do not do this math by hand, but you need to understand that two servers with the same number of cores can produce different PVU totals.
Here is where it gets interesting. By default, IBM charges you based on the full physical capacity of the server where their software is installed. If you have a physical server with 40 cores and you run WebSphere on a virtual machine with 4 virtual cores, IBM's default position is that you owe licenses for all 40 cores. That is full-capacity licensing, and it is expensive.
IBM introduced sub-capacity licensing to address this. Under sub-capacity terms, you only pay for the virtual cores actually assigned to the VM running IBM software. In our example, that means licensing 4 cores instead of 40. The savings are substantial.
But IBM does not just take your word for it. They need proof that you are only using those 4 cores. That proof comes from ILMT. When you sign your Passport Advantage agreement, there is a document called the Sub-Capacity Licensing Terms, incorporated by reference into the Passport Advantage Agreement. Some older materials refer to it as the Sub-Capacity Attachment. It is the same thing. It states that you must deploy and maintain ILMT to qualify for sub-capacity pricing. Without ILMT running and collecting data, you default back to full-capacity licensing.
Two details from those sub-capacity terms that people skip at their cost. First, new sub-capacity customers are required to deploy ILMT (or one of the approved alternatives, more on those later) within 90 days of first running an eligible product on a virtualized environment. Second, you are expected to keep the audit snapshots for at least two years. If you cannot produce them on request, the auditor does not need to argue with you about sub-capacity consumption. They can default you back to full capacity for the missing period.
So ILMT exists because IBM needed a verifiable, automated way to measure sub-capacity usage. And customers needed a way to avoid paying for processor cores that their IBM software never touches.
Who Needs ILMT?
The short answer: any organization running IBM middleware products under a Passport Advantage agreement on virtualized infrastructure. That covers a lot of companies.
The products that typically trigger the need for ILMT include:
- IBM WebSphere Application Server (all editions, including Liberty)
- IBM Db2 (all editions)
- IBM MQ (formerly WebSphere MQ)
- IBM Integration Bus (formerly WebSphere Message Broker)
- IBM Spectrum products (Protect, Scale, Virtualize)
- IBM Tivoli products (Workload Scheduler, Monitoring, and others)
- IBM DataPower Gateway
- IBM SPSS and Cognos Analytics
This is not an exhaustive list. IBM has hundreds of PVU-licensed products. If you are not sure whether your specific products require ILMT, check your Passport Advantage entitlements or the IBM PVU licensing page.
There is one notable exception. If you run IBM software exclusively on bare-metal servers (no virtualization at all) and you hold full-capacity licenses that cover the entire physical server, you technically do not need ILMT. You are already paying for everything, so there is nothing to measure. In practice, though, almost nobody runs a purely bare-metal environment anymore. The moment you have even one VM running an IBM product, ILMT becomes relevant.
Another scenario worth mentioning: organizations running IBM software only in IBM Cloud or on IBM Power Systems with certain license models may have different requirements. But for the vast majority of enterprises running IBM middleware on VMware, Hyper-V, KVM, or PowerVM, ILMT is effectively mandatory.
Alternatives to ILMT for IBM Sub-Capacity Reporting
ILMT is not the only tool IBM accepts. This matters if your organization has invested in a different license management platform, or if ILMT does not cover some corner of your environment well.
As of Passport Advantage Agreement v11 (effective from February 2023), IBM recognizes four tools as valid for sub-capacity reporting:
- IBM License Metric Tool (ILMT) is the IBM-branded product, free for Passport Advantage customers.
- IBM BigFix Inventory is the HCL-developed product from which ILMT is derived. Functionally equivalent for sub-capacity purposes and the same codebase. IBM and HCL maintain a certification agreement that keeps BigFix Inventory on IBM's approved list.
- Flexera One with IBM Observability IT Asset Management is a Flexera-built alternative sold through IBM. Common in organizations that already use Flexera for broader SAM.
- Flexera One IT Asset Management is the Flexera product purchased directly.
A few things to know before choosing. ILMT is free under Passport Advantage and the fastest path to compliance if you are starting from zero. BigFix Inventory is attractive if you already own BigFix for other purposes (Lifecycle, Compliance) because you reuse the agent and server infrastructure. Flexera options make sense if you already run Flexera for Microsoft or Oracle reporting and want one tool across vendors. They are commercial products and the cost can be significant, but the coverage is broader than IBM-only.
Manual reporting used to be an exception IBM granted case by case. That door closed in 2023. Customers who were already reporting manually under the v10 agreement had a transition window to migrate to one of the approved tools. From that point on, if you are running IBM software under sub-capacity and using a spreadsheet, you are out of compliance regardless of how accurate the spreadsheet is.
One scenario that still confuses people: IBM software in containers (Kubernetes, OpenShift). Container workloads use a separate mechanism, the IBM License Service, which runs inside the cluster and produces reports IBM accepts. It is outside the scope of this guide, but worth flagging if your environment is moving toward containerized middleware.
How ILMT Works
ILMT is built on top of IBM BigFix, which is IBM's endpoint management platform. Understanding the relationship between these two products is important because ILMT does not work without BigFix. They are separate products that work together.
Here is the chain of how data flows:
BigFix Agent is installed on every server (physical and virtual) in your environment. The agent collects hardware information, installed software data, and processor configuration details. It runs continuously and reports back to the BigFix server on a regular schedule.
BigFix Server receives the data from all agents and stores it in its database. It acts as the central collection point. The BigFix server also distributes the software scanner (the component that actually identifies what is installed on each endpoint).
ILMT Server connects to the BigFix server's database and pulls the collected data. It then applies IBM's software catalog to identify which installed software is actually IBM-licensed software. The catalog contains thousands of signatures that match files, registry entries, and other markers to specific IBM products and their license metrics.
Reports are generated by the ILMT server. These reports show how many PVUs each IBM product is consuming, on which servers, and under what virtualization configuration. This is the output that matters for compliance.
The whole process is largely automated once configured. Agents scan endpoints on a schedule (typically every few hours for software inventory and daily for detailed scans). ILMT imports data from BigFix periodically (usually daily). Reports can be generated on demand or scheduled.
One thing that trips people up: the BigFix agent and the ILMT server are not the same thing. You do not install ILMT on every server. You install BigFix agents on every server and ILMT on one central server. In large environments you do not cluster ILMT itself. The server runs as a single instance. High availability is handled at a different layer, which we cover later in the guide. ILMT reads the data that BigFix collects. If the BigFix agent on a server is broken, ILMT has no data for that server. That is why agent health monitoring is so critical.
Not Sure If Your ILMT Is Set Up Correctly?
We review ILMT environments every week. Send us a quick message describing your setup and we will tell you if anything looks off. No commitment required.
Request a Free ReviewILMT Reports That Matter
ILMT can generate several types of reports, but three of them are the ones you will actually use in practice.
Audit Snapshot
This is the most important report in ILMT. The Audit Snapshot is a point-in-time export of your entire IBM software inventory, processor consumption, and virtualization configuration. When IBM initiates an audit, this is what they ask for first. The snapshot contains everything an auditor needs to assess your license position: which products are installed, how many PVUs they consume, what the virtualization topology looks like, and whether there are any gaps in the data.
You should generate Audit Snapshots regularly, not just when an audit happens. We recommend at least quarterly. If you only generate your first snapshot after receiving an audit letter, you have already lost time that you cannot get back.
Resource Utilization
The Resource Utilization report shows the processor capacity available to each server and VM over time. This is where you see whether a VM's processor allocation has changed, which directly affects PVU calculations. If someone increased a VM from 4 virtual cores to 8 for a performance test and forgot to scale it back down, this report will show it. High-water mark values matter here because IBM calculates PVU based on the maximum capacity assigned during the reporting period, not the average.
All IBM Products
This report lists every piece of IBM software that ILMT's catalog has identified across your entire environment. It is useful for discovering IBM software that nobody knew was installed. This happens more often than you would expect. A developer installs Db2 Express on a test server. Someone deploys a Docker image that bundles an IBM runtime. A legacy application includes IBM libraries that technically require a license. The All IBM Products report catches these.
Beyond these three core reports, ILMT also offers reports on computer groups, software installations, and hardware inventory. They are useful for day-to-day management but the three above are the ones that matter for compliance and audits.
ILMT High Availability and Disaster Recovery
A question we get often: can ILMT run in a high-availability cluster? The short answer is no, not in the sense most people mean. ILMT server runs as a single instance. IBM and HCL do not support an active-active or active-passive cluster configuration for the ILMT application or its embedded DB2 database.
What is supported, and what we deploy for clients who need resilience, is a warm standby. A second server is prepared with the same ILMT version. The ILMT database is backed up on a schedule and the backup is restored onto the standby host, either continuously through log shipping or daily through full backup restore. If the primary fails, you promote the standby. Downtime is measured in hours, not seconds, which is acceptable for a reporting tool that is not on the critical business path.
The BigFix Platform underneath ILMT is a different story. BigFix supports Disaster Server Architecture (DSA), multiple BigFix servers that replicate with each other, and on Windows, Microsoft Failover Clustering starting with BigFix Platform 11.0.4. If your concern is continuous data collection from agents during a site failure, that is where you put the clustering effort. ILMT can be rebuilt from the BigFix data after a recovery.
The practical configuration we use for most enterprise clients: BigFix in DSA across two data centers, ILMT as a single VM with VMware HA and daily database backups to offsite storage. That covers the realistic failure modes without introducing complexity that IBM does not support.
Common ILMT Problems We See
We work with ILMT environments every week, and certain problems come up again and again. Here are the ones that cause the most trouble.
Agents Not Reporting
This is the single most common issue. BigFix agents stop reporting for all sorts of reasons: firewall changes, certificate expirations, server reimages that did not include the agent package, network segmentation changes, or simply a service that crashed and nobody noticed. When an agent stops reporting, ILMT has no data for that server. If that server runs IBM software, you have a gap in your compliance data. We have seen environments where 20% of agents were offline and the ILMT admin had no idea because nobody was monitoring agent health.
Outdated Software Catalog
ILMT identifies IBM software by matching file signatures against its built-in catalog. IBM updates this catalog regularly to add new product versions, fix misidentifications, and improve detection accuracy. If your catalog is six months old, ILMT may miss newly installed products or misclassify existing ones. Updating the catalog is straightforward but it requires someone to actually do it. In many environments, nobody does.
Incorrect Bundling Rules
IBM products often come bundled together. WebSphere Application Server Network Deployment includes a limited-use license for IBM HTTP Server, for example. ILMT needs to know about these bundling relationships to calculate PVU consumption correctly. If the bundling rules do not match your actual Passport Advantage entitlements, your reports will overstate or understate your license consumption. Both are problems. Overstating means you might buy licenses you do not need. Understating means an auditor will find a shortfall.
Missing Virtualization Data
ILMT needs to understand your virtualization topology to calculate sub-capacity PVU values. On VMware, this means the BigFix VM Manager tool needs to connect to your vCenter and pull VM-to-host mappings. On PowerVM, ILMT reads HMC data. If this integration is broken or misconfigured, ILMT cannot determine which physical host a VM is running on. Without that mapping, it defaults to full-capacity calculations for those VMs. We see this frequently in environments where the VMware team and the ILMT team do not talk to each other.
Reports Showing 0 PVU
Sometimes ILMT reports show 0 PVU for products that are clearly installed and running. This usually means the software scan data is not being imported correctly, the catalog does not recognize the installed version, or the agent's software scan has not completed successfully. It looks harmless but it is actually a red flag. An auditor who sees a known IBM product with 0 PVU consumption will investigate further, and that investigation rarely ends well.
Want an Expert Review of Your ILMT Data?
We can spot issues in your ILMT setup that internal teams often miss. A quick review now can prevent a costly surprise during an audit.
Get an Expert ReviewILMT and IBM Audits
IBM has the contractual right to audit any Passport Advantage customer. This is written into the Passport Advantage agreement itself. Audits are conducted by IBM's License Compliance team or by third-party auditors that IBM engages (typically Deloitte, PwC, or KPMG in Europe).
When an audit is initiated, you typically receive a formal notification letter. From that point, you generally have about 90 days to provide the requested data, though timelines can vary. The auditor will request ILMT Audit Snapshots covering the review period, your Passport Advantage entitlement records (IPLA and related documents), and details about your virtualization environment.
Here is what matters: IBM expects continuous ILMT data for the entire sub-capacity reporting period. If you have been running ILMT for three years with no gaps, you are in good shape. If there are periods where ILMT was not running, where agents were offline, or where reports were not generated, the auditor can treat those periods as full-capacity.
The financial impact of this can be severe. Consider a scenario where you have 10 VMware hosts, each with 20 physical cores, running WebSphere Application Server Network Deployment. Under sub-capacity, you might be licensing 30 virtual cores across your VMs. Under full-capacity, you owe licenses for all 200 physical cores. At 70 PVU per core, that is the difference between 2,100 PVU and 14,000 PVU. Depending on your license pricing, that gap could represent hundreds of thousands of dollars in back-charges.
The best defense against audit risk is simple: keep ILMT running, keep agents healthy, generate reports regularly, and fix issues as they arise rather than letting them accumulate. If you need help preparing for an audit or managing your ILMT during one, our ILMT Audit & Compliance service is designed for exactly that situation.
Getting Started with ILMT
If you do not have ILMT deployed yet, here is a high-level overview of what the process looks like. This is not a step-by-step installation guide (we will publish a detailed installation walkthrough separately), but it gives you a sense of the scope.
Step 1: Install the BigFix server. This is the foundation. The BigFix server is a Windows-based application (though the agents support Windows, Linux, AIX, Solaris, and other platforms). You will need a dedicated server or VM, a SQL Server or Db2 database, and network connectivity to all the endpoints you want to manage. For most environments, a single BigFix server handles up to about 20,000 endpoints.
Step 2: Deploy BigFix agents. Every server where IBM software runs needs a BigFix agent. This includes physical servers, virtual machines, and LPARs on Power Systems. The agent is lightweight and runs as a service. Deploying it across a large environment usually involves your existing software distribution tools, scripted installs, or including it in your VM templates.
Step 3: Install the ILMT server. ILMT is a web application that runs on its own server (or shares one with BigFix in smaller environments). It connects to the BigFix database to pull endpoint data. Current versions of ILMT (9.2.x) run on Linux (RHEL or SLES) and use an embedded Db2 instance for their own data store. ILMT does not support an active-active cluster of its own. If you need resilience, the standard approach is a warm standby (a second ILMT host with regular database backups restored on a schedule) or virtualization-level HA. That is the same approach IBM's own documentation describes.
Step 4: Configure the software catalog and import data. Once ILMT is running, you import the latest software catalog from IBM, configure your virtualization connections (vCenter for VMware, HMC for PowerVM), and let the first data import run. This initial import can take several hours depending on the size of your environment.
Step 5: Generate your first reports. After the initial data import, generate an Audit Snapshot and an All IBM Products report. Review them carefully. The first set of reports almost always reveals surprises: IBM software nobody knew about, agents that did not deploy correctly, VMs missing from the virtualization topology. These initial findings are normal and fixing them is part of the process.
The entire deployment typically takes between one and four weeks, depending on the size and complexity of your environment. Organizations with thousands of servers across multiple data centers and virtualization platforms will need more time than a company with 50 VMs on a single vCenter.