RHV to OpenShift Virtualization, priced against the sunset.

Red Hat Virtualization is the Red Hat supported KVM based hypervisor that Red Hat positioned for years as the on premise virtualization alternative to VMware vSphere. Red Hat moved RHV to end of full support in August 2024 and named OpenShift Virtualization as the receiving product on the Red Hat virtualization roadmap. The buyer who still runs RHV in production after the end of full support date is on the extended life support timeline, which carries security backports but not feature work and not non security backports1.

OpenShift Virtualization is the KubeVirt based stack that Red Hat ships as an operator on OpenShift. The operator schedules KubeVirt virtual machines as pods on the OpenShift cluster's worker nodes. The virtual machine workload sits alongside container workloads on the same cluster, and the virtualization stack is metered through the OpenShift entitlement: cores on the worker nodes that host the virtual machines count against the OpenShift subscription, with no separate hypervisor licence beyond the OpenShift line2.

The migration economics are therefore a two sided question. On the RHV side the question is how long the buyer wishes to pay extended life support against an end of life timeline and what the replatform cadence looks like. On the OpenShift side the question is whether the existing OpenShift footprint can absorb the migrated virtual machines or whether the migration requires net new OpenShift cores under a new contract line.

OpenShift Virtualization workload reads at the OpenShift core counting basis. The cores on the worker nodes that host the KubeVirt virtual machines count against the OpenShift subscription regardless of whether those cores are scheduling container workloads or virtual machine workloads. The control plane node cores do not count against the subscription on a standard OpenShift contract; only the worker node cores do, with a discount applied for bare metal worker nodes in some contract structures.

The arithmetic of the migration depends on the RHV host count and the virtual machine to core ratio the engineering team is willing to schedule on the OpenShift side. A buyer who ran sixty four RHV hosts at twenty four cores per host has fifteen hundred and thirty six hypervisor cores in the source environment. The same workload running on OpenShift Virtualization at the same virtual machine to core ratio reads at the same fifteen hundred and thirty six cores on the OpenShift worker pool, which is a substantial OpenShift contract expansion if the buyer's existing OpenShift footprint was smaller3.

The engineering team can often consolidate the migration by replatforming virtual machines that no longer need full virtualization to container workloads, by retiring virtual machines that the inventory has not retired previously, and by tuning the virtual machine to core overcommit ratio on the OpenShift side. The procurement function should price the migration at the consolidated core count, not at the one for one mapping. The migration is the cheapest moment to retire virtual machines that the operations team would otherwise carry indefinitely; the audit pressure on RHV plus the budget visibility on OpenShift creates leverage that the buyer rarely has outside the migration window.

The RHV support tail is the second half of the migration economics. A buyer that began the migration in 2024 with twelve months of planned parallel run will have paid the RHV subscription through the extended life support tier through 2025 and into 2026. The extended life support tier covers security backports only and is intended as a runway for migration, not as a long term hosting tier. The cost of the extended tier accumulates against the cost of the OpenShift expansion the migration is preparing for.

The parallel run is the period when the RHV environment and the OpenShift Virtualization environment both run productively. A typical parallel run lasts between three and nine months depending on the size of the estate and the regulatory posture of the workloads. During the parallel run the RHV contract continues to bill, the OpenShift contract is expanding to absorb the migration, and the engineering team is doing both operational work simultaneously. The migration cost includes the labour for the parallel run, not just the contract delta4.

The migration procurement narrative should name the parallel run length, the RHV extended life support tier the buyer is willing to pay for, the OpenShift contract expansion the migration requires, and the labour budget for the parallel run. The procurement function that prices all four lines together signs a clean envelope. The procurement function that prices only the OpenShift expansion discovers the other three lines at the next quarterly review and is asked to defend them retroactively.

The buyer side discipline at the procurement table is a migration narrative that names the virtual machine inventory, the destination by pattern, the OpenShift contract expansion, the parallel run length, and the RHV extended life support tier. The narrative is reviewed by the procurement function, the platform engineering function, and the operations function before any contract is signed. The migration is procurement work first and engineering work second; treating it as engineering work first commonly produces a contract that the procurement function cannot defend.

For the broader cross product reading, see the storage and virtualization practice hub, the OpenShift Virtualization as VMware exit path read for the parallel migration story from vSphere, the Red Hat Virtualization end of life planning read for the lifecycle dates, the OpenShift Virtualization KubeVirt licensing read for the core counting detail, and the VMware host inventory evidence read for the parallel evidence pattern that often surfaces during the migration. For the engagement protocol, see renewal negotiation and contact.

OpenShift Virtualization versus Red Hat Virtualization is a migration economics question with a forced timeline. The buyer who sizes the destination at consolidated core count, who retires stale virtual machines in the migration window, and who prices the parallel run honestly signs a contract that reads cleanly. The buyer who lifts and shifts pays the migration twice: once at the OpenShift expansion and again at the parallel run that ran longer than the procurement function planned.

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.