VMware to Proxmox Migration: A Complete Runbook

Moving virtual machines off VMware is largely mechanical, and the copy is rarely what fails. What fails is a Windows guest that will not boot because the disk controller changed underneath it, or a VM that migrates cleanly and serves data from a snapshot taken three weeks ago. This runbook covers the preparation that prevents both, the import itself, and the VMware features that have no Proxmox equivalent.

The technical work is mostly mechanical. Proxmox VE ships an ESXi import wizard that connects to a host or vCenter and pulls virtual machines across without an intermediate export, which removes the step that used to consume a weekend. What breaks migrations is not the copy, it is the guest operating system booting on a different disk controller afterwards.

MassiveGRID runs Proxmox in production. Every server on the platform sits on a Proxmox high-availability cluster with Ceph triple-replicated NVMe storage, deployable in any of the 85+ metros on our datacenter map.

Proxmox support plans — from $99/node/month, including migration assistance on Enterprise
HA Private Cloud · Colocation for hardware you already own

Before You Touch a VM

Three pieces of preparation prevent most of the failures that follow.

Inventory what you actually run. Record for every VM: firmware mode (BIOS or UEFI), disk controller, disk sizes and thin-provisioning state, network adapters and VLANs, guest OS and version, and whether anything depends on a VMware-specific feature. Fault Tolerance, DRS affinity rules, NSX segments and vSphere snapshots used as a backup strategy all need a different answer on Proxmox rather than a direct translation.

Consolidate snapshots. A VM with an active snapshot chain exports its base disk, not its current state. Consolidate everything and confirm the snapshot list is empty before you migrate. This single mistake accounts for a large share of migrations that appear to succeed and then present data from three weeks ago.

Get the guest ready. This is the step that determines whether the VM boots. It is covered in detail below because it differs completely between Windows and Linux.

Preparing Windows Guests

Windows will not boot on a disk controller it has no driver for. VMware guests boot from an LSI Logic or PVSCSI controller; Proxmox defaults to VirtIO SCSI. Move the disk without preparing the guest and you get a 0x0000007B stop code, INACCESSIBLE_BOOT_DEVICE, on first power-on.

There are two ways to avoid it, and the order matters.

The reliable approach is to inject the VirtIO drivers while the VM is still running on VMware. Download the VirtIO driver ISO, attach it, and install the drivers so Windows has them registered before the hardware changes underneath it:

pnputil /add-driver D:\vioscsi\2k22\amd64\*.inf /install
pnputil /add-driver D:\NetKVM\2k22\amd64\*.inf /install
pnputil /add-driver D:\Balloon\2k22\amd64\*.inf /install

Then uninstall VMware Tools and shut the VM down cleanly. Do not skip the uninstall: VMware Tools services fail noisily on KVM and its display driver can leave you with an unusable console.

The fallback, when you have already migrated and the VM will not boot, is to attach the disk on an IDE or SATA controller so Windows boots, install the VirtIO drivers from inside the running guest, then shut down and switch the disk to VirtIO SCSI. It works, but it costs two extra reboots per VM and does not scale across a large estate.

Preparing Linux Guests

Most modern distributions ship VirtIO modules in the kernel already, so Linux guests are usually easier. Two things still need checking.

Confirm the initramfs contains the VirtIO block and SCSI modules, and rebuild it if not:

lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'virtio_(blk|scsi|net)'
# if absent:
echo -e "virtio_blk\nvirtio_scsi\nvirtio_net\nvirtio_pci" >> /etc/initramfs-tools/modules
update-initramfs -u -k all

On Red Hat family systems the equivalent is dracut --force --add-drivers "virtio_blk virtio_scsi virtio_net".

Then check that /etc/fstab and the bootloader reference filesystems by UUID rather than by device path. A VM that mounts /dev/sda1 will fail when the controller change renames the device, and the failure appears as a drop to an emergency shell rather than anything that mentions disks.

Finally, remove open-vm-tools and install the guest agent Proxmox uses:

apt remove --purge open-vm-tools
apt install qemu-guest-agent
systemctl enable --now qemu-guest-agent

Importing With the ESXi Wizard

Proxmox VE treats an ESXi host as a storage backend. Add it once under Datacenter, then Storage, then Add, then ESXi, supplying the hostname and credentials. Virtual machines on that host become visible and importable from the web interface, disks and configuration together.

Two constraints are worth knowing before you plan around it. The wizard reads powered-off VMs, so this is a cold migration and you need a maintenance window per VM. And it pulls over the network from ESXi's storage, so throughput is bounded by whichever is slower, the network path or the source datastore.

Import, then before the first boot, set the hardware correctly:

The Manual Route

When the wizard is not an option, because the source is an older ESXi release or you are working from files on disk, import from an OVF export or a raw disk:

# from an OVF/OVA export
qm importovf 120 /mnt/export/appserver.ovf local-lvm --format qcow2

# or attach an existing VMDK to a VM you defined by hand
qm importdisk 120 /mnt/export/appserver-flat.vmdk ceph-pool
qm set 120 --scsihw virtio-scsi-single --scsi0 ceph-pool:vm-120-disk-0
qm set 120 --boot order=scsi0 --agent enabled=1

Note that importovf does not preserve every setting, and network configuration in particular usually needs to be recreated. Verify the resulting configuration with qm config 120 rather than assuming it came across intact.

A Migration Order That Limits Damage

Sequence the estate so that mistakes are cheap when you make them and rare by the time they are expensive.

Start with a throwaway test VM to prove the pipeline end to end. Then move development and staging workloads, which is where you learn the per-VM quirks of your own images. Then internal tools with a tolerant user base. Then production, in dependency order, databases before the applications that read them. Leave anything with a hardware dongle, a licence tied to a MAC address, or a passthrough device until last, because each of those is a separate problem rather than a migration.

Keep the ESXi host running and untouched until every VM has been verified in production for at least a week. The rollback plan is to power the original back on, and that only works if you have not reclaimed the storage.

Verification Before You Call It Done

A VM that boots is not a VM that has migrated. Check each one:

qm agent 120 ping                 # guest agent responding
qm config 120 | grep -E 'scsihw|net|bios|agent'

Then inside the guest, confirm the paravirtualised drivers are actually in use rather than an emulated fallback, that the clock is correct and NTP is running, that services started in the right order after an unclean hardware change, and that disk performance matches expectations. A guest silently running on emulated IDE will work and will be several times slower than it should be.

What Does Not Translate

Fault Tolerance is the one with no answer, and it is worth raising early with whoever asked for it. Proxmox will restart a VM on another node within a minute or two; it will not run a shadow copy in lockstep. If a workload genuinely cannot lose a single transaction, that guarantee has to come from the application, through database replication or a clustered service.

Do Not Rebuild vCenter in Proxmox

The most common design error is recreating the VMware architecture one component at a time. Proxmox has no central management appliance because every node runs the same clustered configuration database and any node's web interface manages the whole cluster. There is nothing to make highly available, which is a simplification rather than a gap.

Similarly, resist the urge to put Ceph on top of a hardware RAID controller because that is how the VMFS datastore was built. Ceph expects direct disk access and does its own replication; a RAID layer underneath adds a write penalty and hides failures from the software that is supposed to handle them. Our guide to Proxmox Ceph setup covers the correct layout.

Migrating Onto Someone Else's Cluster

Leaving VMware and building a first Proxmox cluster at the same time means learning corosync quorum, Ceph placement groups and HA fencing during a migration with a deadline. Those are the three areas where a mistake costs data rather than time.

MassiveGRID has run Proxmox with Ceph in production for years, so the cluster underneath is already built, tuned and monitored. Workloads land on a high-availability cluster with automatic failover and three-way replicated NVMe storage rather than on hardware you are commissioning in parallel.

If you would rather keep the hardware and hand over the operations, Proxmox support plans start at $99 per node per month for patching and monitoring, $249 adds HA and Ceph management with a four-hour critical response SLA, and the Enterprise tier includes migration work directly. The comparison of running it yourself against handing it over is laid out in managed Proxmox versus self-managed.