VMware to OpenShift Virtualization: a migration runbook

Define the migration objectives

Confirm which VMware workloads you intend to run on Red Hat OpenShift Virtualization before planning the migration. If you are still choosing a target, compare the options in our VMware decision guide.

Use Migration Toolkit for Virtualization (MTV), an Operator on the target OpenShift cluster, to connect to vCenter, copy disks, convert guests for KVM and create target VMs. Define workload selection, wave order, networks, storage and cutover recovery in your migration plan.

Inventory and classify every VM

List every VM with its operating system, owner, dependencies, disk sizes, change rate and tolerated downtime. The guest operating system must be certified for OpenShift Virtualization and supported for conversion to KVM with virt-v2v. Check each one against both lists rather than assuming a common OS family is covered.

Some VMs need special handling or cannot move with MTV. Disks attached to several VMs in multi-writer mode can only be migrated cold; that applies to disks shared between VMs, not to every VM whose disks sit on shared storage. MTV documents that it cannot migrate Microsoft Windows VMs that use Measured Boot; Red Hat's alternative is to re-create them on OpenShift Virtualization. Encrypted guests are supported with conditions: LUKS volumes need their passphrases supplied or Clevis and Tang unlocking configured, and BitLocker is supported, but Red Hat documents conversion failures for some Windows versions, so test representative builds first. MTV's validation flags known concerns for each VM before you migrate, and its Deep Inspection option analyzes disk images to find issues standard inspection misses. Run both early, while there is still time to fix what they find.

Then group the VMs into waves. Keep application tiers that talk to each other constantly in the same wave, and put the VMs whose owners can tolerate a longer outage first.

Choose cold or warm for each VM

A cold migration copies a VM that is shut down. It works from every source MTV supports and is the simplest path, but the outage lasts for the whole copy and conversion. A warm migration keeps the VM running while most of the data moves. It is available only from VMware vSphere and Red Hat Virtualization.

Warm migration has two stages. In the precopy stage the VM keeps running while MTV copies its disks incrementally using changed block tracking (CBT) snapshots, at a default precopy interval of 60 minutes that can be changed. The cutover stage starts at a time you schedule or trigger: the VM is shut down, the remaining changes are copied and the guest is converted. A warm migration still needs that shutdown, so it is not a live migration. We size each cutover window using the measured data-change rate and pilot results for the workload.

Warm migration from VMware has prerequisites. CBT must be enabled on the VM and on its disks, and VMware Tools must be installed. Windows VMs also need the Volume Shadow Copy Service and the VMware Snapshot Provider service enabled, set to Manual or Automatic, or snapshot creation fails. Live migration, with almost no downtime, exists in MTV only between OpenShift Virtualization clusters or between namespaces on one cluster, from MTV 2.10 with OpenShift Virtualization 4.20. It is not available from VMware.

Build the target platform before the first copy

Storage comes first. Each source datastore maps to an OpenShift storage class, so the classes must exist with the performance, capacity and access modes the workloads need. A database that ran on fast flash in vSphere will notice if it lands on a general-purpose class.

Networks come next. Each vSphere port group maps to a target network: the pod network, or a Multus network attachment definition that puts the VM on an existing VLAN. Decide IP addressing per wave. Virtual network interfaces change during migration, so a static IP configuration tied to the interface name inside the guest can be lost. Select the option to preserve static IPs, make sure the source VM's network interface information is available to MTV, and validate networking after each migration. Firewall rules, DNS records and licences pinned to a MAC or IP address need the same attention.

For transfer performance, create a VMware Virtual Disk Development Kit (VDDK) image. Red Hat strongly recommends using VDDK when transferring disks from vSphere, and it is mandatory when the source VMs are on vSAN. A dedicated migration network on the source provider keeps copy traffic away from production traffic. If that network uses a non-default MTU, the OpenShift transfer network must use the same value.

Maps, plans and hooks

In MTV, network maps and storage maps record how source networks and datastores land on the target, and a migration plan ties a set of VMs to those maps, a target namespace and a migration type. One plan per wave keeps each wave reviewable and repeatable.

Use pre- and post-migration hooks for agreed tasks such as application quiescing, DNS or load-balancer updates, and monitoring and backup registration. Pre-migration hooks require VMware Tools on the source VM. MTV can grant application teams namespace-scoped map and plan permissions without provider creation or system-setting privileges.

Run a pilot wave and measure it

Pick a pilot wave that looks like production, with the same operating systems, storage and networks, but whose owners can tolerate a problem. Migrate it end to end, then measure what the plan depends on: transfer throughput, precopy duration, cutover duration per VM and the time to validate each application.

Validate backup and restore, monitoring, alerting, patching, resizing and recovery. Confirm that your team can operate the migrated workloads as well as start them.

Cutover with a way back

Schedule each cutover inside an agreed maintenance window, freeze changes to the VMs in the wave, and write down who can stop the cutover and on what signals. After cutover, check that each VM boots, has its disks and addresses, and passes its application checks before anyone declares success.

Keep the source VMs intact, powered off, until the wave is formally accepted. In the normal MTV workflow the source VM stays in vSphere after its data is copied, but confirm that for your provider and for any hooks that act on the source. A powered-off source does not contain anything written on the new VM after cutover. Rolling back therefore means stopping or isolating the new VM, deciding how data written since cutover is recovered or reconciled, and only then starting the source and moving DNS or the load balancer back. Agree in advance how long a wave may run before rolling back, so the decision is made on the plan rather than under pressure.

Where migrations lose time

Check CBT settings, the VDDK image, network and storage maps, target storage performance, firewall rules and address-bound licenses during inventory. Resolve gaps before the cutover window.

Include license, hardware and support-contract decisions in the decommissioning plan. Completing data migration alone does not close those costs.

How we approach it

Bring your workload inventory, target requirements and migration constraints to the discussion. Our two-week Assessment Sprint includes a written target architecture and migration sequence with recovery plans; implementation is quoted separately.