The vMotion Problem: When Workloads Move
VMware made workloads portable, and that portability is exactly what an IBM auditor looks for. If an IBM virtual machine can migrate freely across a cluster, IBM may argue that every host it could land on is in scope, not just the host it ran on. The defense is to prove where the software could and could not go. Mobility expands the claim unless you bound it.
Why movement matters to the metric
Sub-capacity licenses the virtual cores running IBM software rather than the full physical host. But on a VMware cluster with vMotion and DRS enabled, a virtual machine is not pinned to one host. IBM's position is that any host the workload could migrate to is part of the licensable capacity, because the software was capable of running there. A four host cluster suddenly becomes four hosts of countable cores rather than the cores of the one host the workload occupied.
The cluster boundary is the argument
The fight is almost always about boundaries. If a virtual machine can vMotion across an entire cluster, the cluster is the boundary IBM will claim. If host affinity rules, dedicated clusters, or hard partitioning restrict where the workload can run, that smaller boundary is what should count, provided it is documented and enforced rather than merely intended.
- Unrestricted cluster: IBM claims every host the workload could reach
- Host affinity rules: can narrow scope only if technically enforced and evidenced
- Dedicated cluster for IBM workloads: the cleanest boundary to defend
- Configuration drift: a rule that lapsed during the lookback reopens the wider claim
ILMT has to corroborate the boundary
A containment argument only works if the evidence backs it for the whole lookback period. ILMT must be deployed within 90 days of first eligible deployment, running continuously, with quarterly reports retained for two years, and those reports need to reflect the hosts where the software actually ran. If ILMT shows the workload reaching hosts the affinity rules were supposed to exclude, the rule was not enforced and the wider claim stands. The configuration intent and the measured reality have to agree.
How buyers defend it
We reconstruct the cluster topology for each period in scope, document the affinity and DRS settings that limited migration, and line them up against the continuous ILMT record. Where a finding charges every host in a cluster, the counter is the enforced boundary plus the reports showing the workload never crossed it. Where boundaries were loose, the remediation is to tighten them now and rebuild a defensible posture before the next reporting cycle closes.
On VMware, mobility is the exposure. If an IBM workload can vMotion across the cluster, expect IBM to claim the cluster. Restrict where the software can run with enforced affinity rules or dedicated clusters, prove it with continuous ILMT reports, and keep the configuration consistent across the lookback. An undocumented or unenforced boundary hands IBM every host the workload could have touched.