Every VMware shop I talk to is asking the same question this year: where do our VMs go next? For many of them, the answer is Red Hat OpenShift Virtualization. It runs virtual machines on Kubernetes using KubeVirt, and Red Hat ships a tool, the Migration Toolkit for Virtualization (MTV), that moves them across from vSphere.
The documentation is good, but it is written for people who already think in Kubernetes. A VMware engineer opening it for the first time meets Pods, PVCs, NADs and operators all at once. So I built a lab, migrated a VM end to end, and wrote down everything, including the parts that went wrong.
The concepts translate
Most of what you know still applies. It just has a new name.
| vSphere | OpenShift Virtualization |
|---|---|
| VMDK on a datastore | PersistentVolumeClaim (PVC) on a StorageClass |
| Port group | NetworkAttachmentDefinition (NAD) |
| vSwitch / VDS | Linux bridge built by NMState |
| vMotion | Live migration (needs RWX storage) |
| VMware Tools | QEMU guest agent |
Once that table clicks, the rest is detail.
What MTV actually does
When you press Start on a migration plan, MTV runs a short pipeline. It validates the plan, creates the target disks, converts the guest with virt-v2v (which installs virtio drivers and the guest agent), copies the blocks, and creates a VirtualMachine with the same CPU, memory and MAC address. A cold migration only reads from the source, so the original VM stays where it is as your rollback.
What I learned the hard way
- The read path decides your speed. Without VDDK, MTV reads disks over HTTPS through vCenter on port 443. My 10 GiB test VM took 1 h 24 min, most of it disk transfer at about 2.8 MB/s. With VDDK, it reads from the ESXi hosts over NBD on port 902, which is much faster. Build the VDDK image before your first real wave.
- DNS is everything. The agent-based installer, the console and MTV's connection to vCenter all fail in confusing ways when a record is missing.
- Storage needs RWX for live migration. If your StorageClass is ReadWriteOnce only, VMs work but cannot move between nodes.
- Check what was kept. In my test the VM kept its MAC address, disk serial and BIOS serial, so licensing and DHCP reservations survived. Verify this on your own VMs before you promise it to anyone.
The commands I used most
oc get providers,plan,migration -n openshift-mtv # is MTV connected, what is running
oc get migration -n openshift-mtv -w # watch a run move through the pipeline
oc get vm,vmi -n mtv-test # the migrated VM, defined and running
oc get dv,pvc -n mtv-test # disk import progress and the claim
virtctl console ubuntu-noble-24.04-cloudimg -n mtv-test # serial console into the guest
The full 53-command cheat sheet is in the repo as a PDF.
What's in the manual
The Lab Manual: Migration Edition has ten chapters, from Linux and networking basics through the agent-based install, storage, VM networking and MTV, to an end-to-end migration and a troubleshooting chapter. Every command block shows real output from the lab, with hostnames and IPs replaced by placeholders. There is also a 53-command cheat sheet and an exam map for EX316.
It is MIT-licensed and free: github.com/Willey2003/openshift-vmware-migration-sop
If you are planning a migration, I'd like to hear what you are running into. Corrections and production lessons are welcome as issues or pull requests.
Top comments (0)