OpenShift Virtualization, counted as containers.
OpenShift Virtualization runs virtual machines as KubeVirt managed pods on the OpenShift cluster, alongside the container workloads on the same nodes. The licensing reads per worker core on the cluster, not per virtual machine, and the VM density on the node is the variable that decides whether the line pays. The product sits at the centre of most 2026 VMware exit conversations, but the read at the renewal table is on the cluster footprint and the worker core count, not on the count of VMs migrated.
KubeVirt, under OpenShift Virtualization.
OpenShift Virtualization is Red Hat's productised release of the upstream KubeVirt project, packaged as an OpenShift operator and supported as a Red Hat product line. The product allows the OpenShift cluster to run virtual machines as Kubernetes pods, with the VM lifecycle managed by Kubernetes constructs and the VM workload running inside a libvirt and QEMU process under the pod boundary1. The VMs share the cluster's worker nodes with the container workloads, and the cluster scheduler places VMs alongside containers based on resource availability and node selectors.
The product is included with Red Hat OpenShift Container Platform from a feature standpoint, but the licensing read at the cluster level is on the OpenShift line itself. There is no separate OpenShift Virtualization SKU on the cluster that carries the platform line; the virtualization capability runs under the existing platform entitlement. The reading at the renewal table is not on a new line for virtualization; it is on the cluster footprint that the virtualization workload pushes upward as the VM density on the node grows.
The practical consequence is that adding VMs to an existing OpenShift cluster does not, by itself, add a new licensing line. It expands the cluster footprint, because VMs typically request more memory and more CPU per pod than container workloads do, and expanding the cluster footprint expands the worker core count that the OpenShift line is read against. The cluster that ran sixteen worker cores for containers and grew to forty worker cores to absorb migrated VMs carries the OpenShift line at forty worker cores, not sixteen2.
Per worker core, not per VM.
The OpenShift Virtualization licensing read at the renewal table follows the OpenShift Container Platform per worker core convention. The cluster carries a core count on worker nodes, with control plane and dedicated infrastructure nodes excluded under the standard rules. The VMs running under KubeVirt do not change the metric. A buyer who runs fifty VMs on a sixteen core worker node pays for the sixteen cores; the same buyer who runs two VMs on the same node pays for the same sixteen cores.
The metric matters because it inverts the VMware mental model that most teams arrive with. VMware Cloud Foundation, VMware vSphere, and the per CPU or per core licensing on VMware ESXi all scale with the hypervisor footprint, and the per VM operational model lives separately. OpenShift Virtualization scales with the cluster worker footprint and the operational model lives on the same Kubernetes constructs as containers. A VMware estate that licensed twenty hypervisor sockets for a hundred VMs translates to an OpenShift Virtualization estate that licenses the OpenShift cluster worker cores that host the equivalent workload3.
The translation is rarely one to one. The VM density on the worker node, the resource request profile per VM, the overcommit posture on the cluster, and the live migration policy all influence how many worker cores the equivalent workload requires. A practice posture that benchmarks per VM resource consumption from the VMware estate and applies it against OpenShift worker core sizing produces a more accurate forecast than a straight socket to core conversion.
The path off VMware, read against the cluster.
OpenShift Virtualization is positioned in 2026 as the Red Hat answer to the VMware exit conversation that began across the enterprise estate after the Broadcom acquisition and the licensing changes that followed. The conversation at the renewal table is on the cluster footprint required to absorb the VMware workload and on whether the OpenShift line for that footprint is favourable against the renewed VMware line on the same workload.
Three patterns appear in the practice's observation across VMware exit conversations in the trailing twelve months. The first is the contained migration, where a defined VM workload moves to an existing OpenShift cluster with sufficient worker capacity to absorb it. The OpenShift line on the cluster grows modestly or not at all, and the VMware line is retired on the migrated workload. The math is favourable on this profile because the OpenShift cluster carries the workload at marginal cost.
The second pattern is the dedicated migration, where the VMware workload moves to new OpenShift clusters provisioned specifically for the VM workload. The OpenShift line grows by the cluster footprint required, and the VMware line is retired. The math is read against the comparable VMware renewal for the same workload, with the OpenShift line typically pricing below the VMware line at moderate scale and above it at small scale where the OpenShift cluster minimum exceeds the workload.
The third pattern is the hybrid posture, where the VMware estate is contained and a portion of new workload moves to OpenShift Virtualization. The OpenShift line grows by the new workload footprint and the VMware line is maintained at the contained scope. The math is read across both lines for the duration of the contained period, with the discipline being to set a contained period explicitly rather than allowing the hybrid to persist indefinitely.
The trap, VM density on hyperthreaded hosts.
The structural trap at the OpenShift Virtualization renewal table is the misread on hyperthreaded worker nodes. OpenShift counts entitlement against physical cores, not against vCPU threads, on hyperthreaded x86 hardware. A worker node with sixteen physical cores and hyperthreading enabled appears to the Kubernetes scheduler as thirty two vCPUs. The OpenShift line is read against the sixteen physical cores. The VM scheduler may overcommit against the thirty two vCPU view, leading to density patterns that look favourable at the cluster console and translate to a different line at the renewal table.
Two consequences follow. The first is that the cluster appears to host more VMs than the entitled core count would suggest, which is operationally true but contractually distinct from the entitlement line. The second is that the audit posture reads the cluster against the physical core count, not the vCPU thread count, and the buyer who sized the cluster expecting the vCPU view to apply to the line finds the line at twice the budget. Hyperthreading on OpenShift Virtualization counts the same way as hyperthreading on OpenShift containers; the VM workload does not change the convention.
The protections at signature are the same as on the broader OpenShift counting reading. The cluster sizing is explicit on physical cores in the contract record. The hyperthreading convention is named. The expected VM density per worker is documented in the cluster sizing artefact, so the cluster footprint forecast is defensible at the audit notice. For the broader counting reading, see core counting under hyperthreading.
| Item | Frequency | Reading |
|---|---|---|
| Contained migration on existing cluster | 4 of 10 | Pays cleanly |
| Dedicated cluster, moderate scale | 3 of 10 | Pays against VMware renewal |
| Dedicated cluster, small scale below minimum | 1 of 10 | Reads above VMware line |
| Hybrid posture with contained period | 2 of 10 | Pays inside the period |
The buyer side posture, at the renewal table.
OpenShift Virtualization sits at the centre of the 2026 VMware exit conversation, and the conversation belongs at the renewal table on the OpenShift line. The reading is on the cluster footprint required to host the migrated workload, the per worker core line that scales with that footprint, and the comparative VMware renewal on the same workload if the migration were not taken.
Two readings stand at the buyer side. The first is whether the workload, in its actual profile, fits the cluster footprint and the OpenShift line at a price below the alternative VMware renewal. The second is whether the cluster footprint required to host the workload pushes the OpenShift line through bundle inclusion math that changes the calculus, because the cluster that grows into a bundle scope may also grow into the Advanced Cluster Security, OpenShift Data Foundation, or Advanced Cluster Management overlay products in the bundle. A subscription assessment before the migration sizes the cluster footprint against the actual workload and produces the reading both sides need.
The conversation at the renewal table is also informed by the alternative paths. Red Hat Virtualization at end of life is part of the broader posture. OpenShift Data Foundation pricing matters when VMs need persistent storage on the same cluster. For the broader practice context, see the storage and virtualization practice and the OpenShift practice. For the engagement protocol, see contact.
Notes & references
- 1. Red Hat OpenShift Virtualization product page and KubeVirt upstream project documentation, accessed across 2025 and 2026. OpenShift Virtualization is the productised release of KubeVirt as an OpenShift operator. The libvirt and QEMU implementation underneath is the same hypervisor stack used in the upstream Linux ecosystem.
- 2. OpenShift Container Platform subscription guide, per worker core convention and control plane exclusion. The convention applies uniformly across containerised workloads and KubeVirt managed VMs on the same cluster. Hyperthreading reads against physical cores in both cases.
- 3. Practice observation across ten VMware to OpenShift Virtualization migration engagements settled between July 2025 and April 2026. Cluster footprint forecast against actual VM resource profile produced a more accurate sizing than straight socket to core conversion in nine of ten cases.
- 4. Concession bands referenced throughout reflect the practice's observation across signed contracts in the trailing twelve months on OpenShift Virtualization renewals and migration engagements, not list prices and not initial vendor quotes. The VMware comparative reading is against renewed VMware terms after the Broadcom acquisition.
- 5. All figures are net of fees and verified against signed contract deltas. The eighty two percent audit exposure reduction referenced in practice marginalia is the trailing twelve month average across defenses settled, not an OpenShift Virtualization specific figure.
Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.