Red Hat Virtualization 4.4 end of life: what the deadline forces and the short answer
The exit from Red Hat Virtualization 4.4 needs a destination chosen by workload type, because no single platform fits every RHV estate. The timing is fixed. RHV 4.4 maintenance ended on August 31, 2024, and its Extended Life Phase, the period in which no software fixes are delivered, ends on August 31, 2026. Any cluster still running 4.4 after that date will not receive software fixes, so the migration plan has to finish before then, or the team has to accept unpatched hypervisors while it works. This page compares five destinations: OpenShift Virtualization, oVirt, KubeVirt, Proxmox VE and OpenStack. It treats each one as a different operating model, not as a drop-in replacement for the RHV engine and its storage domains.
Start by sorting the estate into groups of VMs with similar requirements. Some groups will be traditional server workloads that need live migration, high availability and a familiar engine-style management model. Others may be Linux or Windows guests that a platform team already runs on Kubernetes, or small clusters where one web interface matters more than a large feature set. oVirt is the closest continuation of the RHV model, and its project website describes it as community-driven and open to contributions. KubeVirt and OpenShift Virtualization suit teams that already operate Kubernetes. Proxmox VE fits smaller or mixed estates. OpenStack fits larger estates that need multi-tenancy and self-service. For each group, record the storage domain it uses, its guest operating systems, its network dependencies and whether it depends on live migration.
Once the groups are defined, confirm the facts that will change the decision. Ask your Red Hat account team what support terms apply to your subscription through August 31, 2026, and what they cover after that date. Ask each candidate platform's vendor or community what support model it offers for your production use, and which hardware and operating system versions it certifies. Then pilot one workload group on each shortlisted destination, measure downtime and rollback steps, and set the cutover order cluster by cluster. The calendar is short for a full estate, so the first deliverable is a written inventory and a shortlist agreed by the infrastructure, security and application owners, not a completed migration.
What the end-of-life constraint requires from the replacement
The end of Red Hat Virtualization 4.4 support sets the minimum bar for any destination. Each card below is a requirement the replacement must meet, along with the questions to put to each candidate before you commit to a platform.
Security patching after the Extended Life Phase
Red Hat Virtualization 4.4 reaches the end of its Extended Life Phase in late August 2026, and that phase carries no software fixes. Any replacement needs a published security advisory process, a stated patch cadence and a clear route for fixes to the hypervisor, engine and management layer. Ask each vendor how advisories are published, whether community users receive fixes at the same time as paying customers, and how long each release line stays under security maintenance.
A migration path for VMs and storage domains
The move has two parts: the VM disks and configuration held in RHV storage domains, and the sequence that moves them with the least downtime. Forklift supports oVirt as a source for KubeVirt, including warm migration with changed-block tracking. Proxmox VE's built-in import wizard is documented for ESXi, so the route for RHV disks is exporting them and then using qm importovf or qm disk import. Confirm the export method, downtime per VM and the rollback step for each candidate.
A supported host and engine OS
The engine and hosts need an operating system that its vendor still maintains. oVirt 4.5.7 lists Red Hat Enterprise Linux 9 and 10 and CentOS Stream 9 and 10 as platforms, and oVirt Node 4.5 is based on CentOS Stream 9. Check which of these your hardware and drivers support and when each one leaves its own maintenance window. Ask whether the self-hosted engine can run on the same OS family as the hosts and how host OS upgrades are tested before rollout.
A clear support model
Support decides who fixes a production outage and how quickly. oVirt is community-driven, so production support comes from your own team, a partner or a commercial distributor. Proxmox VE sells per-socket subscriptions in four tiers with the same features, and the tiers differ in ticket allowance and response time. OpenNebula offers an annual subscription with SLA-based support. Ask each vendor for written response times, the escalation path and whether a subscription is required to receive security fixes.
Storage and live migration prerequisites
Moving VMs off RHV is only half the job, because the target has to run them the way they ran before. KubeVirt live migration requires a shared ReadWriteMany access mode for PersistentVolumeClaims and does not allow bridge pod networking. Proxmox VE high availability needs at least three cluster nodes, shared storage for guests and watchdog-based fencing. Ask each vendor which storage backends support live migration and what the cluster needs for recovery after a node failure.
Where RHV 4.4 support stops and what Red Hat's dates mean
Maintenance and the Extended Life Phase are two different dates, and your plan should treat them separately. Red Hat Virtualization 4.4 maintenance ended on August 31, 2024, which closed feature work and routine maintenance for the product. The Extended Life Phase runs until August 31, 2026, but it provides no software fixes, so your estate keeps running on the code it has today. Inventory every engine and host version now, and record which ones already sit beyond the point where a defect report would produce a code change.
What you lose after August 31, 2024 is more than new features. Without software fixes, a defect in the hypervisor, the engine or the storage integration will have no patch from Red Hat, and the workaround becomes your team's responsibility. Ask your Red Hat account team to confirm in writing what support remains during the Extended Life Phase, whether security issues are handled differently from other defects, and whether any contract terms change at August 31, 2026. Their written answer governs your planning, not this page, because lifecycle terms can be amended.
The upstream project is a second reference point. oVirt is where features are developed before they reach Red Hat's supported product, as described in an oVirt release announcement. That makes it a useful signal of where the code is heading, but oVirt is a community project, and no vendor is contractually bound to fix a defect for you on it. An exit to oVirt therefore needs a named internal or partner support path before cutover. Confirm the relationship between upstream and product releases, and the support lifecycle of any oVirt release you select, before you set a date.
Which destination fits which RHV estate
This table compares OpenShift Virtualization, oVirt, KubeVirt, Proxmox VE and OpenStack as exit destinations for RHV 4.4 estates. Read each row against your own deadline, storage layout and team skills, since the right answer depends on whether you need a like-for-like virtualization manager or a move to Kubernetes or a cloud platform. The main takeaway is that oVirt is the closest like-for-like path, while KubeVirt and Proxmox VE require different operating decisions.
| Factor | oVirt 4.5 line | KubeVirt on Kubernetes | Proxmox VE | OpenStack and OpenShift Virtualization |
|---|---|---|---|---|
| Deadline fit | Community line on the 4.5 release series, with ovirt-engine-4.5.7 the latest tag. Confirm support horizon with your own risk team. | Requires a Kubernetes platform first, so plan the cluster build before VM moves begin. | Migration wizard for ESXi exists, but RHV import paths need the qm importovf or qm disk import routes. Plan cluster-by-cluster. | Projects are large programs. Confirm timelines and support terms with the vendor before committing. |
| License | Apache License 2.0 for ovirt-engine, with no per-socket fee for the software itself. | Apache License 2.0. | GNU AGPL v3 for the software. Subscription tiers are priced per CPU socket per year. | Confirm license and subscription terms with each vendor, including OpenShift Virtualization entitlements. |
| Migration tooling from oVirt | Native like-for-like path with the same engine model. Confirm the exact upgrade steps for your RHV version. | Forklift lists oVirt as a source and supports warm migration with changed-block tracking. | Export VMs or disks from storage domains, then import with qm importovf or qm disk import. Test guest drivers. | Confirm with vendors which tooling covers oVirt sources, since Forklift is the documented route for KubeVirt-based targets. |
| Storage requirement | Storage domains continue in the same model. Confirm supported storage backends for your array. | Live migration needs ReadWriteMany access mode for VMs using PersistentVolumeClaims. Check your CSI driver. | Supports local LVM, ZFS, and network storage such as iSCSI, NFS, and Ceph RBD. High availability needs shared storage. | Confirm the Ceph or shared storage design with the vendor and your storage team. |
| Operating model and trade-offs | Keeps the VM-centric model familiar to RHV admins. Your team carries patching and support without Red Hat. | Shifts VMs into Kubernetes operations. Choose it only if your platform team already runs Kubernetes at scale. | Single web interface and clustering in one product. High availability needs at least three nodes and watchdog fencing. | Best suited to multi-tenant or self-service needs. Expect a larger operating burden and a longer project plan. |
Choosing a destination by estate size and team skills
If your estate is mostly traditional virtual machines, your team runs Linux and a few hypervisor hosts, and nobody on staff wants to operate a Kubernetes cluster, the most direct destinations are oVirt, which keeps the RHV engine model, and Proxmox VE, which combines KVM and LXC with clustering and a web interface in one product. Proxmox VE is the more common choice for small teams because it is a single product with a shorter learning curve, while oVirt suits teams that want the closest upstream of RHV.
- Required skills: Linux administration, KVM concepts, storage configuration (LVM, NFS, iSCSI, or Ceph) and basic network bridging.
- Engine placement: oVirt installs its Engine as a self-hosted virtual machine on a host, so plan for that layout before you start.
- Clustering: Proxmox VE high availability needs at least three cluster nodes, shared storage and watchdog-based fencing.
- Support model: Confirm whether you will rely on community resources or buy a subscription with support tickets and response times.
- Ongoing work: Operating system upgrades, patching and backups stay with your team in both cases.
Before choosing, confirm your host hardware, storage type and the support tier you need, and test the destination with a non-production cluster.
If your application teams already deploy on Kubernetes or plan to, KubeVirt lets you run VMs beside containers on the same cluster, and Forklift can migrate VMs from oVirt to KubeVirt. Harvester, which is built on Kubernetes, KubeVirt and Longhorn, is another option when you want a hyperconverged appliance-style platform with Kubernetes underneath. This path changes the work your team does, because VMs become Kubernetes objects managed through the same tooling as containers.
- Required skills: Working Kubernetes knowledge, including cluster upgrades, RBAC, networking and persistent storage.
- Storage for live migration: KubeVirt live migration requires a shared ReadWriteMany access mode for PersistentVolumeClaims, so confirm your storage backend supports it.
- Network limits: Live migration is not allowed with a pod network bridge interface, so plan your VM networking early.
- Platform ownership: Decide whether platform engineering or the virtualization team owns the cluster and its lifecycle.
- Component versions: Check the current KubeVirt and Harvester release notes, since both move quickly.
Confirm whether your guests and their drivers suit a Kubernetes-based runtime, and pilot a few non-critical VMs before moving the estate.
Larger estates that need multi-tenancy, quotas, self-service provisioning or several hypervisor types under one management layer usually look at OpenStack or Apache CloudStack, and at OpenNebula where an enterprise subscription with SLA-based support is preferred. These platforms add a control plane with its own database, identity integration and networking model, so the decision is as much about the team you can staff as about the hypervisor underneath.
- Required skills: Dedicated platform engineers who can run the control plane, plus storage and network specialists.
- Multi-tenancy design: Define tenants, projects, quotas and network isolation before migration starts.
- Hypervisor mix: CloudStack can orchestrate vSphere, KVM, XenServer and Hyper-V during a phased move, which helps when several platforms coexist.
- Operating cost: The people who run the control plane are a recurring cost that small estates rarely need to carry.
- Migration sequencing: Plan cluster-by-cluster moves with a clear rollback path for each workload group.
Ask prospective partners and vendors to describe the operations staffing they expect, and confirm how your current identity, backup and monitoring tools integrate with the chosen control plane.
How to plan and run the exit before August 31, 2026
The sequence turns an open-ended migration into a dated, tested program that moves each cluster with a rollback path before Red Hat Virtualization support ends. The output is a decommissioned RHV estate with every workload verified on its destination.
Inventory VMs, hosts and storage domains
The RHV administrator exports a list of every VM, template, host, cluster, data center, network and storage domain, with its operating system, disk sizes, snapshot count, and whether it depends on a license or a hardware feature. Application owners confirm which workloads are business critical, which can be retired, and which need a change window. The step is done when the inventory has an owner and a recommended wave for each item, and the team agrees on which items will not move.
Choose the destination for each workload group
Architects compare the candidate platforms (oVirt, KubeVirt through Forklift, Proxmox VE and OpenStack) against the inventory, focusing on the skills the operations team already has, the storage the estate depends on, and whether containers or multi-tenant self-service are needed. Different clusters may land on different platforms, but each choice should be recorded with its reasoning. The step closes with a signed decision record per workload group, including the support model the destination will use after August 31, 2026.
Build a test cluster that mirrors production
The team builds a non-production environment on the chosen platform with the same network segmentation, storage type, authentication source and backup tooling as production, using a representative subset of hosts. Installers and host operating systems are confirmed against the platform's current support matrix before anything is installed. Integration with monitoring, backup, identity and change management is tested here. The step is done when a reference VM can be built, patched, backed up and restored end to end on the test cluster.
Prove migration on a pilot wave
The team selects a small set of low-risk VMs that cover the main guest operating systems, disk types and network layouts, then migrates them using the method chosen for the destination, such as warm migration where the tooling supports it, or a cold export and import otherwise. Each VM is checked for boot, drivers, network reachability, application health and performance against its pre-migration baseline. Rollback is rehearsed by reverting one VM to RHV. The step closes when the pilot results are written up and the team accepts the runbook for the next waves.
Migrate cluster by cluster in waves
The team moves one RHV cluster at a time, starting with the least critical and ending with the most sensitive, and schedules change windows with each business owner. Each wave follows the rehearsed runbook, keeps RHV copies until the workloads pass acceptance checks, and records any deviations. Limits that apply to a destination, such as shared storage requirements for live migration on KubeVirt or the import constraints that Proxmox VE documents for VMware sources, shape which VMs move in which wave. The step is done for a cluster when every workload is verified on the destination and its backups run successfully there.
Decommission RHV and retain evidence
Once all waves are accepted, the team shuts down the RHV engine and hosts, archives the engine database and configuration backups under the retention rules the organization requires, and wipes or repurposes storage that held customer or regulated data. Access, certificates, DNS entries and monitoring checks tied to RHV are removed. Auditors or internal risk teams receive the migration records, test results and disposal evidence. The step closes when the decommissioning checklist is signed and no production workload depends on RHV.
Evidence to keep for the exit and for auditors
The exit from Red Hat Virtualization 4.4 produces a trail of records that the next platform, your operations team and any later assessor will need. DeployOpen prepares this evidence as part of the migration work, but independent auditors and certification bodies are the ones who issue any assessment or certification.
Verified VM and storage inventory
Keep a dated export of every VM, template, disk, network and storage domain in the RHV engine before the first move, with owner, classification and dependency notes. Reconcile it against the target platform after each wave so that no guest is missing or duplicated. Ask whether vSAN-backed or snapshot-heavy disks need separate handling on the destination, since those affect the import path you choose.
Migration test results with rollback proof
For each pilot and production wave, record the source and target configuration, the import method, boot and application checks, and the time the cutover took. Keep proof that the source VM was left intact so you can roll back, including the test you ran to confirm it. Treat a migration without a documented rollback as incomplete, even if the guest booted on the first attempt.
Patch and support records for the new platform
Once oVirt, KubeVirt, Proxmox VE or OpenStack is in production, keep a register of the versions running on each host and engine, the patch dates applied and the support status of each component. Note which support is community, vendor subscription or internal, and confirm the lifecycle of the chosen release with its vendor or project. This record shows who is responsible for fixes after the Red Hat Extended Life Phase ends.
Backup restore tests
A backup that has never been restored is an untested assumption. Keep logs of restore tests on the new platform for representative VMs, covering full restores, file-level recovery and restores into an isolated network. Record the restore time and any gaps found, and repeat the test after changes to storage or backup software. Confirm the backup tool supports your target hypervisor before you rely on it.
Access control and user management configuration
Export the role, group and permission model from RHV and map each entitlement to the new platform, noting where roles do not carry over one to one. Keep the approved configuration, the list of administrator accounts and the review date for each. Auditors will ask who can create, change or delete VMs, so this record should match your identity provider and admin access logs.
What teams ask about RHV exit cost, effort and support
What drives the cost of leaving Red Hat Virtualization?
The cost is driven by components, not by a single license fee. The main lines are staff time for planning and migration, hardware for the destination cluster, storage (whether that is Ceph, ZFS, iSCSI or NFS), any paid support subscription you choose, and training. Subscription savings depend on what you pay today and what you pick next, so compare the full three-year cost of each destination rather than only the license line. Ask any vendor or partner for a quote that separates one-time work (planning, migration, testing, hardening) from recurring items (support, upgrades, backups, retainers). Costs fall when you reuse existing hardware and staff skills, and rise when the destination needs new storage or a longer parallel run.
Is oVirt supported in production, and who supports it?
oVirt is a community-driven upstream project, so there is no vendor support contract built into it. The ovirt-engine repository is licensed under the Apache License 2.0, and the most recent tag is ovirt-engine-4.5.7, dated December 17, 2025. Production support therefore has to come from your own staff, from a commercial partner that agrees to support it in writing, or from a community you trust. Confirm which host operating systems are supported for your engine version, since the oVirt download page lists RHEL and CentOS Stream releases, and confirm the support scope in writing before you commit.
Are Proxmox VE subscriptions priced per socket, and what do the tiers include?
Yes. Proxmox VE subscriptions are priced per CPU socket per year. The published tiers are Community at 120 euros (no support tickets), Basic at 370 euros (3 tickets, 1 business day response), Standard at 550 euros (10 tickets, 4-hour response) and Premium at 1,100 euros (unlimited tickets, 2-hour response), according to the Proxmox VE pricing page. Every tier includes the same software features. The tiers differ in support entitlements and access to the enterprise repository, which the vendor recommends for production. The software can run without a subscription, but the no-subscription repository is aimed at testing and non-production use, so budget for a tier if you plan production use with vendor support.
How long does an RHV migration take, and what sets that timeline?
No duration can be given from the supplied facts, because it depends on your estate. The main factors are the number of VMs and total disk size, how many clusters and storage domains you move, whether you use warm or cold migration, the network path between old and new storage, guest driver and OS changes, and how many application owners must sign off on testing. Move one cluster at a time, and keep a rollback path until each wave is verified. Ask for a timeline in any quote that lists the waves, the test gates and the work each wave needs from your side, rather than a single end date.
What does the migration need from our own staff?
Your staff hold the knowledge of the workloads, so they are needed for inventory, dependency mapping, application owner sign-off, change windows and cutover decisions. Engineers also need to own the new platform after handover, including storage, networking, backups, monitoring and patching. Plan for named owners in each area and for time away from routine work during planning and cutover. For Proxmox VE, note that high availability needs at least three cluster nodes, shared storage and watchdog-based fencing, so your network and storage teams must be part of the design early.
Can our internal team do the RHV exit alone?
Often yes for small estates, but it depends on skills and capacity. A team that already runs Linux, KVM and storage can plan and execute a single-cluster move with good documentation and a test environment. Larger estates, tight deadlines and regulated workloads usually benefit from an outside implementation partner for planning, migration tooling, hardening and evidence for compliance reviews. DeployOpen works on fixed-scope engagements with scope, deliverables and timelines agreed in writing before work starts, and offers retainers for ongoing support and upgrades. Ask any partner, including DeployOpen, for a written scope that names what your team must do and what the partner does.
What risks should we check before choosing a destination?
Check four risks early. First, confirm that your hardware, NIC and storage are supported by the destination, since Proxmox VE can import from ESXi but this page's sources do not cover RHV-specific import, so each path needs its own test. Second, confirm support scope for the destination in writing. Third, test backups and restores on the new platform before any VM moves. Fourth, confirm that applications and guest drivers work after conversion. Ask each candidate to show a working test migration of one representative VM and to document the rollback steps.
How DeployOpen approaches the exit
The exit starts with a written scope, not a platform choice. DeployOpen plans the move inside your own cloud accounts, data centers or air-gapped network, and the scope, deliverables and timeline are agreed in writing before work begins. For an RHV 4.4 estate, that scope usually covers an inventory of hosts, storage domains, networks, VM dependencies and backup jobs, plus a decision on the destination. Ask any provider to show how they will handle the August 31, 2026 end of the Extended Life Phase, including the date by which the cutover must finish and what happens if a pilot cluster slips.
The build phase is where the chosen platform is installed, integrated and hardened. Depending on the destination, this can mean a self-hosted oVirt engine, a KubeVirt cluster with a Forklift migration path, a Proxmox VE cluster or an OpenStack deployment. DeployOpen configures identity, network segmentation, storage redundancy, backup targets and access controls, and then runs a restore test before any production VM moves. Confirm with the implementer which hardening baseline they apply, who signs off each change, and where the configuration and runbooks are stored.
Ongoing support is sold separately as a retainer, so the platform stays patched and supported after the project closes. The handover package should include architecture and network diagrams, recovery procedures, change records and a list of open risks. DeployOpen also prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so ask your independent auditor early which evidence they will require. Request a written quote that separates one-time project work from recurring retainer fees.
