IBM VM Virtualization Rules: Sub Capacity Eligibility.

What the rules are for.

IBM software licensed under Passport Advantage with a Processor Value Unit (PVU) or Resource Value Unit (RVU) metric is sold by the underlying physical processor capacity. When the software runs on a virtualised platform, the buyer can in principle pay only for the virtual capacity allocated to the software, not the full physical capacity of the host. This is sub capacity licensing. The virtualization rules define when the sub capacity model is allowed and what documentation is required.

The default position is full capacity. Sub capacity is an exception that must be earned. The buyer side discipline is to operate every PVU and RVU workload on a sub capacity eligible platform with the required documentation in place. Without that discipline, the audit position defaults to full capacity, which typically produces a multiple of the actual entitlement requirement.

Written from the buyer side by independent advisors. We are not an IBM Business Partner. For an introduction to the broader sub capacity framework, see sub capacity explained and the sub capacity expertise page.

Approved virtualization platforms.

IBM publishes a list of approved virtualization platforms in the Eligible Virtualization Technology table. The list is updated multiple times per year. The buyer side discipline is to verify the current version of the table at every architecture decision. The major platforms typically on the list include VMware vSphere ESXi, Microsoft Hyper V, KVM (in defined configurations), IBM PowerVM, IBM zVM, and the major cloud hypervisors as documented in the cloud section.

VMware vSphere.

VMware vSphere ESXi is the most commonly deployed approved platform. The eligibility conditions include the use of supported ESXi versions, the use of vCenter for management, and the deployment of the IBM License Metric Tool against the environment. Most Fortune 500 customers running VMware satisfy the conditions structurally but the documentation gap is frequent.

Microsoft Hyper V.

Hyper V is approved with conditions similar to vSphere. The eligibility hinges on the partitioning configuration. Static partitioning produces clean eligibility. Dynamic memory or processor reallocation patterns require careful documentation.

IBM PowerVM and zVM.

IBM PowerVM (the Power Systems hypervisor) and zVM (the IBM Z mainframe hypervisor) are approved with the most generous partitioning rules in the table. Both are IBM platforms and the alignment is unsurprising. The buyer side opportunity is to centralise IBM workloads on Power or Z where the partitioning rules are most favourable. See mainframe expertise.

KVM.

KVM is approved in defined configurations, including Red Hat Enterprise Virtualization and OpenShift Virtualization. The eligibility hinges on the management platform and the partitioning configuration. KVM running outside a supported management platform is typically not eligible.

Capping and partitioning.

The sub capacity entitlement is anchored to the capped allocation of the virtual machine, not the unbounded peak. The two operational concepts are static partitioning and dynamic partitioning.

Static partitioning.

The virtual machine is configured with a fixed processor allocation that does not vary. The IBM sub capacity entitlement is calculated against the fixed allocation. This is the cleanest eligibility model and is achievable on every approved platform.

Dynamic partitioning.

The virtual machine processor allocation can vary at runtime through reservations, shares, or limits. The IBM sub capacity entitlement is calculated against the maximum allocation reached over a defined window. The dynamic partitioning model is operationally flexible but requires more documentation rigour.

ILMT and reporting.

The IBM License Metric Tool (ILMT) is the reporting requirement that anchors most sub capacity entitlement claims. ILMT scans the environment, identifies the IBM products in scope, and produces the Audit Snapshot quarterly report that documents the sub capacity entitlement consumption.

The ILMT requirement is operationally precise. The tool must be deployed within ninety days of the first IBM PVU product installation. The Audit Snapshot must be generated quarterly and retained for two years. The bundle files for new product releases must be applied promptly. Each of these is a documented requirement and each is a common audit finding source. See the ILMT best practices guide and the ILMT guide.

ILMT failure modes.

Three ILMT failure modes recur. The deployment is incomplete, leaving a portion of the environment unscanned. The bundle file lifecycle is not maintained, leaving products mis identified. And the Audit Snapshot is generated but not reviewed, leaving exposures undetected. Each failure mode is recoverable but the recovery is most effective before an audit, not after.

Cloud hypervisor rules.

The major cloud hypervisors carry their own eligibility status. AWS EC2 Dedicated Hosts and Dedicated Instances are eligible under specific conditions. Azure Hyper V backed virtual machines are eligible. Google Compute Engine is eligible in defined configurations. IBM Cloud Virtual Server instances are eligible by default.

The cloud sub capacity rules typically require a Dedicated Host configuration, not shared tenancy, because the IBM partitioning model assumes single tenant visibility into the hypervisor. The dedicated configuration carries a cost premium relative to shared tenancy. The buyer side maths is to compare the IBM full capacity cost on shared tenancy against the IBM sub capacity cost on dedicated tenancy, including the dedicated premium. See IBM cloud sub capacity.

Containers and Kubernetes.

Container deployments under Cloud Pak licensing use a different metric, the Virtual Processor Core (VPC), and a different reporting tool, the Cloud Pak Licence Service. The classic sub capacity rules do not apply to container workloads on Cloud Pak. The container licensing rules are documented separately. See IBM container licensing.

Container workloads outside Cloud Pak licensing (for example, classic IBM products running in containers under traditional Passport Advantage entitlement) sit in a transitional zone. The buyer side discipline is to convert these workloads to Cloud Pak entitlement at the first practical opportunity, both for licensing clarity and for forward platform alignment. See Cloud Pak strategy.

Common eligibility failures.

The five most common sub capacity eligibility failures observed in Fortune 500 audits.

1. Uncapped virtual machine. The VM runs on an approved platform but has no enforced processor cap. Defaults to full capacity at audit.
2. ILMT not deployed within ninety days. The product install predates the ILMT deployment. The window between install and ILMT defaults to full capacity.
3. Bundle files out of date. The ILMT scan misidentifies the product because the bundle file lifecycle has not been maintained. The Audit Snapshot understates the actual deployment.
4. Unapproved platform. The workload runs on a hypervisor that is not on the current Eligible Virtualization Technology table. The eligibility is voided regardless of other documentation.
5. Cloud shared tenancy. The workload runs on a cloud hypervisor in shared tenancy where dedicated is required. Defaults to full capacity at audit.

Where to go next.

For the broader sub capacity framework, see sub capacity explained. For the ILMT operational guide, see ILMT guide and ILMT best practices. For cloud sub capacity, see IBM cloud sub capacity. For container licensing, see IBM container licensing. For the sub capacity expertise page, see sub capacity expertise. For ILMT expertise, see ILMT expertise. For PVU optimisation, see PVU optimization expertise.

For a scoped advisory conversation about your virtualisation eligibility and ILMT posture, the contact page is the entry point. A senior advisor responds within 24 hours.