Migrate VM from ESXi to Proxmox: ESXi to Proxmox Migration — Complete Step-by-Step Guide for VMware to Proxmox in 2026

An ESXi to Proxmox migration moves a VM's disks and configuration to different virtual hardware. To migrate a VM from ESXi to Proxmox, plan the transfer, preserve a rollback copy, and check the guest's drivers and firmware. The main stages are:

• Export or copy the powered-off VM and its complete virtual disk files.
• Convert the disks with qemu-img, or use the Import Wizard to transfer them to supported target storage.
• Create the Proxmox VM with suitable CPU, memory, network, and firmware settings.
• Verify boot, drivers, networking, and application data before returning the guest to service.

The following methods cover the Import Wizard, manual disk conversion, and OVF/OVA export. Test the chosen method before you migrate VMware to Proxmox in production.

Prepare before migrating

Source ESXi requirements

• Enable SSH only if you use SCP or other SSH commands. The Import Wizard uses the ESXi API and does not require SSH for its normal workflow.
• Verify network connectivity from the Proxmox node to the ESXi services used by your chosen method.
• Inspect source disk usage, virtual capacity, and snapshot chains. This command shows current directory usage, but does not by itself determine the required destination capacity:

du -sh /vmfs/volumes/datastore1/myvm/

Destination Proxmox requirements

• Estimate capacity for every source disk, destination disk, temporary copy, and snapshot. The expression below is only a rough allowance:

A 20% buffer is not sufficient for every conversion workflow. Copying or converting thin disks may require more space than their current allocated size; check the target storage and temporary files before starting.

• Use a supported, updated Proxmox VE release that includes the importer you intend to use. Apply updates through your normal maintenance procedure:

apt update && apt full-upgrade

Test the importer and disk tools on the versions installed on the destination before scheduling a production migration.

VM checklist, including Windows drivers

• Record each VM's IP configuration, hostname, domain membership, firmware, disk controllers, and disk layout.
• Create and verify a separate backup. Keep the original VM available for rollback; a snapshot on the same datastore is not an independent backup.
• Prepare Windows VirtIO drivers before cutover where possible.
  • Obtain the VirtIO Windows ISO from the Fedora project.
  • Mount the ISO and install the drivers appropriate to the guest and intended virtual hardware.
  • Verify that the destination storage driver is installed and usable before switching the boot disk to VirtIO.
• Plan to remove VMware-specific tools when they are no longer needed and install the tools required by the destination guest.
• For Linux, record the network interface configuration. A changed virtual NIC may receive a different name, requiring changes to Netplan or /etc/network/interfaces.

Method 2: migrate ESXi disks with qemu-img

Step 1: copy complete VMDK files

• Power off the source VM and ensure its disk chain is consistent before copying. Enable SSH on ESXi for SCP transfers.
• Locate all VMDK files for the VM, including descriptors and their referenced extent or snapshot files:

find /vmfs/volumes/datastore1/VMname/ -name "*.vmdk"

• Create the destination staging directory, then copy each descriptor and every file it references. For a consolidated split disk, the example copies its descriptor and flat extent:

mkdir -p /var/lib/vz/import/VMname
scp root@esxi-host-ip:/vmfs/volumes/datastore1/VMname/VMname.vmdk /var/lib/vz/import/VMname/
scp root@esxi-host-ip:/vmfs/volumes/datastore1/VMname/VMname-flat.vmdk /var/lib/vz/import/VMname/

• For snapshot chains, copying only the base flat extent misses later changes. Consolidate through VMware with a verified backup, or export a complete, consistent disk before conversion. Do not mount a VMFS datastore for arbitrary writes from Proxmox.

Step 2: convert the descriptor to QCOW2 or raw

• Convert the complete VMDK to QCOW2 by passing the descriptor file:

qemu-img convert -p -f vmdk -O qcow2 /var/lib/vz/import/VMname/VMname.vmdk /var/lib/vz/import/VMname.qcow2

• Convert to raw if that format suits the destination storage:

qemu-img convert -p -f vmdk -O raw /var/lib/vz/import/VMname/VMname.vmdk /var/lib/vz/import/VMname.raw

• Use compression only when producing a supported QCOW2 image and the storage tradeoff is appropriate:

qemu-img convert -c -p -f vmdk -O qcow2 /var/lib/vz/import/VMname/VMname.vmdk /var/lib/vz/import/VMname.qcow2

• Inspect the descriptor and its referenced files before converting:

qemu-img info /var/lib/vz/import/VMname/VMname.vmdk

Virtual capacity and allocated size help estimate space requirements. Conversion time also depends on storage performance, the network, image layout, and options.

Step 3: create the destination VM and import its disk

• Create a VM without a disk. Match the source's BIOS or UEFI firmware, configure CPU and memory, and choose a machine type and network bridge compatible with the guest.
• Use a free VM ID, such as 105 in these examples.
• Import the converted disk into the target storage. This example uses raw output on local-zfs:

qm importdisk 105 /var/lib/vz/import/VMname.qcow2 local-zfs --format raw

• Select the resulting Unused Disk 0 in the Hardware tab.
  • Attach it with VirtIO SCSI when the guest has the driver, or initially use SATA for a Windows guest without that driver.
  • Save the disk attachment.
• In Options → Boot Order, enable the imported boot disk and put it first.
• Boot and validate the guest while keeping the original ESXi VM off.

ovftool vi://root@esxi-host-ip/VMname /staging/VMname.ova

scp /staging/VMname.ova root@proxmox-host:/var/lib/vz/import/

qm importovf 105 /var/lib/vz/import/VMname/VMname.ovf local-zfs --format raw

Post-migration guest configuration

Settings to review after migration

Windows drivers and guest tools

• If Windows cannot boot through VirtIO, attach the boot disk through a compatible SATA controller. Install and activate the appropriate VirtIO storage driver before changing it back; a temporary small VirtIO disk can help Windows load that driver.
• After migration, remove VMware Tools if no longer required. Check Device Manager for devices and drivers that need attention.
• Install the QEMU Guest Agent from the appropriate installer in the VirtIO ISO's guest-agent directory, and enable the agent in the VM options.

Linux network configuration

• Inspect network device names after migration rather than assuming the ESXi name will remain unchanged.
• List the guest interfaces:

ip addr show

• Review the existing Netplan configuration on Ubuntu:

sudo nano /etc/netplan/00-installer-config.yaml

• Update the interface name and settings as needed, then apply the configuration:

sudo netplan apply

• Enable QEMU Guest Agent in the VM options on Proxmox. If the communication channel is not available, shut down the guest and start the VM again. Inside a Debian or Ubuntu guest, install the package and start the service:

sudo apt install qemu-guest-agent && sudo systemctl start qemu-guest-agent

Check the service inside the guest with systemctl status qemu-guest-agent. On the Proxmox host, test communication with qm agent 105 ping, replacing 105 with the actual VM ID. Follow the guest distribution's instructions for automatic startup.

VMFS and VMDK recovery during migration

Storage risks to plan for

Copying and converting disks introduces additional files and storage dependencies. Check these failure cases before cutover:

• An interrupted SCP transfer can leave an incomplete destination VMDK. The original consistent source should remain available for another copy.
• Source storage failures during a transfer can interrupt access to the VM's files.
• Thin disks can require more destination space than expected. Running out of space can interrupt conversion, so retain the source and backup until validation is complete.

When a VMFS datastore becomes inaccessible

A storage path, controller, or metadata problem can stop Proxmox from reading source VMDKs. Diagnose that problem before retrying the migration.

• Stop the transfer and distinguish an incomplete destination copy from a damaged source disk.
• Ordinary ext4 or NTFS tools do not interpret VMFS metadata.
• Some data may remain readable on the source storage, but recovery depends on the failure and surviving files.

Recovering readable VM data

DiskInternals VMFS Recovery™ can examine VMFS storage and VMDKs when the original VMware environment cannot provide access. Available recovery functions include:

• Open readable VMDKs without a running ESXi host.
• Scan VMFS metadata to locate recoverable files and datastore structures.
• Recover available VMDK disks and VMX configuration files.
• Connect to an accessible ESXi host and save readable VM files to separate staging storage.

Validate recovered files before using them in the migration workflow:

1. Convert a complete, consistent disk to QCOW2 or raw where necessary.
2. Import the disk and attach it to the destination VM.
3. Review the hardware configuration, then boot and check the guest.

FAQ

Related articles

FREE DOWNLOADVer 4.28, WinBUY NOWFrom $699