ILMT and Sub-Capacity

How Auditors Use Historic ILMT Snapshots Against You

Your ILMT data is not just a current picture. It is a timeline, and the timeline is exactly what an auditor wants. By reaching back through historic snapshots, IBM can build a finding from a single peak that lasted a single quarter, even if your steady-state position is well within entitlement.

ILMT keeps a history

The License Metric Tool records consumption over time, snapshot by snapshot, quarter by quarter. That history is the evidence behind sub-capacity, and it is the reason the tool is mandatory. But the same record that protects you can be read against you, because it preserves every spike, every misconfiguration, and every period when an agent was reporting badly.

The peak value problem

Sub-capacity is measured on peak processor value unit consumption within a period, not the average. An auditor looking at your back history will reach for the highest point in each window. A short lived spike, a test environment left running, or a migration that briefly doubled a footprint can all set a peak that defines the finding. The number that matters to the auditor is the worst quarter you ever had, not the typical one.

How auditors read the timeline

Read this way, a basically compliant estate can produce a large finding, assembled entirely from outliers in the record.

Where the data can mislead

Many historic peaks do not reflect real licensable usage. A spike can come from a miscategorized install, a temporary clone of a server, a workload that was decommissioned days later, or an agent reporting inflated capacity because the VM manager connection was down. None of these is genuine over-deployment, but all of them sit in the snapshot history looking identical to it. The defense is to explain the context of each peak rather than to accept the number on its face.

Defending the historical record

The buyer side approach is to treat the timeline as contestable evidence. We reconcile each flagged peak against what was actually deployed and entitled at the time, separate real consumption from artifacts, and document the cause of every spike. Where reporting was broken, we reconstruct the defensible position rather than concede full capacity. The goal is to replace the auditor's worst-case reading of your history with an accurate one.

What this means under audit

Expect IBM to mine your full ILMT history for peaks and to treat the highest as the baseline. Do not accept a finding built on outliers. Every spike has a story, and a documented explanation of each one is what brings the historical number back to reality.