None of this is exotic. It’s the same category of friction you’d hit moving between any two hypervisors with different virtual hardware models. The fixes are well understood, but only if you know to expect them before you start.

Plan before you export anything

Before touching a single VM, build a short inventory: guest OS and version, disk size, how many NICs, and whether it’s using anything ESXi-specific like a VMware-only storage adapter or a distributed virtual switch port group. This takes ten minutes and saves you from being surprised mid-migration.

Also clean up before you export. Delete old snapshots on the source VM first, a live snapshot chain complicates the export and drags stale data along with it. And if the guest is disposable or trivial to reinstall, seriously consider just doing that instead of migrating it. Migration is worth the effort for anything with real configuration or data baked in; it’s not worth the effort for a five-minute Ubuntu box you spun up to test something once.

Getting the disk out of ESXi

You have two realistic paths, depending on the tooling you have available.

Path one: ovftool. VMware’s OVF Tool exports a VM as an OVA/OVF package, disk and metadata bundled together. If you have access to it (it doesn’t require ESXi’s paid licensing tier to download and run from your desktop), this is the cleaner path:

ovftool vi://root@esxi-host/vm-name /path/to/export/vm-name.ova

Path two: pull the VMDK directly. If you don’t have ovftool handy, or the VM is simple enough not to need the metadata, SCP or SFTP the VMDK files straight off the ESXi datastore. Every VM’s files live under /vmfs/volumes/<datastore>/<vm-name>/. Grab the flat VMDK (the actual disk data, not the small descriptor file alone, though you need both) and copy it to your Proxmox host or a staging location it can read from.

Either path gets you a disk image in VMware’s format. The conversion step is where Proxmox actually takes over.

Converting the disk and building the VM shell

Proxmox’s qm importdisk handles VMDK-to-target-storage conversion directly, no separate qemu-img step required for the common case:

qm create 210 --name migrated-vm --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0
qm importdisk 210 /path/to/vm-name-disk1.vmdk local-lvm

importdisk reads the VMDK and writes it into whatever storage you point it at, converting format as needed. Attach the resulting disk to the VM the same way you would for any other:

qm set 210 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-210-disk-0
qm set 210 --boot order=scsi0

At this point you have a VM shell with the migrated disk attached, but it will very likely not boot cleanly on the first try. That’s expected, not a sign something went wrong. The next three sections are why.

The boot firmware mismatch

If the source VM was running with EFI firmware on ESXi, the Proxmox VM needs EFI too, not the default SeaBIOS. Check this before you ever hit start:

qm set 210 --bios ovmf --efidisk0 local-lvm:1,efitype=4m

Guessing wrong here is the single most common reason a freshly imported VM just sits at a blank screen or drops into a UEFI shell instead of booting the OS. If you don’t know which firmware the source used, check the VM’s settings in the vSphere/ESXi client before you export, it’s a five-second lookup that saves a confusing troubleshooting session later.

The disk controller and network adapter aren’t the same hardware

ESXi VMs almost always use VMware-specific virtual hardware: an LSI Logic or PVSCSI disk controller, and a vmxnet3 network adapter. None of that exists in Proxmox’s KVM-based virtual hardware model. Proxmox wants VirtIO SCSI and VirtIO network devices instead, and the guest OS needs a driver for that hardware before it’ll come up cleanly.

Linux guests usually have VirtIO drivers built into the kernel already, so this is often a non-event, boot it and it just works. If it doesn’t come up on the network, check ip a from the console; the interface name may have changed (predictable network interface naming keys off PCI slot and device ID, and a different virtual NIC model changes that), which breaks a network config file hardcoded to the old interface name like ens192.

Windows guests are the real risk here. Windows does not ship VirtIO drivers out of the box, and if you switch straight to a VirtIO disk controller, the guest can blue-screen on boot because it has no driver for the disk it’s trying to read from. The safe sequence:

1. Boot the imported VM first with a SATA or IDE disk controller (something Windows already has a driver for) instead of VirtIO SCSI, just to get it running at all.
2. Mount the VirtIO driver ISO as a second CD-ROM device and install the storage and network drivers from inside Windows while it’s still running on the compatible controller.
3. Shut down, switch the disk to VirtIO SCSI and the NIC to VirtIO, and boot again. It should come up clean now that the drivers are already installed.

Skipping straight to VirtIO on a Windows guest that’s never seen those drivers is the number one cause of “the migrated VM won’t boot” reports in homelab migration threads, and it’s entirely avoidable with this two-step boot sequence.

Clean up VMware-specific software inside the guest

Once the VM boots reliably, uninstall VMware Tools from inside the guest, it’s dead weight now and occasionally interferes with things like time sync or the guest reporting incorrect resource stats. Install qemu-guest-agent in its place (apt install qemu-guest-agent on Debian/Ubuntu, or the equivalent package on other distros; for Windows, it’s a separate installer packaged alongside the VirtIO driver set). Enable the agent on the Proxmox side too:

qm set 210 --agent enabled=1

Without this, Proxmox can’t report the VM’s real IP in the summary tab, can’t do a clean guest shutdown, and can’t quiesce the filesystem for consistent backups, the same reasons this matters for any Proxmox VM, cloud-init templates included.

Static IPs, MAC addresses, and DHCP reservations

If anything on your network keys off MAC address, a DHCP reservation, a firewall rule, whatever, know that the migrated VM will get a new MAC unless you explicitly set the old one on the new NIC:

qm set 210 --net0 virtio,bridge=vmbr0,macaddr=<original-mac>

Pulling the original MAC from the ESXi VM’s network adapter settings before you decommission it, and setting it explicitly here, saves you from chasing down every DHCP reservation and firewall rule that referenced the old address.

Don’t decommission the old host until you’ve actually verified the new one

This sounds obvious, but under time pressure it’s the step that gets skipped. Keep the source ESXi VM powered off (not deleted) until you’ve confirmed the migrated VM on Proxmox does everything the original did: the services start, the data is intact, and anything else on your network that talks to it still works. A powered-off VMware VM costs you nothing but disk space, and it’s a much better rollback plan than restoring from a backup if something surfaces a week later that you didn’t test on day one.

Bottom line

Migrating from ESXi to Proxmox isn’t hard, but it’s not zero-friction either. The disk itself converts easily, qm importdisk handles that part for you. Nearly every real problem comes from the virtual hardware model changing underneath the guest: firmware type, disk controller, and network adapter. Check the firmware before you start, expect Windows guests to need the two-step VirtIO driver dance, and keep the original VM around as a safety net until the new one has proven itself. Do those three things and the actual migration is a couple of commands per VM, not a debugging project.