Moving Linux VMs off VMware to KVM, Proxmox or OpenShift Virtualization

You have decided to leave VMware (we covered why, and where people go). This post covers the mechanics for Linux guests: what to check on each VM before you move it, what changes inside every Linux guest that leaves ESXi, how the move works on each of the three common destinations, and how to tell that the VM you landed is the VM you had.

First, decide per VM: rehost or rebuild

There are two ways to move a Linux VM, and you should choose one deliberately for each VM:

• Rehost: convert the disk, keep the guest OS exactly as it is, and boot it on the new hypervisor. This is quickest, and right for a guest on a supported OS release that you are happy to keep.
• Rebuild: stand up a fresh VM on a current OS on the new platform and carry over what the old one ran: packages, services, configuration and accounts. This is right when the guest OS is end-of-life (a lot of VMware estates are still on CentOS 7), when nobody knows how the VM was built, or when you want it built from code from now on.

Mixing the two by accident is what makes failures hard to diagnose. If you change the hypervisor and the OS in one step and something breaks, you cannot tell which change broke it.

Before you touch a VM

Record these for every VM. Most failed conversions trace back to one of them:

• Firmware: BIOS or UEFI, and whether Secure Boot is on. The target VM must use the same, or the guest will not find its bootloader.
• Disks: how many, their sizes, and whether any are independent or raw device mappings (RDMs). An RDM is not in the VMDK and has to be moved separately.
• Snapshots: consolidate them first. Converting a VM with a snapshot chain either fails or converts the wrong point in time.
• Encryption: a VM encrypted by vSphere or with a vTPM has to be decrypted before conversion tools can read its disks.
• Network: each NIC's MAC address, VLAN and IP configuration. Some licensed software is bound to a MAC address, so keep it on the new VM where you need to.
• Guest tools: whether the VM runs open-vm-tools or the older VMware Tools installer, which you will need to remove.

What changes inside every Linux guest that leaves ESXi

These apply whichever destination you pick. Conversion tools handle some of them for you, but you should know what they are, because they are what you check when a converted VM does not come up.

Storage and network drivers. On ESXi a guest usually uses the vmw_pvscsi disk controller and the vmxnet3 NIC. On KVM it will use virtio. Current kernels ship the virtio drivers, but a host-only initramfs (the default with dracut on Enterprise Linux) may not include them, and then the guest stops at boot with no root device. Before you shut the source down, add them: on Enterprise Linux, dracut -f --add-drivers "virtio_blk virtio_scsi virtio_net virtio_pci"; on Debian or Ubuntu, list them in /etc/initramfs-tools/modules and run update-initramfs -u.

Disk device names. With virtio-blk the disks become /dev/vda, /dev/vdb. With virtio-scsi they stay /dev/sda. An /etc/fstab that mounts by UUID or LVM name survives either way. One that mounts /dev/sdb1 does not. Check fstab, and any application config that names a device, before you convert.

Interface names. A NIC called ens192 or ens160 on ESXi usually comes up as something like enp1s0 on KVM. Network configuration tied to the old name or the old MAC, such as ifcfg files, NetworkManager profiles or netplan, will not apply, and the VM boots without its address. Either match on the new name, or keep the MAC and match on that.

Guest agent and time. Remove VMware Tools or open-vm-tools, install qemu-guest-agent, and make sure chrony or another NTP client keeps time now that VMware Tools no longer syncs the clock.

KVM with libvirt

The standard tool is virt-v2v, from the libguestfs project. It reads a VM from vCenter, from an ESXi host, or from an OVA or VMDK file, converts the disk, installs the virtio drivers in the guest, removes VMware Tools where it can, and writes a libvirt domain definition. A typical file-based run looks like virt-v2v -i ova web01.ova -o libvirt -of qcow2 -os default.

You can also convert the disk yourself with qemu-img convert -f vmdk -O qcow2 and define the VM by hand, but then every guest change in the section above is yours to make. That approach is fine for a few VMs. For a whole estate, use virt-v2v.

Proxmox VE

Since Proxmox VE 8.2, Proxmox has an import wizard for ESXi. You add the ESXi host as a storage of type ESXi under Datacenter → Storage, browse its VMs, and import one. The wizard maps disks and NICs and lets you choose the target storage and bridge. For a VMDK you already have, qm disk import <vmid> disk.vmdk <storage> attaches it to a VM you created.

In both cases, choose the VirtIO SCSI single controller and VirtIO network, match the firmware (SeaBIOS for BIOS guests, OVMF with an EFI disk for UEFI guests), and turn on the QEMU guest agent option. The wizard copies the disk but does not prepare the guest, so do the driver and network checks above first.

OpenShift Virtualization

On OpenShift the route is the Migration Toolkit for Virtualization (MTV, upstream Forklift). You add your vCenter as a provider, map VMware networks to OpenShift networks and datastores to storage classes, and create a migration plan. MTV uses virt-v2v for the guest conversion.

MTV offers cold migration, where the VM is shut down for the whole copy, and warm migration, which uses VMware changed block tracking to copy the disks while the VM runs and shuts it down only for a final sync. Warm migration keeps downtime short for large disks, but needs changed block tracking turned on for the VM.

Two decisions matter most here. Storage: a storage class that supports ReadWriteMany is what lets VMs live-migrate between nodes later. Networking: a VM that needs its old VLAN and IP address goes on a bridge or localnet network through Multus, not on the pod network. If you only have a disk image, the Containerized Data Importer can import it into a DataVolume, and you define the VM around that.

Checking the VM you landed

A VM that boots is a start. Before cutover, check at least these on each one:

• lsmod | grep virtio: the guest is on virtio, not emulated hardware.
• ip -br addr: every interface has the address it had before.
• findmnt --verify and df -h: every mount from the source is there.
• systemctl --failed and journalctl -p err -b: nothing failed at boot.
• The application's own health check, run by the team that owns it.
• The packages, services and configuration compared against the source, not just glanced at.

Keep the VMware VM powered off but intact until those pass. It is your rollback. Lower the DNS TTLs a day before cutover so that switching back is quick if you have to.

Where vrtmv fits

vrtmv is for the rebuild path and for the last item on that list. It reads a VM's disk cold (VMDK, qcow2, OVA or raw), never boots the guest and never needs vCenter credentials. It works out what the guest runs and generates an Ansible role or Terraform that rebuilds it on the target Linux distribution, on whichever of the three platforms you chose. After the rebuild, vrtmv verify checks the new VM against what the plan said it must carry, using its package database and the carried configuration paths, and writes a parity report that lists every caveat and gap. Verify exits non-zero on any parity gap, so your pipeline can hold the cutover on it.

It does not convert disks or move bulk data. Data moves through a runbook you run, with checksums, and vrtmv refuses to dump a clustered database rather than pretend that is safe. The supported page names the distributions and major versions, and your exact source and target are confirmed in scoping.