Red Hat Virtualization vs oVirt: which to choose

Red Hat Virtualization vs oVirt: when each option fits

Your RHV 4.4 estate reaches the end of its Extended Life Phase on August 31, 2026, and the decision in front of you is whether to stay with a Red Hat supported product or move to oVirt, the community upstream project. Red Hat Virtualization fits organizations that need vendor-backed support and a single accountable party for the hypervisor, the engine and the escalation path, especially where an auditor or board expects a named supplier on every layer. oVirt fits teams that already have strong Linux and virtualization skills in house, or a partner who can carry support contractually, and that accept the community release cadence as a standing operating condition. The upstream project is where new features are developed before they reach Red Hat's supported offering, so the trade is between vendor commitment and a faster, less predictable update stream.

Start by pulling your own support obligations. Ask who you call at 2 a.m. when a host fails, who writes the patch if a CVE lands in the engine, and whether your contracts or regulators require a vendor on the hook. Then check the host operating system path, because the oVirt download page lists RHEL 9 and 10 and CentOS Stream 9 and 10 for both the Engine and hosts, and oVirt Node is based on CentOS Stream 9. Confirm which of those your hardware and security baseline can run, and whether the target matches the operating system lifecycle your organization already tracks. Review the ovirt-engine tags and recent commits yourself to judge release activity, since the most recent tag is ovirt-engine-4.5.7 from December 17, 2025, following 4.5.6 from February 12, 2024.

Finally, weigh compliance needs and internal skills against each other. A compliance assessment will ask how you patch, test and evidence changes, and the answer must come from your own process whichever option you choose, because DeployOpen prepares controls and evidence but does not issue audit reports or certifications. The decision turns on four questions: the support obligations you must meet, the supported host operating system path you can maintain, the compliance evidence your assessors expect, and the skills your team can keep for the life of the platform. If two or more of those answers point to a vendor, stay supported. If your team can honestly carry the engine, the hosts and the upgrade cycle, oVirt is a credible destination.

Which option fits which scenario

This table matches common RHV exit situations to oVirt or to a nearby alternative. Read each row as a condition: the fit holds only while the stated condition is true, so check it against your own contracts, team and network before deciding.

Scenario	Better fit	Why
Regulated buyer that needs a contracted support party	oVirt only with a commercial support contract from a third party, or another platform with a vendor SLA	oVirt is community-driven, so production support is not provided by the project itself. Confirm in writing who answers a severity-one incident and within what response terms before choosing it.
Team with strong Linux operations and capacity to self-support	oVirt	The engine, KVM hosts, OVN networking and Ansible automation are open components. The fit holds if your team can run upgrades, patch hosts and troubleshoot the self-hosted engine without a vendor escalation path.
Estate that must leave RHV quickly	Proxmox VE or a migration tool path via Forklift to KubeVirt, rather than a full oVirt rebuild	An oVirt move means new hosts, a new engine and storage domain work on a supported line. If the deadline is close and the team is small, a destination with a simpler import path may reduce the number of platform changes.
Air-gapped sites	oVirt, provided mirrors of packages, OS images and the engine can be built and approved offline	oVirt installs from the command line and can run on hosts you control. Confirm that every dependency, including the host operating system and update channel, can be mirrored into the enclave before committing.
Organization already standardized on Red Hat Enterprise Linux	oVirt on RHEL 9 or 10 hosts, if your RHEL subscription and support terms cover the hosts	oVirt lists RHEL 9 and 10 among its supported platforms for the engine and hosts. Your existing RHEL operations, patching and skills carry over, though the virtualization layer itself remains community-supported.
Organization that expects a hypervisor vendor to own patches and upgrades	Vendor-backed alternatives such as Nutanix or OpenShift Virtualization, if commercial support is a hard requirement	oVirt keeps the RHV code base but changes who is accountable for fixes. Use this row to test whether that accountability model is acceptable to your risk committee.

What oVirt keeps from RHV and what it does not promise

oVirt is the community upstream project from which Red Hat has developed its virtualization product, and its own materials name the KVM hypervisor, OVN networking, high availability and Ansible automation as its core components. It is community-driven and open for pull requests, and new features are developed there before they reach Red Hat's supported offering. The ovirt-engine code is licensed under the Apache License 2.0, so the management plane itself can be read, built and changed by your own engineers. That openness is the main thing oVirt keeps from RHV: the code base and its lineage, not a support contract.

What oVirt does not promise is the packaging, certification and support commitments that come with a Red Hat subscription. Do not assume that a feature present in RHV behaves the same way in oVirt, or that a configuration validated by Red Hat has been validated by anyone for your hardware. Before you commit to a target version, list the RHV features your estate depends on, such as specific storage domain types, networking configurations, fencing setups and external integrations, and check each one against the oVirt release notes for that version. Record anything that is missing, changed or unclear as a gap to test, not as a fact to assume.

Treat that check as the first deliverable of the migration plan. Ask your team to confirm, in a lab built from your own configuration, that each dependency works on the chosen oVirt and host operating system combination, and to write down who will fix a defect in that combination if one appears. Because oVirt has no vendor obligation to you, that owner must be named inside your organization or in a support agreement with a third party. Pages on the exit timeline and sibling migration paths cover the sequencing; this decision decides whether oVirt is a sound destination for your estate at all.

What changes without Red Hat support

Moving from Red Hat Virtualization to oVirt keeps the engine and hypervisor code but removes the vendor contract behind them. The cards below cover the operational gaps that appear once a Red Hat subscription no longer answers patch, incident and evidence questions, and what to confirm before the Extended Life Phase ends.

No vendor patch commitment

Under RHV, fixes arrived through a Red Hat subscription with a defined support path. With oVirt, fixes arrive as community releases, and there is no vendor-issued patch timeline you can write into a change board decision. Illustrative case: a security fix lands in the upstream tree, but your team must still build, test and schedule it. Ask any commercial partner you consider whether they commit to a patch window for oVirt 4.5 engines and hosts, and in writing what that window covers.

Host OS lifecycle ownership

oVirt Node is based on CentOS Stream 9, and oVirt 4.5.7 lists RHEL 9 and 10 and CentOS Stream 9 and 10 as supported platforms. Your team owns the host operating system lifecycle, kernel updates and driver compatibility, which RHV customers previously tracked through Red Hat's matrix. Confirm which host OS and engine OS combinations you will run, and who signs off when a host OS release leaves the supported list.

Production incident response

Without a support contract, incident response becomes an internal rota plus whatever community channels you can reach. This matters most for clusters carrying databases, identity services or regulated workloads, where an engine outage blocks change and recovery. Document who triages engine faults, who can access the self-hosted engine VM, and the escalation path to a paid partner. Ask for named responders, response targets and after-hours coverage in the written scope.

Compliance evidence and certification

Auditors will ask which software version runs in production, how it was patched, and who approved each change. oVirt is Apache-2.0 licensed and its source is public, but it does not come with a vendor-issued certification or attestation that you can attach to an assessment. Your team must build the evidence trail for the platform, from version inventory to patch records. Ask any partner which evidence artifacts they will produce and which control areas they will not cover.

Upgrade planning across releases

oVirt follows a community release line, and new features are developed upstream before they appear in Red Hat's supported product. Plan each upgrade as a project: check engine and host compatibility, test the self-hosted engine upgrade on a non-production cluster, and confirm the rollback path before touching production storage domains. Ask whether the release you choose will receive maintenance updates long enough to match your planned exit from RHV.

Staffing and partner coverage

The real operational cost is people. A small platform team that knows the engine, the self-hosted setup and the storage domain layout can run oVirt well, but staff turnover or leave can leave a cluster without anyone who can recover it. Decide early whether to build internal depth, retain an implementation and support partner, or both. Ask any partner for named engineers, documented runbooks and knowledge transfer deliverables before you sign.

Who supports oVirt in production

oVirt is a community-driven project, so there is no single vendor that carries production support by default. Red Hat's support contract for RHV does not transfer to oVirt, and the oVirt project does not sell an SLA. In practice, production support comes from one of three places: your own platform team, a commercial partner that agrees to operate or troubleshoot oVirt, or a third-party support contract from a provider that works with the upstream code. Decide which model you are using before the Extended Life Phase ends, because the answer determines who you call at 2 a.m. when a host fails to rejoin the cluster.

Ask every provider you consider for a written scope that names what they cover: the Engine, hosts running oVirt Node or a supported operating system, the self-hosted engine, storage domains, networking and backup integration. Ask who is named on each responsibility, what the response and escalation path looks like from first call to a senior engineer, and whether they will patch the Engine and hosts on a schedule you agree. Also ask which oVirt releases they support, since the most recent ovirt-engine tag is 4.5.7, and whether they commit to following later fixes. Vague wording such as "best effort" should be treated as no support.

Verify current support options directly before you sign. Check the oVirt community channels and documentation for active maintainers and release activity, and confirm with any provider which community versions and host platforms they can support in your environment. Treat that verification as a standing check, not a one-time task. Your team should also document what it will handle without outside help, so that a provider's scope and your internal runbook cover the same failure modes.

Hosting, data control and identity implications

In a data center you own, the oVirt Engine, the hypervisor hosts and the storage domains all sit on hardware your organization controls. You decide where the self-hosted engine VM lives, which storage backs the data and domains, and how hosts are patched. oVirt runs on the Red Hat Enterprise Linux and CentOS Stream family, so the operating system lifecycle and kernel patching become your responsibility rather than a vendor's support queue.

Engine placement: The self-hosted engine runs as a virtual machine on a host, so plan a separate management network and a way to recover the engine if its host fails.
Storage domains: Identify which NFS, iSCSI, Fibre Channel or Gluster domains hold the data and confirm that each one is backed up independently of the hypervisor.
Backups: Your team holds the keys to backup repositories and must test restores of VMs and the engine database, since no vendor restores them for you.
Identity integration: Connect the engine to your directory service and record which administrator groups can change clusters, storage and users.
Audit logging: Forward engine and host logs to your central log store so changes are traceable without depending on the platform's own retention.

Before cutover, ask your security team to document who can reach the engine web interface, API and hosts, and to confirm that these controls match your existing access policies.

Cost components on each side of the decision

Moving off Red Hat Virtualization changes who gets paid and when. The cards below separate the Red Hat subscription from the open-source software, the staff and hardware that run it, and the one-time migration and parallel-running costs that appear during cutover.

Red Hat subscription fees

Red Hat charges for RHV through subscriptions, with the subscription tier and the number of hosts or sockets covered as the main inputs. The cost recurs at each renewal, and the Extended Life Phase that ends August 31, 2026 is the date to plan around. Ask the account team for the exact subscription line items, the tier covering your hosts, and what the renewal price is for a term that ends before your planned exit. Confirm whether any extension is available and at what cost.

oVirt software cost

oVirt is licensed under the Apache License 2.0, so there is no software license fee to pay. The recurring costs are the staff who install, patch and upgrade the Engine and hosts, plus the server, storage and network hardware those hosts need. Your own hardware refresh schedule determines when those costs land. Budget for the operating system platform underneath, since oVirt Node is based on CentOS Stream 9, and confirm which platform your hosts will run.

Internal engineering time

Without Red Hat support, your own engineers own upgrades, patch testing, troubleshooting and the knowledge of the self-hosted engine. This is a recurring cost measured in staff hours, and it grows with the number of clusters, hosts and custom integrations. Ask your team to estimate hours per month for patch cycles, upgrade rehearsals and on-call coverage, then compare that figure with the hours you spend on RHV today. Skills concentration is a risk that does not appear on an invoice.

Third-party support contracts

If you choose a third-party support provider for oVirt in production, that is a recurring fee tied to scope, response expectations and the number of environments covered. Compare the written support scope with what your current Red Hat subscription covers, including engine and host issues, upgrade assistance and escalation paths. Ask each provider which oVirt versions and host operating systems they support, how they handle the self-hosted engine, and whether their terms are fixed for the contract period.

Migration project labor

Migrating storage domains, VMs, networks and the engine is a one-time project cost, paid to your staff, an implementation partner or both. It scales with the number of VMs, the number of storage domains, custom networking and the number of change windows you need. Ask any partner for a fixed-scope written proposal listing deliverables, testing steps, rollback procedures and acceptance criteria, so you can compare offers on the same basis.

Parallel running during cutover

During cutover, RHV and oVirt, or RHV and the destination platform, must run side by side. Both carry hardware, power, licensing or support costs for the overlap period, which lasts until the last VM is verified and the old estate is retired. Shorten the overlap by moving workloads in tested waves, and confirm with Red Hat how long your subscription stays active at the point you need it. Each week of overlap is a cost that a written cutover plan should show.

How a move from RHV to oVirt involves your team

The sequence turns an RHV estate into a tested oVirt 4.5 environment, with each cluster moved only after its backups, guest drivers and rollback path have been checked. The detailed procedure lives on the migration page for oVirt.

Inventory hosts, engine and storage domains
Record every RHV host, the Manager (engine) version, clusters, data centers, storage domains, networks and the VMs on each. The virtualization lead and the storage administrator own this list, and each VM is tagged with an owning application team. The step is done when the inventory is reviewed and signed off by those owners, and every VM has a named business owner and a target cluster.
Confirm the oVirt 4.5 line and host OS path
Confirm which oVirt 4.5 release you will target, the supported Engine and host platforms listed on the oVirt download page, and whether hosts will run oVirt Node, which is based on CentOS Stream 9. Ask your platform team and your security team to approve the operating system path, including how patches will be sourced after RHV support ends. The step closes with a written decision record that names the release, the host OS and the patch source.
Build a test environment
Stand up a non-production oVirt environment that mirrors the production network, storage type and host hardware as closely as your budget allows. The platform team builds it, and application owners supply test VMs that represent each workload class. Confirm that VM creation, live migration, high availability restart and backup jobs work on test hosts. The step is complete when a documented test run passes and the open issues list is owned by named people.
Plan the self-hosted engine installation
Design the self-hosted engine deployment: the dedicated hosts that will run the Engine as a virtual machine, the engine VM storage, the network layout, DNS and certificate names, and the Engine backup schedule. The platform team writes the plan and the security team reviews access, certificates and administrator accounts. The step is done when the plan is approved and an installation runbook exists with a rollback step for the Engine.
Move storage domains and VMs
Attach or reconnect the storage domains to the new oVirt environment and move VMs in waves, starting with low-risk workloads. The virtualization team runs each wave with the application owner present, records the method used for each VM and checks network and storage mappings after every move. Confirm that Forklift is not part of this path unless you plan a later move to KubeVirt. The wave is done when each VM boots, passes the owner's functional check and is recorded in the inventory.
Validate backups and guest drivers
Run a restore test on a sample of VMs from every class, using the backup product your team chose for oVirt. Check that guest tools, virtio drivers and network configurations work on the new hosts. The backup owner and the application owners sign the results. The step closes when restores have been tested successfully for each workload class and the signed results are filed with the change record.
Cut over cluster by cluster
Move production clusters one at a time, with a defined change window agreed by the application owners, the operations lead and the service desk. Keep the RHV cluster available as a rollback path until the cutover is accepted. The operations lead owns the go or no-go decision. The cluster is cut over when all its VMs are running on oVirt, monitoring shows normal operation and the owners confirm acceptance in writing.
Decommission RHV after acceptance
Once every cluster has been accepted, remove RHV hosts from service, archive the Manager configuration and final backups according to your retention policy, and wipe or repurpose hardware under the asset owner's approval. The IT governance lead confirms that the archive and any licensing obligations are closed. The step is complete when the decommission record is filed and no production workload depends on the RHV Manager.

Deciding before the Extended Life Phase ends

Start with the timing constraint. Red Hat Virtualization 4.4 maintenance ended on August 31, 2024, and its Extended Life Phase, the period with no software fixes, ends on August 31, 2026. Work backward from that date. Three decisions come first, in this order: the support model you will accept for production, the target platform, and the window in which you can test a full migration on a copy of your estate. Each decision narrows the next. If you decide the target before the support model, you may pick a platform whose production support does not match your risk tolerance. If you leave testing until late, you will discover storage domain or network mapping problems when there is no time left to fix them. For the support model, the core question for oVirt is who answers production incidents. oVirt is community-driven, and its releases come from the upstream project, not from a vendor support contract. Confirm in writing whether your organization will staff this internally, buy support from a third party, or accept a platform with a commercial vendor behind it. Ask the same question of every candidate, because a support agreement is often the largest recurring cost in the comparison. Also confirm which operating systems your hosts and Engine will run, since the oVirt download page lists specific Red Hat Enterprise Linux and CentOS Stream versions that you should check against your own patch policy. Alternatives such as Proxmox VE, OpenStack and KubeVirt are covered on the sibling pages linked from this section, and the choice among them depends less on features than on your workload mix and your team's skills. Stateful virtual machines that the business runs as-is point toward a KVM-based hypervisor with minimal change. Cloud-native workloads, or teams already operating Kubernetes, point toward KubeVirt. Multi-tenant self-service points toward OpenStack. Inventory your VMs by type, count the operators who can run each platform under pressure, and let those two lists choose the target.

Questions buyers ask before moving from RHV to oVirt

How much does moving from RHV to oVirt cost?

Moving to oVirt has no license fee for the software itself, so the cost is the labor, hardware and time needed to run the move. The main components are internal staff hours, any outside engineering help, new or repurposed hosts that run a supported operating system, storage capacity for copying VM disks during migration, and training. The main cost drivers are the number of clusters, the number of VMs and disks, how much custom integration exists, and whether the team already runs Linux and KVM. Ask any partner for a quote built from a written scope that lists these components separately, and ask which parts recur, such as support or upgrades, and which are one-time, such as the engine installation and data moves.

How long does an RHV to oVirt migration take?

Duration depends on the size and layout of the estate, not on a fixed rule. The factors that set it are the number of clusters and hosts to rebuild, the number of VMs and total disk size to move, how many VMs can be stopped in each window, how much testing each application needs, and how many change approvals the business requires. Your timeline should also account for the Extended Life Phase end date of August 31, 2026, which is fixed for RHV 4.4. Confirm the plan with your own inventory and test results rather than a generic estimate, and ask any provider to show the sequence of clusters, rollback points and cutover windows before agreeing a schedule.

What does the internal team need to know before starting?

The internal team needs working knowledge of Linux administration, KVM, networking, storage domains, and the oVirt engine and host lifecycle. Staff should be able to read oVirt documentation, run installation commands, manage the self-hosted engine, and troubleshoot host and storage issues. They also need to own the decisions that remain theirs: change control, backup policy, monitoring, and access management. Before the project starts, inventory which people will operate the platform after handover and whether they have time to learn it during the migration. If that skill set is thin, plan for training or outside help from the start.

Can our own team migrate from RHV to oVirt without outside help?

Yes, many teams with strong Linux and virtualization skills can do this themselves, since oVirt is installed from the command line and its self-hosted setup runs the engine as a virtual machine on a host. The questions to answer honestly are whether the team can test rollback, whether it has time away from current operations, and whether it can support the platform after the move. Outside help is most useful for scoping, for hardening and backup design, for testing, and for documenting the result. Any engagement with DeployOpen would begin with a written, fixed scope that defines deliverables and timelines before work starts.

Is oVirt safe to run in production?

oVirt is licensed under the Apache License 2.0 and its most recent ovirt-engine tag is ovirt-engine-4.5.7, dated December 17, 2025, after ovirt-engine-4.5.6 on February 12, 2024. The project is community-driven and open for pull requests, and it describes itself as the upstream project where features are developed before they enter Red Hat's supported product. That means there is no vendor-backed support contract unless you buy one from a third party. Production readiness therefore depends on your own testing, patch process, backup and recovery design, and staffing. Review the release history and your support options with the project and any provider before deciding.

Which host operating systems does oVirt support?

The oVirt 4.5.7 download page lists Red Hat Enterprise Linux 9 and 10 or similar, and CentOS Stream 9 and 10, as platforms for both the Engine and hosts. Hosts can also run oVirt Node, a minimal operating system based on CentOS Stream 9, with oVirt Node 4.5 as the current stable release. Confirm the exact package and version combinations on the download page before you build hosts, and check that your hardware, drivers and storage adapters are supported on the chosen operating system. Keep the host OS version in your change plan, since it determines which oVirt release you can run.

What happens to existing VMs during the move?

Existing VMs stay on the RHV environment until each one is moved, so you can run both platforms during the transition. The move involves exporting or copying disks, recreating network and storage mappings in the oVirt environment, and validating each guest after boot. Expect configuration checks such as guest drivers, network interface names and access to storage. Plan a rollback point for each VM, keep the source copy until acceptance testing passes, and move clusters in stages. Confirm the exact procedure, including how storage domains are attached and what downtime each step requires, with your platform team and in a test cluster before cutover.

Sources to check before deciding

Start with the primary sources, because the oVirt project describes itself on its oVirt website as community-driven and open for pull requests, with KVM, OVN networking, high availability and Ansible automation as its core components. Read that page alongside the oVirt download page, which lists the supported Engine and host platforms for the 4.5 line. Confirm that the operating system versions your hosts will run appear there before you order hardware or plan a rebuild. The download page also explains that hosts can run oVirt Node, a minimal image based on CentOS Stream, so decide early whether you will use it or a general-purpose Enterprise Linux host.

Next, verify the license terms yourself. The ovirt-engine code is Apache License 2.0, and the tags list shows the most recent release, which you should compare against your target version. Check the dates on the tags against the maintenance window you plan, and review the commit history for the components your estate depends on, such as storage and networking. Community activity is a fact you can measure directly, so do not rely on a summary when the repository can answer the question.

If you plan to move VMs with Forklift, read the kubev2v/forklift repository to confirm which source providers and warm migration paths it currently supports. Forklift lists oVirt as a migration source for KubeVirt, which matters if you may later leave the hypervisor layer entirely. Finally, support terms are the one question this page cannot settle. Ask Red Hat in writing what it will and will not cover after the Extended Life Phase, and ask any oVirt-based vendor you consider for its written support scope, response targets and who is accountable for production incidents.

How DeployOpen helps evaluate, implement or migrate

DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, including oVirt. For Red Hat Virtualization customers, we start by testing whether oVirt fits your host, storage and support requirements before any production cutover.

How we scope

Written scope covers current RHV cluster, storage domain and host inventory, and the oVirt target version you agree on.
We confirm supported host operating systems and engine platform against your own hardware and support plan before work starts.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing; a quote follows from that scope.

How we build

We install and configure the oVirt engine, self-hosted engine and hosts in your cloud accounts, data centers or air-gapped networks.
Storage domain, network and high availability configuration are tested against your failure scenarios in a non-production environment first.
Backup and recovery procedures are built and restore-tested before any VM is moved from RHV.

How we hand over

You receive architecture, runbooks, configuration records and the migration test results for your own operations team.
Documentation records which controls and evidence your compliance assessor may ask for, while audit conclusions remain with independent auditors.
Handover includes a walkthrough of upgrade paths so your team knows how to track oVirt releases and their own patch decisions.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
A retainer can cover monitoring of oVirt release activity, patch testing and periodic restore tests in your environment.
Ask any provider, including DeployOpen, which party carries production support obligations and what response terms apply in writing.

Red Hat Virtualization vs oVirt