Db2 sub-capacity on VMware clusters.

Why VMware is the high-risk hypervisor.

Sub-capacity licensing lets you license only the virtual cores Db2 uses instead of every physical core in the host. VMware complicates that because vMotion and Distributed Resource Scheduler can move a Db2 virtual machine across hosts automatically. IBM's sub-capacity rules treat any host a workload can run on as in scope, so an unrestricted cluster means every host where Db2 could land becomes licensable. That is how a sixteen virtual core deployment turns into a charge across a 128 core cluster.

What pulls the whole cluster into scope.

The exposure is not the cores Db2 used on average; it is the cores Db2 could have reached. Without host affinity or pinning rules that confine the workload, IBM's position is that the entire cluster is eligible territory. Add a broken or late ILMT agent and the sub-capacity claim for that period collapses entirely, defaulting to full capacity. The lookback can reach back two to five years, so a single mismanaged quarter compounds across the audited window.

• vMotion and DRS let Db2 roam unless host affinity rules confine it
• Any host the workload can reach is treated as in scope by IBM
• A missing or late ILMT agent voids sub-capacity for that period
• Full capacity on the cluster can be many times the real consumption

How the claim is defended.

The defense is built on two records: the VMware configuration that constrained where Db2 could run, and the ILMT data that measured what it actually used. Where host affinity rules pinned Db2 to a defined subset of hosts, those rules cap the licensable footprint, and the quarterly sub-capacity reports prove the peak. Where the configuration was loose, we scope the genuine exposure rather than conceding IBM's full cluster figure, and we correct ILMT miscategorizations that inflate the count.

What this means under audit.

A Db2 on VMware finding is rarely about how much Db2 ran. It is about whether you can prove where it could run and that ILMT captured it. Under Contain, Reconcile, Challenge, Settle, the Reconcile step rebuilds the cluster boundary from affinity rules and ILMT evidence, and the Challenge step holds IBM to its own sub-capacity terms instead of the full cluster default. The records win this dispute, and assembling them early is the whole game.