WebSphere on VMware: counting the right cores.

WebSphere is licensed by processor value units, counted against the cores it uses. On a single physical server that count is simple. On VMware it is not, because the whole point of the platform is that a guest is mobile. vMotion can migrate a running virtual machine between hosts, and Distributed Resource Scheduler can do it automatically to balance load. IBM's sub-capacity rules respond to that mobility by counting the cores the workload could reach, not only the cores it occupies at the instant of measurement.

This is where well run estates get surprised. A team licenses WebSphere for the four cores of a small guest, confident the deployment is tiny. The cluster, however, is configured so that guest can move freely across eight large hosts. Unless that movement is constrained and the constraint is evidenced, IBM's position is that the relevant capacity is the set of hosts the guest can land on. The count jumps from four cores to the cluster.

Why mobility expands the count

Sub-capacity is a bargain: license the virtual cores in use, in exchange for proving where the software ran. In a mobile cluster, proving where it ran is only half the answer. IBM also asks where it could run, because an unconstrained guest can consume capacity on any host in its migration boundary. The capacity calculation therefore follows the boundary, and a loosely defined boundary is a large boundary.

Constraining the boundary

• Pin WebSphere guests to a defined subset of hosts using host affinity rules
• Carve a dedicated cluster or resource pool for IBM workloads so the boundary is explicit
• Ensure ILMT, or an approved tool such as Flexera One ITAM or HCL BigFix Inventory, observes the cluster topology and the constraints
• Keep the configuration stable, because a constraint that existed only briefly is hard to evidence across a multi year lookback

Proving the constraint under audit

A constraint that is not evidenced does not exist as far as the audit is concerned. The defensible package shows the affinity rules or cluster boundaries that limited where WebSphere could run, the ILMT data that observed the same topology, and a continuous record across the audited period. With that in hand, the count returns to the cores inside the constrained boundary. Without it, IBM applies the full cluster, and on WebSphere that is the difference between a few hundred PVU and several thousand. We assemble that package, reconcile it against entitlements, and challenge any finding that assumes an unconstrained cluster the evidence does not support.