Migrate from Red Hat Virtualization to oVirt

Migrate from Red Hat Virtualization to oVirt: what the move involves

The move is an engine, host and storage domain migration, not a rebuild of the guest workloads. If your team runs RHV 4.4 hosts and a Manager, the work is to stand up a new oVirt Engine, install oVirt Node or a supported Enterprise Linux or CentOS Stream host operating system on each host, and move storage domains and virtual machines into the new data center. Guest operating systems and applications do not need to be re-architected. Plan to verify guest drivers and agents after each VM moves, and confirm the exact host and engine operating system combinations on the oVirt download page before you order hardware or write the build standard.

The platform team usually owns the work and brings in an implementation partner for the parts it has not run before, such as the self-hosted engine installation, storage domain cutover and a tested backup and restore path. Effort depends on the number of clusters and hosts, the storage type behind each domain, the network design and how many VMs need downtime planning. The main costs are internal staff time, partner work under a written fixed scope, a test environment, and any spare hardware needed for rolling host replacement. oVirt's engine is licensed under Apache License 2.0, so the software itself carries no license fee. The recurring costs are patching, monitoring, backup and any third-party support contract you choose to buy.

oVirt is the upstream community project where Red Hat develops features before they reach its supported product, so it is a community product without Red Hat support. The most recent engine release tag is ovirt-engine-4.5.7, dated December 17, 2025, and that is the line to test against. Before you commit, confirm with your team or partner who will answer production incidents, how security fixes reach you, and which platform versions the project supports on the dates your cutover needs. Your risk sits mostly in storage and the cutover window, and the decision is whether your team, or a partner under contract, will carry the support duty Red Hat carries today.

Which RHV capabilities map to oVirt and which need rework

This table maps the main RHV capabilities to their oVirt counterparts and marks each as clean, needs rework or gap. oVirt is the upstream project where features are developed in the open, so most engine and host functions carry over, but Red Hat subscription tooling and production support do not. Confirm feature parity for every add-on you run before you commit to a cutover date.

Capability	oVirt equivalent	Status
Engine and management	oVirt Engine, the web admin portal and REST API, licensed Apache 2.0	Clean, confirm your engine version and any custom UI extensions
KVM hosts	oVirt Node based on CentOS Stream 9, or EL-based hosts on RHEL 9 or 10 or CentOS Stream 9 or 10	Needs rework, rebuild hosts on the new OS line
Storage domains	NFS, iSCSI, FC and Gluster storage domains managed by the engine	Clean for supported types, confirm each storage vendor driver and multipath setup
OVN networking	OVN-based logical networks managed through the engine	Needs rework, re-validate network profiles and VLAN mappings after the move
High availability	HA VM policies and self-hosted engine failover	Clean, retest fencing and power management agents in your environment
Ansible automation	oVirt Ansible collections and playbooks, updated for the 4.5 line	Needs rework, check module names and playbooks against your current RHV roles
REST API and SDK clients	oVirt REST API with compatible client libraries	Needs rework, test scripts and third-party integrations against the target engine
Backup integrations	Backup APIs for vendor agents, depending on the backup product	Gap, confirm with each backup vendor that its oVirt support matches your RHV agent
Red Hat subscription tooling and support	No direct equivalent, community support and in-house or partner support	Gap, plan your own patching, security response and escalation path

What data and integrations move, and what you rebuild

Some RHV assets move as data, some are recreated by hand, and some integrations must be pointed at a new API. Sorting them before cutover avoids surprises during the move. The cards below separate what you export from what you re-create and what you re-point.

VM disks in storage domains

Disk images live in RHV storage domains, and the export path you choose decides how much you move at once. Confirm which disks are on NFS, iSCSI or Gluster domains, and whether any are shared or direct LUN disks that need separate handling. Check snapshot chains before you copy, because a VM with a deep chain is slower to move and easier to get wrong. Validate every copied disk by booting a test clone before you retire the source.

VM and cluster configuration

CPU types, memory settings, boot order, device layout and cluster policies do not carry over as a file you can simply import. Record them from the RHV Administration Portal or API for each VM and cluster, then recreate them in the oVirt engine. Pay attention to CPU model compatibility between old and new hosts, since a mismatch can block live migration. Keep the record in version control so the rebuild can be reviewed.

Logical networks and VLAN mappings

RHV logical networks, VLAN tags, MTU settings and vNIC profiles must exist in the oVirt data center before any VM starts. Map each source network to a destination network with the same VLAN and MTU, and confirm that OVN networking on the new hosts matches the firewall and routing rules the workloads expect. Test connectivity for each VM after cutover, not only the hypervisor link.

Templates, users and directory bindings

Templates, permission assignments and directory bindings are configuration, not VM data, so they must be recreated. Re-bind the engine to your LDAP or identity provider, then reapply role assignments on data centers, clusters and VMs. Confirm which service accounts used by automation still exist with the same privileges. Ask your identity team to confirm group membership before the first user logs in to the new engine.

Backup software and monitoring

Backup jobs, monitoring agents and the CMDB reference RHV by hostname, API endpoint and VM ID. Each one must be pointed at the oVirt engine and re-tested with a restore, since the backup vendor may need a new integration or plugin for oVirt. Check that monitoring collects host and VM metrics from the new hosts and that CMDB records reflect the new platform and identifiers.

Automation playbooks and the oVirt API

Scripts and Ansible playbooks that call the RHV REST API must be reviewed against the oVirt API and its Ansible modules. Endpoints, authentication and some object attributes can differ, so run each playbook against a lab engine and fix failures before production. Store the playbooks in Git, and record the oVirt version each one was tested against so future upgrades have a known baseline.

How the RHV to oVirt migration runs, step by step

This sequence moves an RHV 4.4 estate to a community oVirt 4.5 engine one cluster at a time, with evidence gathered at each gate so that no cluster moves before the one before it has passed its tests.

Inventory hosts, clusters, storage domains and VMs
Record every data center, cluster, host, storage domain, network, VM and template in the RHV Manager, along with the guest operating system, disk sizes, snapshots, custom properties, and any dependencies on Red Hat-only add-ons or certified drivers. Identify which hosts run RHEL and which can be rebuilt on oVirt Node or a RHEL-compatible system on CentOS Stream 9 or RHEL 9 and 10. The output is a signed-off inventory spreadsheet and a dependency map that the team reviews with application owners. Confirm each item against the oVirt 4.5.7 platform list on the download page before you commit to a host OS.
Build a pilot cluster on new hosts
Select one low-risk cluster and install its hosts with oVirt Node, or with a RHEL-compatible OS on CentOS Stream 9 or RHEL 9 and 10, following the oVirt download guidance. Configure networking, storage access and time synchronization to match the production design, and keep the RHV environment untouched. The team that performs this work is typically the platform engineers who own the existing hypervisors. The output is a pilot host set that passes basic connectivity, storage and fencing checks, documented in a build record.
Install the self-hosted engine from the command line
Deploy the oVirt Engine as a virtual machine on the pilot host using the command-line self-hosted engine setup described in the oVirt documentation. Verify the engine VM's high availability, backup configuration, certificates, and the connection to the storage domain intended for the engine. Record the engine version, the Ansible-based configuration state and the admin access model. The output is a working engine that can start, restart and fail over, with a tested engine backup and restore run captured in the change log.
Move storage domains and virtual machines
Attach the existing storage domains to the new engine, or move data through an export or disk-copy path, and then migrate VMs in small batches. For each VM, confirm the guest tools or drivers, network profile mapping and boot configuration after the move. Keep rollback copies until the application owner signs off. The output is a migration log that lists each VM, its source and target, its outcome and its rollback point. Ask the engine team to confirm that the migration method your environment needs is supported by your oVirt version before scheduling batches.
Run the parallel period and test the pilot
Keep the pilot cluster running alongside the remaining RHV estate for a defined window agreed in advance. Test failover of hosts, storage path loss, engine restart, backup restore into a scratch environment, patching, and application-level checks for each migrated workload. Compare monitoring baselines against the pre-move data. The output is a test report with pass or fail results for each test case, plus a list of accepted risks signed by the service owner. Do not start the next cluster until this report is accepted.
Cut over the next cluster
Repeat the build, engine integration, storage and VM move, and test steps for each following cluster, using the same runbook and the same evidence set. Schedule each cutover with a freeze window, a confirmed rollback point and a named decision owner. The output for each cluster is a closed change record and a reconciled inventory showing that every VM is accounted for on the target side. Re-check the inventory before each cutover, because VMs created after the initial inventory are the most common gap.
Decommission the RHV source environment
Once every cluster has passed its gate, retain RHV in a read-only or powered-down state for an agreed retention period, then remove hosts, storage access and licensing records. Keep the final engine backups and migration logs under your records policy. The output is a decommissioning certificate that lists retired hosts, released storage, removed Red Hat subscriptions and archived evidence. Confirm with Red Hat and your compliance team what records they expect you to keep before you remove the RHV Manager.

What drives the cost and duration of an oVirt migration

This table lists the factors that move the cost and effort of leaving RHV 4.4 for oVirt, with the reason each one matters and how to reduce it. Read the one-time rows as project work that ends, and the recurring rows as costs that continue after cutover. No figures are given because a written quote from your own inventory is the only reliable basis for them.

Driver	Why it changes cost or effort	How to keep it down
Clusters and hosts	Each cluster needs its own host rebuild, network check and cutover window, so effort grows with cluster count more than with host count.	Group clusters by workload and migrate one cluster at a time. Ask the quote to list effort per cluster.
Storage domain type and size	NFS, iSCSI and Fibre Channel domains differ in how disks are exported and verified. Large domains extend copy and checksum time.	Inventory each storage domain first. Confirm which domains will be reused in place and which need data movement.
VM count and disk size	Per-VM work (export, import, driver and guest agent changes, testing) scales with count. Large disks extend transfer time and the window for rollback.	Sort VMs into standard, complex and out-of-scope groups. Ask for a per-group effort estimate, not a single total.
Network complexity	Logical networks, VLAN tagging, bonds and OVN overlays each need mapping and validation on the new engine and hosts.	Export the current network configuration and document each logical network before the build starts.
Number of integrations	Backup software, monitoring, LDAP or SSO, Ansible automation and CMDB links must be re-pointed and retested against the new engine API.	List every system that calls the RHV or oVirt API. Confirm which ones need changes and which keep working unchanged.
Host operating system rebuilds	Hosts move to a supported CentOS Stream or RHEL-compatible base. Each rebuild requires patch validation, driver checks and reinstalled host agents.	Standardize one build image and automate host installation so each rebuild repeats the same steps.
Team skills	Engine setup, Linux administration, storage tuning and API scripting need experienced staff. Gaps are filled by training, outside help or longer schedules.	Assess skills before scoping. Ask the quote to name who performs each task and what knowledge transfer is included.
Downtime tolerance	Strict outage limits push work toward warm migration, parallel environments and more testing, which adds one-time and staffing effort.	Define acceptable downtime per application tier. Ask the quote to price cold and warm paths separately.
One-time: planning, build and testing	Paid for inventory, architecture, self-hosted engine build, pilot migration and acceptance tests. Ends when the new estate is accepted.	Fix the scope in writing and require a test plan with exit criteria before migration waves begin.
Recurring: staff time and support	Internal operations staff, patching, backup operations and any paid support contract continue for the life of the platform.	Ask whether support is bought, from whom, and what it covers. Confirm the team that will operate oVirt after handover.
Recurring: hardware refresh	Hosts, storage and network gear age on their own cycles. Stored RHV hardware may need replacement if it cannot run the oVirt host OS.	Check hardware against the supported host OS list before purchase. Include refresh timing in the quote's operating cost view.

How the move differs by estate size and starting point

A single cluster with a spare host is the simplest shape, and the spare host is what makes the move low risk. The usual sequence is to rebuild one host with the oVirt-supported operating system, deploy the self-hosted engine onto it, and then migrate VMs in batches so the cluster never loses capacity it needs. Because the engine runs as a virtual machine on a host, the team must plan where it lives during each step.

Sequence: Install the new hosts first, build the self-hosted engine, attach the existing storage domain, then move VMs in small groups and drain hosts one at a time.
Parallel run: The RHV engine and the oVirt engine should not manage the same storage domain at the same time. Keep the RHV cluster intact until rollback is no longer needed.
Skill gaps: Command-line installation, engine backup and restore, and oVirt host troubleshooting are less familiar to teams used to the RHV web console alone.
Capacity: Confirm with your own change window how many VMs the spare host can carry during each batch.
Testing: Run a restore test of the engine backup before the first production move.

Confirm the exact host and engine operating system versions against the oVirt download page before ordering hardware or images.

What usually goes wrong in an RHV to oVirt move

Most failed RHV to oVirt moves fail on sequence, not on technology: the deadline arrives before testing finishes, the engine changes without a restore point, or the host operating system mix drifts. The cards below cover the risks we see most often and the prevention step for each. Confirm every version and release detail against the current oVirt download page before you plan.

Deadline before testing completes

Teams often start the migration in the last months before the Extended Life Phase ends and discover that the self-hosted engine, storage and guest workloads have not been tested end to end. Build a dated plan that reserves a full test cycle on a non-production cluster before any production host changes. Record a go or no-go gate for each stage, including rollback criteria. Treat the RHV end date as the fixed constraint and work backward from it.

Unsupported host OS mixes

Hosts running different operating system bases, such as an oVirt Node image on one host and a hand-built RHEL-compatible install on another, cause subtle driver, package and live migration differences. The oVirt download page lists supported Engine and host platforms, including Red Hat Enterprise Linux and CentOS Stream releases. Standardize every host on one supported base before joining it to a cluster. Check the platform list against the release you plan to deploy.

Storage domain format surprises

Storage domains exported or reattached from RHV may carry metadata, formats or permissions that the target engine expects differently, and a mismatch can block import or attach. Confirm the storage type (NFS, iSCSI, Fibre Channel or Gluster), the export format and the domain version before cutover. Run a single test VM through import and boot it. Keep the original RHV storage read-only until the test result is signed off.

Missing backups before engine changes

Engine upgrades, storage edits and self-hosted engine moves change the database that tracks every VM, disk and network. Without a tested engine database backup and a copy of the engine VM, a failed change can leave the data center unmanageable. Take a database backup and a full copy of the engine virtual machine, then test a restore on a separate host. Store copies outside the cluster they protect.

Guest driver and agent gaps

Workloads moved from RHV often keep virtio drivers and guest agents tuned for the old platform, and some guests lose network names, time sync or clean shutdown after the move. Inventory guest operating systems, their drivers and agents, and their boot settings before migration. Test each guest class on the target, including Windows systems that need driver checks before first boot. Document which guests need manual fixes so operators are not surprised during the cutover window.

Staff who have not run the engine

Many RHV estates were operated through a vendor-supported console, and few staff have hands-on experience with a self-hosted engine, its upgrades or its recovery procedure. Plan training and runbooks before cutover, and assign named owners for engine upgrades, certificate renewal and restore. Confirm whether your internal team or an external implementation partner will carry the first two months of production operation. Written procedures for recovery matter more than the install itself.

Testing the oVirt result before Red Hat's Extended Life Phase ends

Build the acceptance test plan before the first production VM moves, and run it against a parallel oVirt environment that mirrors the RHV data center. The tests should cover six areas: VM boot, network reachability, storage performance, failover of the self-hosted engine, backup and restore, and API automation. For each area, write a pass condition that a named owner can check. For example, a boot test should confirm that each migrated VM starts, reaches its login prompt, and gets the expected VLAN and IP address, while a storage test should compare sustained throughput and latency on the target storage domain with the RHV baseline under a load profile your applications actually produce. Record results in a form an auditor or change board can read later.

Failover testing needs the most care because the Engine runs as a virtual machine on a host it manages. Power off the host that carries the Engine VM, confirm that the Engine restarts elsewhere and that the hosts reconnect, and confirm that VMs with high availability enabled restart on surviving hosts. Repeat the test with a host reboot and with a storage network interruption. For backup and restore, take an Engine backup, restore it into a clean test environment, and verify that the data center, clusters, storage domains and VM definitions match. Test API automation by running your existing scripts, Ansible roles and monitoring integrations against the new Engine, and fix any endpoint or authentication changes before cutover. The schedule matters. Red Hat's Extended Life Phase for RHV 4.4 ends on August 31, 2026, and it provides no software fixes. Parallel testing and a rollback rehearsal must finish with enough margin to fix defects and repeat the test cycle, so plan backward from that date and treat it as the hard limit.

Confirm the oVirt release and host platform before you write the test plan, because the tests depend on them. The ovirt-engine repository's most recent documented tag is ovirt-engine-4.5.7, dated December 17, 2025, and the oVirt download page lists Red Hat Enterprise Linux and CentOS Stream as Engine and host platforms, with oVirt Node 4.5 as a minimal host option based on CentOS Stream 9. Decide which of these your hosts will run, check the current oVirt release notes for the minor version you choose, and confirm that your hardware drivers and storage multipath settings are supported on that platform. Ask whether any production support contract will cover the chosen combination, since community support has different response expectations.

Questions teams ask before moving from RHV to oVirt

Is oVirt free, and what does a support contract add?

Yes, oVirt is free to download and use. The engine source is published under the Apache License 2.0, so the software itself carries no license fee. What you pay for is labor and support. oVirt is a community project, so there is no vendor-backed support queue, SLA or long-term support line built into the download. Commercial support is offered by third parties, and the answer depends on which provider you choose and what it covers. Ask each provider in writing which oVirt versions they support, which host operating systems they cover, the response times they commit to, and whether they will help with the engine upgrade path. Compare those quotes with the cost of your own staff time and training, since that is the largest variable in the total.

How long does a move from RHV 4.4 to oVirt take?

The duration depends mainly on the number of hosts, the number of VMs, the storage domain layout, and how many VMs have custom networking or special hardware configurations. Your team also needs to rebuild the hosts on a supported operating system and re-create the self-hosted engine before any VM moves. Plan the timeline around the Extended Life Phase end date of August 31, 2026, and build in time for a test cluster, a rollback plan and a change window per cluster. Ask any implementation partner for a written schedule tied to a defined scope, because a fixed plan is only as reliable as the inventory it is based on.

Can our internal team do the migration without outside help?

Often yes, if the team already runs KVM, Linux and a clustered storage layer and has someone who has installed an oVirt engine before. The installation is done from the command line, and the self-hosted setup runs the Engine as a virtual machine on a host. The harder parts are the storage domain move, the VM inventory, validating backups and testing failover. A useful check is to run a pilot on a non-production cluster first. If the pilot exposes gaps in skills, plan for training or a fixed-scope engagement covering the parts your staff have not done before. Confirm those gaps honestly before committing to a production date.

What skills and staff time does the work need?

Expect the work to need Linux administration, KVM and virtual networking knowledge, storage administration for your storage domains, and familiarity with Ansible for repeatable host configuration. Someone must own the inventory of VMs, their dependencies and their owners, and someone must own the test plan and sign-off. Security and compliance staff should review the new engine's access controls, certificates, logging and backup scope before go-live. Staff time is split between a short planning phase, a longer build and test phase, and a cutover period for each cluster. Ask the team that will do the work to estimate its own hours from the inventory, rather than relying on a generic figure.

Do VMs need downtime during the move?

It depends on how each VM is moved and what the guest needs at cutover. A cold move, where the VM is powered off, exported and imported, produces a clear outage window that is simple to plan and test. A warm approach reduces the outage but adds dependencies on the tooling and the source and target storage. The Forklift project supports warm migration from oVirt with changed-block tracking, but that path is aimed at moving VMs to KubeVirt, so confirm whether your target stack supports it before you plan around it. Also check guest driver and network changes, because those usually require a restart. Test each VM class in the pilot and record the observed outage for each one.

Is oVirt supported for production, and by whom?

oVirt is an open-source project that accepts community contributions, and it is the upstream project where new features are developed before they enter Red Hat's supported product line. It is not supported by Red Hat, and the project itself does not sell production support. Production support comes from third parties, and you should confirm the scope with each one. Check which oVirt release they cover, how they handle security fixes and whether they support your exact host and engine operating systems. The oVirt download page lists Red Hat Enterprise Linux 9 and 10 and CentOS Stream 9 and 10 as platforms, so verify those versions against your support provider's list.

What should we confirm before we pick a migration partner?

Ask for a written scope that names the hosts, engine, storage domains, VM inventory and test plan you expect to receive. Confirm how the partner handles the engine installation, the storage domain move, rollback for each cluster and documentation handover. Ask which oVirt version they will target, how they will validate backups before cutover, and what post-migration support or retainer is available. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. Quotes follow from that written scope.

What a fixed-scope RHV to oVirt engagement covers

A fixed-scope engagement starts with an inventory, not a server order. DeployOpen works through the RHV 4.4 estate with your team to list every data center, cluster, host, storage domain, network, and virtual machine, including the guest operating systems, the disk formats, and which VMs depend on hooks, custom properties, or vGPU and passthrough devices. That inventory drives the target design: how many oVirt hosts, whether the engine is self-hosted, which storage domains carry over, and how the VLANs and logical networks map. The scope, deliverables, and timelines are agreed in writing before any work starts, so the boundaries of the inventory, the pilot, and the cutover are settled up front. Confirm with your Red Hat account team which RHV 4.4 components you hold entitlements for, since that affects what you can still download during the Extended Life Phase.

Implementation follows the design. DeployOpen installs the self-hosted engine on a host running a supported platform such as Red Hat Enterprise Linux 9 or CentOS Stream 9, configures the oVirt hosts (including oVirt Node 4.5 where it fits your standards), and connects the storage domains, networks and authentication. The pilot moves a small set of non-critical VMs first, through the same warm or cold path you will use for production, so that guest drivers, network changes and backup jobs are proven before the main cutover. Each cutover wave gets a rollback point, a named owner for application sign-off, and a change window agreed with your operations team. The engagement also covers hardening (host and engine configuration, access control, and logging) and a tested backup and restore procedure for the engine database and VM data.

Documentation is part of the deliverable. DeployOpen records the as-built architecture, the runbooks for upgrades and failover, the backup schedule and restore tests, and the evidence that controls were configured as designed. That evidence can support a compliance assessment, such as the control set your auditor reviews for change management and access control, but DeployOpen prepares the material and does not issue audit reports, attestations, or certifications. Those come from your independent auditor or certification body. Ask any provider which controls their evidence maps to and how they will hand over configuration exports and test records. Ongoing support, upgrades and continuous testing are available as retainers after handover.

How DeployOpen plans and supports your oVirt migration

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and that includes oVirt. We start with a written scope that fits your RHV 4.4 estate, then build and test the target engine and hosts before any production VM moves.

How we scope

Inventory your RHV 4.4 engine, clusters, hosts, storage domains and VM count before agreeing any work.
Agree the oVirt 4.5 target, host operating system and network layout in writing before work starts.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before work begins.

How we build

Install the self-hosted engine and hosts in your environment, following the oVirt setup path your team approves.
Map storage domains, logical networks and VM export or import steps, then rehearse them on non-production VMs.
Test live workloads, backups and failover on the new oVirt environment before cutover is scheduled.

How we hand over

Deliver architecture, runbooks, configuration records and the migration log for your operations team.
Walk your administrators through day-to-day tasks such as host maintenance, upgrades and backup restores.
Document rollback steps for each wave so your team can reverse a cutover without outside help.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover oVirt patching, host operating system updates and periodic restore tests.
Ask for a written support scope that names response expectations before you sign.

Migrate from Red Hat Virtualization to oVirt