WebSphere Hypervisor Eligibility Checklist
Sub-capacity is the difference between licensing a few virtual cores and licensing an entire physical host, but it only holds when WebSphere runs on an eligible virtualization technology and the reporting obligations are met. Run on the wrong platform, or let the reporting lapse, and IBM defaults you to full-capacity. Eligibility is a checklist, not an assumption.
What eligibility actually means
IBM publishes which virtualization technologies qualify for sub-capacity licensing. Mainstream platforms such as VMware, PowerVM and LPAR, Hyper-V, and major public cloud are generally eligible, each with its own counting rules. Running on a technology IBM does not recognize as eligible, for example certain older operating environments, voids the sub-capacity claim entirely and reverts the count to the full physical capacity of the host. Eligibility is binary for a given period: either the platform qualifies and the reporting backs it, or the full host is charged.
The checklist
Every item below has to be true for the sub-capacity claim to stand. A single failure in any period defaults that period to full-capacity charging.
- Eligible technology: WebSphere runs on a virtualization platform IBM recognizes for sub-capacity
- Tool deployed in time: ILMT, or an approved tool, installed within 90 days of first eligible deployment
- Continuous operation: the tool runs without gaps; a lapsed agent voids the claim for that window
- Quarterly reports retained: reports generated each quarter and kept for two years
- Correct classification: the WebSphere install is categorized correctly, with manual correction where ILMT misreads it
- Bounded mobility: where workloads can migrate, the cluster boundary is enforced and evidenced
Where the claim quietly fails
Most full-capacity findings are not deliberate, they are reporting failures. An agent that stopped reporting for a quarter, an install ILMT miscategorized and nobody corrected, or a workload that drifted onto an ineligible host are the common causes. The lookback makes this expensive: IBM can reach back several years, and any period without clean evidence is charged at full-capacity rather than the cores WebSphere actually used. The gap between sub-capacity and full-capacity on a large host is the whole reason the metric exists.
How buyers defend it
We run the eligibility checklist against each WebSphere deployment for every period in scope, confirm the platform qualified, and reconcile the continuous ILMT record. Where a finding charges full-capacity, the counter is the eligibility evidence plus the retained reports showing the real allocated cores. Where reporting lapsed or installs were miscategorized, we correct them and rebuild the defensible position before the number is finalized in settlement.
WebSphere sub-capacity is conditional, not automatic. Confirm the platform is eligible, the reporting tool was deployed within 90 days and ran continuously, the quarterly reports are retained for two years, and the installs are classified correctly. Every period that fails the checklist defaults to full-capacity across the whole host, and the lookback turns one missed quarter into years of exposure. Run the checklist before IBM does.