Migrate from Red Hat Virtualization to KubeVirt

Migrate from Red Hat Virtualization to KubeVirt: what moves and who does the work

If your RHV 4.4 estate is nearing the end of its Extended Life Phase on August 31, 2026, and Kubernetes is on the shortlist, understand this first: the move is a platform change. Each VM becomes a KubeVirt resource running on Kubernetes, and Forklift is the toolkit that carries it across, mapping oVirt sources to KubeVirt destinations and running the migration plans. Nothing about the guests is preserved automatically, so the work is an infrastructure project with per-VM validation, not a file copy. The people who usually do it are platform engineers who already run Kubernetes clusters, paired with the owners of the VMs being moved. The platform side covers cluster build, storage classes, networking and access control. The VM owners confirm which guests need driver changes, which services must start in a fixed order and what downtime each application tolerates. Effort and risk depend mostly on how many guests run Windows, how many depend on fixed MAC addresses or static IPs, and whether the team has operated Kubernetes in production before. Ask any integrator for the scope of each of those items in writing before agreeing a plan.

This page walks through four areas: setting up the oVirt-compatible source provider, defining network and storage mappings, running warm migrations to shorten the cutover window, and preparing the Kubernetes storage that live migration needs once VMs are running on the new platform. Pay particular attention to the last one. KubeVirt live migration requires shared ReadWriteMany access for PersistentVolumeClaims, and many default storage classes do not provide it, so confirm your storage backend before the first wave. Also confirm that each VM's network configuration does not depend on a pod network bridge interface, because that setup blocks live migration. Check the current KubeVirt release notes and the Forklift documentation for your target versions, since both projects change between releases.

Which RHV capabilities map to KubeVirt and which need rework

This table maps the main RHV capabilities to KubeVirt, Kubernetes storage and networking, and Forklift, and marks each as clean, needs rework or gap. Read the confirm column before planning, because most of the open items depend on your storage backend, guest operating systems and cluster design. The main takeaway is that VM lifecycle and migration are workable on Kubernetes, while storage domains, networks and the engine's management model need redesign.

RHV capability	KubeVirt and Forklift position	Status	What to confirm
VM lifecycle (create, start, stop, delete)	KubeVirt defines VMs as Kubernetes custom resources and runs controllers that schedule, launch, stop and delete them.	Clean	Confirm your target guest OS images are supported for your KubeVirt version and that VM definitions are rebuilt as Kubernetes objects.
Live migration between hosts	KubeVirt supports live migration, but VMs using PersistentVolumeClaims need a shared ReadWriteMany access mode, and bridge pod network binding blocks migration.	Needs rework	Confirm which storage class provides ReadWriteMany for each VM disk and that VM networks avoid the bridge binding type.
Storage domains	RHV storage domains have no direct equivalent. Disks become PersistentVolumeClaims backed by Kubernetes storage classes, and Forklift maps source storage to target storage.	Needs rework	Confirm the CSI driver, storage class and access modes for each workload, and which backend your team will operate.
Logical networks	Logical networks become Kubernetes network attachments and pod or multus networking, and Forklift maps source networks to destination networks.	Needs rework	Confirm the CNI and secondary network design, VLAN trunking and how VM IP addresses persist after migration.
Templates	Templates have no direct RHV-style counterpart in KubeVirt, so teams rebuild golden images or VM templates as Kubernetes resources.	Needs rework	Confirm how your current templates are exported and whether guest drivers and agents in them need updating.
Snapshots	KubeVirt snapshot behavior depends on the storage backend and CSI snapshot support, so behavior differs from RHV snapshots.	Gap	Confirm snapshot support from your CSI driver and test restore procedures before relying on snapshots as a recovery method.
Engine web UI and REST API	KubeVirt has no RHV engine equivalent. Operators use kubectl, Kubernetes APIs and a management console chosen for the cluster, and scripts that call the RHV API must be rewritten.	Gap	Confirm which console, RBAC model and automation tooling your operators will use and inventory every RHV API integration.
Backup integration	Backup for KubeVirt VMs depends on a chosen backup tool that works with Kubernetes storage, not the RHV backup API.	Needs rework	Confirm which backup product supports your storage and VM disks, and test restores of VMs with attached PVCs.

How Forklift connects RHV to KubeVirt through mappings and plans

Forklift is an Apache-2.0 toolkit that moves VMs from oVirt, among other sources, into KubeVirt by mapping the source environment to the destination cluster and then running migration plans against those mappings. In practice, the work starts with a source provider that points Forklift at the oVirt engine, using credentials for an account with read access to the VMs and storage domains being moved. Once the provider is connected, the destination is defined as the target KubeVirt cluster. Confirm the exact Forklift release and the oVirt versions it supports in the Forklift repository before you fix a design, because the supported source versions decide whether your RHV 4.4 estate can be moved directly or needs an intermediate step.

The network mapping and storage mapping decide where each VM's NICs and disks land, so they deserve the most review before any plan runs. The network mapping ties each source logical network to a destination network in the cluster, and a wrong entry here leaves a VM running with no connectivity after cutover. The storage mapping ties each source storage domain to a destination storage class, which sets the performance and access characteristics of every disk that follows it. A plan then groups the VMs that should move together, for example a multi-tier application that must cut over in one window. Grouping by dependency, not by team, is the decision that most affects the outage window.

Forklift supports warm migration with changed-block tracking for oVirt sources, so most of the data can copy while the VM keeps running, and only the changed blocks are synchronized before the final cutover. The same toolkit converts VMware guests with virt-v2v, which installs virtio drivers so the converted VM can use paravirtual devices on KubeVirt. oVirt guests already use virtio devices, so confirm for each guest operating system whether any driver or guest tools change is still needed after conversion. Test one representative VM per guest type in a non-production namespace, and check that the destination storage supports the access modes your live migration design requires, which the next section covers in detail.

The migration sequence from inventory to decommissioning RHV

This sequence moves RHV workloads to KubeVirt in controlled stages, so each VM is inventoried, piloted, migrated with minimal downtime and cut over only after a tested rollback path exists. The result is a verified KubeVirt estate and an RHV environment that can be retired on evidence rather than assumption.

Inventory VMs, disks, networks and dependencies
Your team, with the RHV administrators, builds a register of every VM, its disks and storage domains, attached networks, guest operating system and version, and the applications and services that depend on it. Record which VMs use shared or multi-attach disks, which run on vSAN-style or local storage, and which need a fixed IP or specific MAC address. Ask the Forklift and Kubernetes owners to confirm which VMs will need live migration, because that decision drives the storage design in the next step. The output is an approved inventory with an owner, a criticality rating and a target wave for each VM.
Build the Kubernetes target cluster
Stand up or confirm the Kubernetes cluster that will run KubeVirt, following your standard control plane design, including an etcd topology and backup plan. Install KubeVirt and Forklift, then define a storage class that provides ReadWriteMany access for any VM disk that must live migrate, and confirm that the storage backend supports it. Define network attachments that match the VLANs in your inventory, and avoid the bridge binding type on pod networks where live migration is required. The output is a cluster that passes a test VM boot, a live migration test and a storage access test, all documented.
Configure the RHV source provider and mappings
Create the oVirt-compatible source provider in Forklift against your RHV engine, using a service account with the least privilege that Forklift needs. Map each RHV storage domain to a Kubernetes storage class and each RHV logical network to a network attachment. Confirm the mappings with the network team before any plan runs. The output is a provider in a ready state that lists your inventoried VMs, with mappings reviewed and signed off.
Pilot with non-critical VMs
Run a migration plan for a small set of non-critical VMs that cover your main guest operating systems, disk layouts and network profiles. Check that each migrated VM boots, has its drivers and guest tools working, keeps its network identity and passes an application smoke test agreed with its owner. Record the downtime observed, the errors and the fixes applied to the plan. The output is a pilot report that the application owners accept, and a documented runbook for the next waves.
Run parallel production migration with warm migration
Move production VMs in waves using warm migration, which copies disk data while the VM keeps running on RHV and then performs a short final synchronization at cutover. Keep RHV and KubeVirt running side by side, and verify each migrated VM against its pre-migration baseline before its cutover window. Confirm that backups cover both the source and the new VMs during the parallel period. The output is a wave-by-wave record showing each VM's status, validation result and backup status.
Cut over in agreed change windows
For each wave, schedule a change window with the business owners, stop the final sync point on RHV, complete the migration and start the VM on KubeVirt. Run the post-cutover checks, confirm that monitoring and backups point to the new VM and close the window with the application owner's sign-off. Keep the RHV copy powered off and intact until its rollback period ends. The output is a signed cutover record for each VM and a rollback decision for each wave.
Test rollback before decommissioning RHV
Before retiring RHV, prove that you can roll back a representative set of migrated VMs to their RHV copies, and that the restored services work with the expected data. Confirm that all VMs, disks and networks are either migrated, formally retired or archived, and that backup restores have been tested from the new platform. Then decommission the RHV engine and hosts in the order your change process requires, and retain the archived export and configuration records your auditors need. The output is a written decommissioning approval that cites the rollback test results and the archive location.

What data, identities and integrations need rebuilding after the move

A VM move to KubeVirt carries disks and configuration, but much of what surrounds RHV does not come along as RHV objects. Each card below covers one item that needs an explicit owner, a target and a test before the cutover. Confirm each mapping against your own templates, scripts and access model rather than assuming it transfers.

VM disks and configuration

Forklift is the documented path for moving oVirt VMs into KubeVirt, and it maps source and destination infrastructure before running a migration plan. Disk contents move with the plan, but CPU, memory, NIC and disk settings should be checked against the target VirtualMachine definitions after import. Confirm that each VM's boot firmware, device model and network binding still work on the new cluster, and that bridge-type pod binding is not used where you need live migration.

Templates and snapshots

RHV templates and snapshot chains are RHV objects, so they do not carry over as-is. Treat each template as a source image to rebuild, either as a KubeVirt VM template or as a golden disk your automation clones, and flatten or delete snapshots before the move so the migration copies a single consistent state. Ask your team which templates are still in use and who signs off on the rebuilt versions.

RHV REST API and automation

Scripts, Ansible roles and tooling that call the RHV REST API must be rewritten against the Kubernetes API, where VMs are custom resources managed through CRDs. Inventory every script that creates, starts, snapshots or reports on VMs, then map each call to its KubeVirt equivalent and test it in a non-production cluster. Plan for this work to take longer than the data move itself.

Backup jobs and targets

Backups configured in RHV do not follow the VMs into KubeVirt. Define a new backup target and schedule before the first production VM moves, and confirm that restores have been tested on the new platform. Velero is the self-hosted option listed for Kubernetes backup and recovery, and you should confirm how it handles the VM disks in your environment.

Monitoring and logging

RHV engine alerts and dashboards will not show KubeVirt VMs, so monitoring needs to be rebuilt with Prometheus and Grafana or the stack your team already runs. Decide which VM metrics, host metrics and audit logs must be retained, and confirm where guest-level logs go once the VM runs in a pod-backed environment.

User access and secrets

Kubernetes does not store normal users as API objects, so identities must come from X.509 certificates, OpenID Connect or another supported authentication method. Secrets are stored unencrypted in etcd by default, so enable encryption at rest, restrict list and watch access with least-privilege RBAC, and confirm which secrets from RHV scripts move into the new store.

What drives cost and duration in an RHV to KubeVirt move

This table lists the main drivers of cost and schedule for moving Red Hat Virtualization workloads onto KubeVirt, with the reason each one moves effort and how to reduce it. Read it before requesting a quote, because the drivers shape the written scope more than any single line item.

Driver	Why it moves cost or time	How to keep it down
Number of VMs and total disk size	Migration effort and data transfer time grow with both the count of VMs and the capacity of their disks, and each VM needs its own plan entry, testing and cutover sign-off.	Inventory every VM with its disk sizes before scoping, retire idle VMs first and group the rest into waves by application.
Windows and legacy guests	Windows and older Linux guests need virtio driver work and validation after conversion, and guests without current agents need more manual checks.	Sort guests by OS and support status early, and ask the vendor or DeployOpen to confirm the driver and conversion path for each guest family.
Storage without ReadWriteMany support	Live migration of VMs with PersistentVolumeClaims requires shared ReadWriteMany access, so storage that lacks it pushes work into storage build-out or limits which VMs can move live.	Map each storage domain to a Kubernetes storage class before migration, and confirm RWX support with the storage vendor or chosen CSI driver.
Number of RHV clusters and data centers	Each cluster usually maps to its own set of networks, storage and host pools, so more clusters mean more mappings, more test rounds and more cutover windows.	Consolidate networks and storage definitions where possible, and sequence clusters one at a time instead of in parallel.
Network complexity	VLANs, bonded NICs and bridge interfaces must be mapped to Kubernetes networks, and the bridge pod network binding cannot be used with live migration, which can force redesign of some VMs.	Document every VM's network interfaces, decide which VMs need a secondary network, and test live migration on a sample VM before the main waves.
Production-grade Kubernetes control plane	A production cluster needs at least three control plane nodes, a load balancer on port 6443 in front of kube-apiserver, and etcd with regular snapshot backups, all of which take design, build and testing before any VM moves.	Use a tested kubeadm reference design, define backup and restore runbooks for etcd, and agree the topology (stacked or external etcd) in the written scope.
Team Kubernetes skills	Operating VMs on Kubernetes adds skills in RBAC, storage classes, CSI, certificates and upgrades, and a team without them needs training or outside help, which lengthens the first months.	Assess current skills honestly, plan training or pair work during the pilot, and ask for runbooks and handover documentation as deliverables.
One-time costs	Design, cluster build, Forklift setup, mapping, pilot and wave migrations, guest driver work, testing and cutover are paid once per move, although they are repeated for each wave.	Ask the quote to split these into named deliverables, so each wave can be measured against its scope.
Recurring costs	Kubernetes minor upgrades (one minor version at a time), Forklift and KubeVirt upgrades, etcd backup checks, storage maintenance, monitoring, and any support or retainer agreement continue after the move.	Ask for the upgrade calendar, the support tier needed for production and who owns patching in the operating model before signing.

What usually goes wrong in this migration and how to prevent it

Most failed RHV-to-KubeVirt moves fail on storage access modes, network bindings, guest drivers, untested recovery paths or cluster maintenance, not on the import itself. The cards below cover the risks that show up most often, and each one comes with a check to run before the first production cutover.

Live migration blocked by PVC access mode

KubeVirt live migration requires VMs that use PersistentVolumeClaims to have a shared ReadWriteMany access mode. Disks provisioned as ReadWriteOnce will import without complaint but cannot move between nodes while running. Before importing, confirm that the storage class your target cluster will use supports RWX for block or filesystem volumes, and test a live migration of a non-critical VM before moving production workloads.

Bridge pod network blocks live migration

Live migration is not allowed when a VM uses the bridge interface type on the pod network. Migrated VMs that keep their RHV-era network profile can therefore pass import checks and still fail the move you planned for zero-downtime maintenance. Map each source network to a binding that supports live migration, and document which VMs, if any, must stay on bridge bindings and accept a planned stop for node maintenance.

Missing guest drivers and agents after conversion

Forklift converts VMware guests with virt-v2v, which installs virtio drivers, but oVirt guests carry their own driver and agent setup from RHV. Windows guests that lack the right virtio drivers may fail to boot, and network or disk names can change after conversion. Run a pilot on each operating system family in your estate, confirm the guest agent reports to the platform, and rebuild network configuration in the guest where the mapping differs.

Cutover without a tested rollback

A warm migration reduces downtime at cutover, but it does not give you a way back if the converted VM misbehaves. Keep the source VM in RHV powered off but intact until the application owner signs off, and write down the exact steps and time window for returning traffic to the source. Rehearse the rollback on a test VM so the team has done it before it is needed.

etcd backups never restored

The cluster that hosts KubeVirt holds all VM definitions in etcd, so a lost etcd member without a usable backup means lost VM objects. Kubernetes documentation recommends running a five-member etcd cluster in production and keeping a backup plan, with snapshots taken using etcdctl and restored using etcdutl. Schedule snapshots, store them off the cluster, and restore a snapshot into a scratch environment at least once before go-live.

Upgrade order and version skew mistakes

Kubernetes requires kube-apiserver to be upgraded one minor version at a time, before kube-controller-manager, kube-scheduler and kubelets, and kubelets may trail the API server by up to three minor versions. Teams that upgrade worker nodes first or skip minor versions can leave KubeVirt and its controllers in an unsupported combination. Check the KubeVirt compatibility matrix for each target version, and write an upgrade runbook that follows the control plane first.

Secrets unencrypted in etcd

Kubernetes stores Secrets unencrypted in etcd by default. Cloud-init credentials, registry pull secrets and VM access keys migrated into the cluster can therefore be readable by anyone with broad etcd or list access. Enable encryption at rest for Secrets, restrict list and watch permissions with least-privilege RBAC, and consider an external store through the Secrets Store CSI Driver before importing VMs that carry credentials.

How the move differs by estate size and starting point

A single RHV cluster with a modest VM count usually has one source provider, one or two storage domains and a short list of networks. The sequence is simple: stand up a small Kubernetes cluster with KubeVirt, define the oVirt source provider in Forklift, map networks and storage, then migrate in waves that the application owners can test. Because the inventory is short, most of the effort goes into validating each VM rather than into building the platform.

Fewer mappings: One network map and one storage map may cover the whole estate, so review them once and document the choices.
Smaller pilot: Start with a non-critical VM to confirm the guest boots, the network answers and the console works before moving the rest.
Warm migration for a few VMs: Use warm migration only where the downtime window is tight, since the extra synchronization steps add operational work for a small gain on small VMs.
Single storage tier: Confirm which Kubernetes storage class will back the VM disks, and whether it supports ReadWriteMany for live migration.
Simple cutover: Schedule one window per group of VMs and keep the RHV source intact until each VM passes its checks.

Before starting, confirm with the platform team whether a single Kubernetes cluster is acceptable for this workload or whether a separate cluster is needed for isolation.

Questions buyers ask before moving RHV workloads to KubeVirt

What does a move from RHV to KubeVirt cost, and what drives the price?

The software is free to download: KubeVirt and Forklift are both Apache-2.0 licensed, and Kubernetes is Apache 2.0 as well. The real costs are the people and infrastructure around them. Expect one-time work for the Kubernetes cluster build, storage and network design, migration planning, guest driver changes and testing, plus recurring costs for cluster operations, upgrades, backups and staff time. What drives the total is the number of VMs, how many need warm migration, the guest operating systems in use, how much storage and network redesign is needed, and whether you buy commercial support for the storage or platform layer. No supplied figure sets a price, so ask any provider for a quote built from a written scope that lists each component separately.

How long does an RHV to KubeVirt migration take?

The duration depends on the size and shape of your estate, not on a fixed formula. The main pace setters are the number of VMs and disks, how many VMs need a warm migration with a short cutover, the time needed to build and harden the Kubernetes cluster, how many storage and network mappings you have to design, and how many application owners must sign off on testing. VMs with large disks or snapshots take longer to copy. A reasonable first step is a pilot with a small set of representative VMs, which gives you measured timings for your own environment. Ask for a timeline in the written scope tied to those measured steps.

What does our team need to provide during the move?

You need clear ownership on several fronts before work begins:

An inventory of VMs, their owners, dependencies and acceptable cutover windows.
Access to the RHV engine and the target Kubernetes environment, with change approval.
Network and storage design decisions, including VLANs, IP addressing and which storage class each workload uses.
Application testers who can confirm each VM works after migration.

Your team also has to decide how identities, secrets and backups are handled on the new platform. Confirm these responsibilities in the written scope so that nothing falls between your staff and the implementation team.

Can our own staff run KubeVirt after the migration?

Yes, but it requires Kubernetes skills, not only virtualization skills. Your operators will manage the control plane and etcd, node upgrades under the Kubernetes version skew policy, the storage layer, networking and KubeVirt releases. Kubernetes publishes roughly three minor releases a year and maintains the three most recent, so an upgrade calendar is part of daily work. Teams that already run Kubernetes can absorb this more easily. Teams that do not should plan training, a runbook set and, if needed, a retainer for upgrades and continuous support. Ask the implementation partner which runbooks, training and handover sessions are included in the scope.

Does live migration still work on KubeVirt, and what storage does it need?

Live migration works on KubeVirt, with conditions. According to the KubeVirt user guide, VMs that use PersistentVolumeClaims need a shared ReadWriteMany access mode for live migration to run. Migration is also not allowed when the VM uses a pod network bridge interface. Plan your storage class with that requirement in mind, and test live migration on your chosen storage backend before you rely on it for production. If your storage cannot provide shared ReadWriteMany volumes, you can still run VMs, but you should confirm the operational consequences for maintenance and host evacuation with your implementation team.

Does Forklift migrate every VM from RHV without manual work?

No. Forklift is an Apache-2.0 toolkit that maps source and destination infrastructure and runs migration plans for oVirt sources, and it supports warm migration with changed-block tracking for oVirt. Its guest conversion relies on virt-v2v, which installs virtio drivers. Even so, some VMs need manual attention: guests with unusual boot configurations, unsupported operating systems, custom device passthrough, or applications tied to specific hardware or network identities. Run a discovery and a pilot against every VM class you have, and record which ones need a manual procedure. Ask for that classification as a deliverable in the written scope.

What should we require in a written scope for this migration?

A written scope should name the exact deliverables, so you can compare proposals and hold the work to them. Ask for:

A VM inventory and classification, with cold, warm or manual migration assigned to each VM.
The Kubernetes cluster design, including control plane topology, etcd backup and restore procedure, and the storage and network design.
Documented storage requirements for live migration and a test result on your chosen storage.
Runbooks, handover sessions and a rollback plan for each migration wave.
The support model after handover and the fees that recur, such as retainers or vendor subscriptions.

DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside your own environment, under fixed-scope agreements with deliverables and timelines set in writing before work starts. It does not issue audit reports or certifications, so any compliance evidence you need comes from independent assessors.

How DeployOpen scopes, runs and supports the move to KubeVirt

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Red Hat Virtualization to KubeVirt, we agree the scope in writing first, then build, test, document and hand over the Kubernetes and Forklift environment so your team can run it.

How we scope

Inventory RHV data centers, clusters, storage domains, networks and VMs with their guest operating systems and dependencies
Agree in writing which VM waves move, which stay on RHV for now, and which need downtime windows
Confirm the target Kubernetes distribution, control plane topology and ReadWriteMany storage needed for live migration

How we build

Deploy the Kubernetes cluster and KubeVirt, then configure Forklift with the oVirt-compatible source provider and network and storage mappings
Run pilot migrations of non-critical VMs, including warm migration, and measure cutover behavior against the agreed plan
Harden the cluster against the Kubernetes authentication, Secrets and Pod Security guidance and document each control

How we hand over

Deliver runbooks for migration plans, rollback steps, etcd backup and restore, and Kubernetes upgrades
Provide architecture records, configuration inventory and test evidence in a form your auditors and assessors can review
Train your platform and virtualization staff on day-to-day VM operations, storage and networking in the new environment

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Retainer scope, response expectations and upgrade cadence are set in writing, so you know what is covered before go-live
Ask any proposal to state which Kubernetes and KubeVirt versions it targets and how version skew upgrades will be sequenced

Migrate from Red Hat Virtualization to KubeVirt