OpenShift Virtualization, the VMware exit read closely.
OpenShift Virtualization, the Red Hat productisation of KubeVirt, is positioned by Red Hat as the VMware exit candidate of choice and is the candidate the field team will quote first to any VMware estate reading exit options. The buyer side reads OpenShift Virtualization on its actual licensing posture, its actual cluster footprint at the workload profile in question, its operational fit with the existing platform team, and against the alternative candidates on the same estate. The exit decision is signed when the candidate fits the estate, not when the Red Hat quote fits the slide deck.
The VMware repricing, and what it set in motion.
The Broadcom acquisition of VMware closed in late 2023 and was followed by a programmatic restructuring of the VMware product portfolio and the VMware commercial model. Perpetual licenses moved to subscription. Many low tier SKUs were retired. Product bundles were rebuilt around vSphere Foundation and Cloud Foundation, with the smaller standalone editions consolidated into larger packages. Pricing on the renewed packages moved materially upward on most observed estates1.
The structural consequence for buyers reading the post repricing VMware renewal is that the exit question is now a serious renewal question on most large estates. Many estates that previously would have renewed VMware on autopilot are reading exit candidates in parallel. OpenShift Virtualization is one of the candidates Red Hat positions hard into that reading. The question for the buyer side is not whether OpenShift Virtualization is a candidate. It is whether OpenShift Virtualization is the candidate that fits the specific estate.
The reading at the renewal table is on the same posture used in any exit reading. Size the candidate against the workload profile. Size the licensing footprint required on the candidate against the candidate's metric. Size the operational lift from the source platform to the candidate against the platform team's capability. Size the long term posture of the candidate vendor against the buyer's planning horizon. Compare the result against the alternatives. Sign the candidate that fits. The VMware exit to OpenShift Virtualization is one possible outcome of that reading, not the predetermined outcome.
OpenShift Virtualization, and what it actually is.
OpenShift Virtualization is the Red Hat productisation of KubeVirt, an upstream Kubernetes project that runs virtual machines as Kubernetes pods. The hypervisor underneath is KVM with QEMU and libvirt, the same hypervisor stack that ran Red Hat Virtualization. The orchestration above is OpenShift, with the VM lifecycle managed through Kubernetes constructs (VirtualMachine, VirtualMachineInstance) rather than a dedicated VM manager2.
The functional posture overlaps VMware vSphere substantially for standard VM workloads. Live migration is supported. Snapshots are supported. High availability is supported through OpenShift scheduling. CSI driven persistent storage is supported, with OpenShift Data Foundation, Ceph, NFS, and various third party CSI providers in the supported list. Network integration is supported through Multus and OVN Kubernetes. The classical VM operations a vSphere administrator would expect have functional equivalents on OpenShift Virtualization, with the caveat that the management surface is Kubernetes rather than vCenter.
The licensing read on OpenShift Virtualization is on the OpenShift cluster footprint, not on the count of VMs hosted. The cluster carries the OpenShift Container Platform line on its worker node core count. The VMs run on the cluster as KubeVirt pods. A buyer who migrates two hundred VMs onto OpenShift Virtualization licenses the OpenShift clusters that host those VMs, with the cluster sized against the aggregate VM resource profile. The metric is worker cores, not VMs. For the counting mechanics in detail, see OpenShift Virtualization counted as containers.
The migration arithmetic, cluster footprint against VM profile.
The cluster footprint required to absorb a VMware workload onto OpenShift Virtualization is a function of the aggregate VM resource profile, the desired headroom for scheduling, the overhead of the Kubernetes and OpenShift control plane, and the operational reserve for live migration and rolling upgrade. The arithmetic is direct but requires real numbers from the source estate to be useful at the renewal table.
The aggregate VM resource profile is the sum of allocated vCPUs and allocated RAM across the migrating workload, adjusted for the realised utilisation rather than the allocated headline. Many VMware estates allocate vCPUs generously relative to actual utilisation, with steady state CPU utilisation across the estate often in the fifteen to thirty percent range. The migrating cluster does not need to absorb the allocated headline; it needs to absorb the realised utilisation plus reasonable headroom. The cluster sizing exercise reads the realised utilisation from the source estate and sizes the worker pool against that figure plus headroom.
The worker cores entitled on the OpenShift line are the cores on the worker nodes that host the VMs. The control plane nodes do not count against the OpenShift line on self managed clusters; the control plane is included with the platform subscription. The infrastructure nodes that run logging, monitoring, ingress, and registry workloads carry infrastructure node entitlements that are typically more favourable than worker entitlements; the field team will quote them separately if asked. The buyer side asks. For the counting mechanics on control plane and infrastructure nodes, see OpenShift core counting, hyperthreading, and the control plane question.
| Candidate | Fit profile | Licensing metric |
|---|---|---|
| OpenShift Virtualization | OpenShift estate already in place | Worker cores on the cluster |
| Nutanix AHV | Hyperconverged hardware planned | Included with Nutanix platform |
| Microsoft Hyper V | Windows Server heavy estate | Included with Windows Server DC |
| Proxmox VE | Open source operational appetite | Paid support subscription |
| Public cloud hyperscaler VMs | Cloud first or hybrid posture | Cloud consumption metric |
| VMware renewed on new terms | Migration cost exceeds delta | Renewed VMware subscription |
Where the fit holds, and where it does not.
OpenShift Virtualization fits well on estates where OpenShift is already in production at scale, where the platform team is already operating Kubernetes as part of the platform discipline, and where the migrating workload set is amenable to Kubernetes managed VM lifecycle. The candidate is structurally favourable in that case because the operational lift is incremental rather than wholesale, the licensing is on a metric the buyer is already managing, and the long term posture aligns with the Red Hat investment already made on the OpenShift line.
The fit does not hold on estates where OpenShift is not already in production, where the platform team's Kubernetes capability is limited or absent, where the migrating workload set depends on vSphere specific features without a clean KubeVirt equivalent, or where the storage and network requirements of the workload do not map cleanly onto the CSI and CNI integrations available on the cluster. The migration in those cases is a Kubernetes adoption project layered on top of a VM migration project, and the combined operational lift typically exceeds what an organisation absorbs comfortably inside one renewal cycle.
The honest reading at the renewal table names which side of that line the estate sits on. An OpenShift Virtualization migration on an estate that is not already running OpenShift at scale is a two stage commitment dressed as a one stage migration, and that is the reading that should be signed with eyes open or not signed at all. The candidate fits where it fits. For the broader exit planning discipline that covers candidate selection across the estate, see the exit planning service.
Reading at signature, and structuring the move.
The OpenShift Virtualization signature, when it is the selected exit candidate, is structurally an OpenShift contract expansion with an explicit migration scope attached. The expansion sizes the worker core count against the cluster footprint that will host the migrated VMs. The contract terms align with the migration plan, with the expansion lining up against the date the VM workload lands on the cluster rather than the date the contract is signed.
The buyer side discipline names the migration plan in the contract structure. The expansion does not all become live on day one. A staged expansion that ramps with the migration is more favourable than an upfront expansion that pays for cluster capacity sitting idle during the migration window. The contract structure that supports the migration is one where the OpenShift line scales with the workload arriving on the cluster, not one where the line is fully live before the workload is migrated.
The bundle question is the second structural read. OpenShift Plus, the bundle that includes OpenShift Container Platform, Advanced Cluster Management, Advanced Cluster Security, OpenShift Data Foundation, Quay, and OpenShift AI on current packaging, may or may not be the right shape for an estate principally adopting OpenShift Virtualization. The bundle pays when the estate uses the bundled components; it does not pay when the estate consumes only OpenShift Container Platform and OpenShift Virtualization. For the bundle reading in full, see when OpenShift Plus pays.
For the renewal posture in general, see the renewal negotiation service. For the OpenShift practice context, see the OpenShift practice. For the storage and virtualization practice context, see the storage and virtualization practice. For the engagement protocol, see contact.
Notes & references
- 1. Broadcom acquisition of VMware, closed November 2023. Subsequent VMware product portfolio and commercial model restructuring observed across 2024, 2025, and 2026. Subscription model replaced perpetual licensing. Bundled SKUs (vSphere Foundation, Cloud Foundation) replaced many standalone editions. Observed pricing on renewed packages moved upward on most observed estates, with the realised increase variable by estate and by the negotiated terms.
- 2. OpenShift Virtualization product surface and the underlying KubeVirt upstream project, accessed across the OpenShift 4.x release cycle in 2025 and 2026. Hypervisor stack is KVM, QEMU, libvirt. Orchestration is Kubernetes through OpenShift. VM lifecycle is managed through Kubernetes constructs.
- 3. Practice observation across VMware exit conversations in the trailing twelve months. OpenShift Virtualization selected on roughly a quarter of observed cases where OpenShift was already in production at scale. Alternative candidates (Nutanix AHV, Microsoft Hyper V, Proxmox VE, public cloud, and renewed VMware on negotiated terms) split the remainder.
- 4. Cluster sizing methodology referenced throughout reflects the practice's approach of sizing the cluster against realised VM utilisation plus operational headroom, rather than against the allocated vCPU and RAM headline from the source vSphere environment. The practice observed steady state utilisation across many VMware estates in the fifteen to thirty percent range against allocation.
- 5. Concession bands referenced throughout reflect the practice's observation across signed contracts in the trailing twelve months on OpenShift expansion lines tied to VMware exit projects, not list prices and not initial Red Hat quotes. The OpenShift line on a structured VMware exit typically settled materially below the initial Red Hat quote when the buyer presented the alternative candidate set as part of the reading.
- 6. 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 a VMware exit 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.