VMware to OpenShift Virtualization: a migration runbook

Start from the decision, not the tool

This runbook assumes the decision is already made: some or all of your VMware workloads will run as virtual machines on Red Hat OpenShift Virtualization. If that choice is still open, settle it first. Our decision framework for the VMware question covers the options, and each one leads to a different plan.

Red Hat supports the move with the Migration Toolkit for Virtualization (MTV), an Operator that runs on the target OpenShift cluster. MTV connects to vCenter, copies disks, converts each guest for KVM and creates the VM on OpenShift. It is good at that job. It does not decide which VMs should move, in what order, onto which networks and storage, or what happens if a cutover goes wrong. That is the runbook.

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. How long the cutover takes depends on how much data changed since the last snapshot, so busy databases need a cutover window sized from measurement, not hope.

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 landing zone 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.

Pre-migration and post-migration hooks run automation around each VM: quiescing an application, updating DNS or a load balancer, registering the new VM with monitoring and backup. Anything a person would otherwise do by hand at 2am is a good candidate for a hook. Note that a pre-migration hook needs VMware Tools on the source VM. MTV can also give non-administrators rights to build maps and plans in their own namespaces without letting them create providers or change system settings, which suits application teams that own their waves.

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 operations as well as boot. Can the new VMs be backed up and restored? Do monitoring and alerting see them? Can the team patch them, resize them and recover one from failure? A pilot that only proves the VMs start has tested the easy part.

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

The same few problems account for most delays: CBT not enabled on the VMs or disks planned for warm migration, no VDDK image, a network or storage map missing a port group or datastore, target storage slower than the source, and firewall rules or licences pinned to old addresses. Each one is cheap to find in the inventory stage and expensive to find during a cutover window.

Plan the decommissioning too. VMware licences, hosts and support contracts only stop costing money when the source estate is actually retired, so the last wave is not the end of the project.

How we approach it

This is the sequence we follow: inventory and validation first, a landing zone built and tested before the first copy, one migration plan per wave, a measured pilot, and cutovers with a documented way back. Our two-week Assessment Sprint delivers a written target architecture and a migration sequence with rollback plans, so the migration starts from reviewed facts rather than estimates.