Migrate VM from ESXi to Proxmox: ESXi to Proxmox Migration — Complete Step-by-Step Guide for VMware to Proxmox in 2026
Broadcom’s licensing changes made Proxmox VE the go‑to replacement for VMware ESXi. Migration is straightforward if you focus on the essentials:
- Export VM from ESXi.
- Convert disks from VMDK to QCOW2 or RAW with
qemu-img. - Import into Proxmox and adjust VM settings (CPU, RAM, NIC).
- Verify drivers and networking before production use.
This guide gives you the exact steps, commands, and checks to move workloads safely from ESXi to Proxmox — without downtime or data loss.
Why Organizations Migrate VMware to Proxmox in 2026
🔑 The Licensing Reality That Is Driving Migration
The trigger is Broadcom’s 2023 acquisition of VMware. Since then:
- Perpetual licenses eliminated → mandatory subscriptions only.
- Price hikes → 200–1,200% increases for many customers.
- Free ESXi tier removed → February 2024.
- Essentials Plus discontinued → November 2024.
- vSphere 9 locked → available only in VVF and VCF. Standard customers are frozen at vSphere 8, with support ending October 2027.
For environments where per‑core subscription costs exceed budget thresholds, Proxmox VE is the primary migration destination.
⚙️ What Proxmox VE Offers That VMware Does Not
Proxmox VE delivers features without licensing cost:
- Zero licensing fees (AGPLv3 open source).
- KVM + LXC → full VMs and containers on one platform.
- ZFS integration → snapshots, deduplication, compression.
- Ceph cluster support → scalable distributed storage.
- Proxmox Backup Server → image‑level backups.
- Automation → REST API, Ansible integration.
- Web UI → simple management.
- HA clustering → built‑in high availability.
Optional paid support subscriptions provide enterprise repository access and professional ticketed support, but the core platform remains free.
📊 ESXi to Proxmox Migration: Three Methods Compared
| Method | Best For | Downtime Required | Complexity | Tools Required |
|---|---|---|---|---|
| Proxmox Import Wizard | Live ESXi hosts with network access from Proxmox | Minimal (shutdown for final cutover) | Low | Proxmox web UI |
| qemu-img convert (VMDK → QCOW2/RAW) | Offline VMDKs copied from datastore | Yes (VM must be off for export) | Medium | SSH, qemu-img, qm importdisk |
| OVF/OVA import (qm importovf) | VMs already exported to OVF/OVA format | Yes (export from vCenter/ESXi) | Low–Medium | SSH, qm importovf |
| virt-v2v | Windows VMs needing automatic VirtIO driver injection | Yes | Medium–High | virt-v2v, SSH |
Prerequisites: Before Any ESXi to Proxmox Migration
🖥️ ESXi Host Requirements
- Enable SSH → ESXi Host Client: Host → Manage → Services → SSH → Start or via VCSA: Host → Configure → Services → SSH → Start. Required for SCP transfers and ESXCLI commands to locate VMDK paths.
- Verify network connectivity → Proxmox and ESXi must be reachable at IP level. If Proxmox is on a separate VLAN, confirm routing.
- Check datastore space → ESXi VMDKs may be thin‑provisioned. Run code to see actual usage. This determines staging storage needs on Proxmox:
<code class="language-bash">du -sh /vmfs/volumes/datastore1/myvm/</code>
🖥️ Proxmox Host Requirements
- Confirm storage capacity → Calculate:
(actualVMDKsize×VMcount)×1.2
(20% overhead buffer). Ensure target pool (ZFS, LVM, NFS, or directory) has space.
- Update Proxmox VE → Always run latest 8.x before migration:
<code class="language-bash">apt update && apt full-upgrade</code>
`Import Wizard and qemu-img fixes ship in point releases.
📋 Pre‑Migration VM Checklist (Critical for Windows VMs)
- Document IP, hostname, domain membership → needed if NIC drivers change.
- Take a final ESXi snapshot → rollback point.
- Windows VMs: pre‑install VirtIO drivers while still on ESXi.
- Download VirtIO ISO from fedorapeople.org.
- Mount inside VM, install storage + network drivers.
- Prevents post‑migration BSOD.
- Uninstall VMware Tools → avoids driver conflicts in Proxmox/KVM.
- Linux VMs: note NIC name (e.g.,
ens192on ESXi). On Proxmox it changes (e.g.,ens18). Update Netplan or/etc/network/interfacesafter migration.
Method 1: Convert VMware to Proxmox Using the Import Wizard
🛠️ What the Import Wizard Does and When to Use It
Proxmox VE 8.1 introduced the ESXi Import Wizard — a native web UI feature that connects directly to a running ESXi host, lists available VMs, and imports them into Proxmox with automatic VMDK → QCOW2 conversion.
- Best case: ESXi host is still running and reachable.
- Benefit: No manual SCP transfers, no CLI conversion commands.
- Outcome: Fastest, lowest‑complexity migration path.
📋 Step‑by‑Step: Import Wizard Migration
Step 1. In the Proxmox web UI, select the node → click Import (VE 8.1+) or go to node Summary → ESXi Import. Step 2. Enter ESXi host IP, root username, password → click Add. Step 3. Proxmox connects and lists all registered VMs → select the VM to migrate. Step 4. Configure import options:
- Target storage pool.
- Disk format: QCOW2 (snapshots) or RAW (max performance on ZFS).
- Network bridge assignment. Step 5. Click Import → wizard transfers VMDKs over the network and converts automatically. Monitor progress in the task log. Step 6. After import completes → power off VM on ESXi → power on VM in Proxmox → verify boot.
Method 2: Migrate ESXi VM to Proxmox via qemu-img Convert
📂 Step 1: Copy VMDK Files from ESXi to Proxmox via SCP
- Enable SSH on the ESXi host.
- Identify the flat VMDK path:
<code class="language-bash">find /vmfs/volumes/ -name "*-flat.vmdk" | grep VMname</code>
- Copy the file to Proxmox staging:
<code class="language-bash">scp root@esxi-host-ip:/vmfs/volumes/datastore1/VMname/VMname-flat.vmdk /var/lib/vz/import/</code>
- For large disks (100 GB+), use
pvto monitor progress or mount the ESXi datastore directly on Proxmox to avoid copy overhead.
⚙️ Step 2: Convert VMDK to QCOW2 or RAW with qemu-img
- Convert to QCOW2 (snapshots, space‑efficient):
<code class="language-bash">qemu-img convert -p -f vmdk -O qcow2 /var/lib/vz/import/VMname-flat.vmdk /var/lib/vz/import/VMname.qcow2</code>
- Convert to RAW (max performance, no overhead):
<code class="language-bash">qemu-img convert -p -f vmdk -O raw /var/lib/vz/import/VMname-flat.vmdk /var/lib/vz/import/VMname.raw</code>
- Add compression (smaller output, slower conversion):
<code class="language-bash">qemu-img convert -c -p -f vmdk -O qcow2 /var/lib/vz/import/VMname-flat.vmdk /var/lib/vz/import/VMname.qcow2</code>
- Check disk info before conversion:
<code class="language-bash">qemu-img info /var/lib/vz/import/VMname-flat.vmdk</code>
→ shows guest virtual size vs actual used blocks.
🖥️ Step 3: Create a Shell VM in Proxmox and Import the Disk
- Create a new VM in Proxmox web UI → set CPU, RAM, machine type (
q35for UEFI,i440fxfor BIOS), NIC bridge → no disks yet. - Note the VM ID (e.g., 105).
- Import converted disk:
<code class="language-bash">qm importdisk 105 /var/lib/vz/import/VMname.qcow2 local-zfs --format qcow2</code>
- Disk appears as Unused Disk 0 → edit in Hardware tab:
- Set bus to VirtIO SCSI (Linux with VirtIO drivers) or SATA (Windows without drivers yet).
- Click Add.
- Set boot order: VM → Options → Boot Order → enable new disk → move to top.
- Power on VM → verify successful boot.
Method 3: VMware to Proxmox Migration via OVF/OVA Export
📦 Export the VM from ESXi or vCenter as OVF/OVA
- ESXi Host Client → right‑click VM → Export → choose OVF or OVA → download files.
- vCenter → right‑click VM → Export OVF Template → select OVF (folder) or OVA (single archive).
- Command line (ovftool) →
<code class="language-bash">ovftool vi://root@esxi-host-ip/VMname /staging/VMname.ova</code>
📥 Import the OVF/OVA into Proxmox
- Upload OVF/OVA to Proxmox staging via SCP:
<code class="language-bash">scp VMname.ova root@proxmox-host:/var/lib/vz/import/</code>
- Run
qm importovfto create VM from OVF manifest:
<code class="language-bash">qm importovf 105 /mnt/pve/nfs-staging/my-windows-vm.ovf local-zfs --format raw</code>
- This generates VM 105 with disks on
local-zfsin RAW format. - After import, adjust VM settings:
- BIOS/UEFI type (
q35for UEFI,i440fxfor legacy). - CPU type and count.
- Network bridge assignment.
- BIOS/UEFI type (
Migrate VM from VMware to Proxmox: Post-Migration Configuration
📊 Recommended Proxmox VM Settings After Migration
| Setting | Recommended Value | Notes |
|---|---|---|
| Machine type | q35 | Modern PCIe bus; use i440fx only for legacy BIOS requirement |
| BIOS | OVMF (UEFI) | If the source VM used UEFI; SeaBIOS for legacy BIOS |
| CPU type | x86-64-v2-AES or x86-64-v3 | Required for Windows Server 2025 — host causes infinite reboot loop |
| Storage controller | VirtIO SCSI | Best performance; use SATA or IDE for Windows without VirtIO drivers |
| Network adapter | VirtIO (paravirtualized) | Best performance; use e1000 for Windows without VirtIO drivers |
| QEMU Guest Agent | Enabled | Allows Proxmox to see VM IP and perform graceful shutdown |
| Balloon driver | Enabled | Memory ballooning for dynamic memory management |
🖥️ Windows VM Post‑Migration: VirtIO Drivers and VMware Tools
- Blue screen fix → If Windows fails to boot, switch the disk bus back to IDE or SATA, boot, then install VirtIO drivers from the VirtIO ISO (mount ISO as CD in Proxmox hardware). Shut down, change disk bus to VirtIO SCSI, and reboot.
- Remove VMware Tools → Control Panel → Programs → Uninstall VMware Tools. Leaving it installed on KVM causes driver conflicts and log spam.
- Install QEMU Guest Agent → Mount VirtIO ISO → run
virtio-win-guest-tools.exefrom the guest-agent directory.
🐧 Linux VM Post‑Migration: Network Interface Rename
- Interface rename → ESXi NIC
ens192often becomesens18in Proxmox. - Check new name:
<code class="language-bash">ip addr show</code>
- Update Netplan (Ubuntu):
<code class="language-bash">sudo nano /etc/netplan/00-installer-config.yaml</code>
- Change ens192 → new interface name, then:
<code class="language-bash">sudo netplan apply</code>
- Install QEMU Guest Agent:
<code class="language-bash">sudo apt install qemu-guest-agent && sudo systemctl enable --now qemu-guest-agent</code>
ESXi to Proxmox: Common Errors and Fixes
📊 ESXi to Proxmox Migration Error Reference Table
| Error / Symptom | Cause | Fix |
|---|---|---|
| Windows VM blue screens on boot | Missing VirtIO storage drivers | Change disk bus to IDE/SATA temporarily; boot; install VirtIO ISO drivers; switch back to VirtIO SCSI |
| Windows VM boots then reboots in a loop (Server 2025) | Wrong CPU type | Set cputype=x86-64-v2-AES or x86-64-v3 in VM Options — do not use host |
| VM disk size 500 GB but only 80 GB of data — conversion takes forever | Thin VMDK converted at full virtual size | Use -c for qemu-img compression or trim inside guest before export |
| Network unreachable after migration | Interface name changed (ens192 → ens18) | Update Netplan or network interfaces file with new interface name |
| qm importdisk fails — "file format not recognized" | Passing the VMDK descriptor instead of the flat file | Ensure the -flat.vmdk file is used, not the descriptor .vmdk |
| Import Wizard cannot connect to ESXi | SSH not enabled or firewall blocking | Enable SSH on ESXi host; verify port 22 is open between Proxmox and ESXi |
| VM boots but no IP visible in Proxmox UI | QEMU Guest Agent not installed | Install qemu-guest-agent inside the guest OS |
| VMware Tools error messages in guest logs | VMware Tools left installed on KVM host | Uninstall VMware Tools; install VirtIO guest tools and QEMU Guest Agent |
VMFS, VMDK, and Data Recovery During ESXi to Proxmox Migration
⚠️ How Migration Creates VM Data Risk
The ESXi → Proxmox migration window is one of the highest‑risk periods for VM data integrity:
- Interrupted SCP transfer → leaves a partial VMDK on Proxmox, unusable but consuming disk space.
- ESXi host power loss mid‑transfer → source VMDK may be left inconsistent.
- Thin‑provisioned disks → destination may attempt to write full virtual size (e.g., 500 GB) even if only 80 GB is used, exhausting storage mid‑conversion. Any of these scenarios can leave VMDK data inaccessible on the source VMFS datastore.
📉 When VMFS Becomes Inaccessible Mid‑Migration
If the ESXi host’s VMFS datastore goes offline during migration — due to controller failure, LUN reassignment, or metadata corruption from interrupted writes — the source VMDKs become unreachable.
- Migration halts immediately.
- Standard Linux tools on Proxmox cannot parse VMFS.
- Data remains on physical storage but is invisible without VMFS‑aware recovery.
🛠️ Recovering VMFS and VMDK Data with DiskInternals VMFS Recovery™
DiskInternals VMFS Recovery™ is purpose‑built for VMware recovery across ESXi, vSphere, and Workstation. In VMware → Proxmox migration scenarios where VMFS becomes inaccessible mid‑process, it provides:
- Mount VMDKs without ESXi → access disks directly.
- Reconstruct VMFS volumes → repair damaged or partially overwritten metadata.
- Recover deleted/damaged VMDKs + VMX configs → restore critical VM files.
- Remote ESXi host scanning → connect via IP + credentials, extract VMDKs to safe staging storage.
Once extracted, recovered VMDKs follow the standard workflow:
- 1.
qemu-img convert→ QCOW2 or RAW. 2. qm importdisk→ attach to Proxmox VM.- 3. Adjust hardware settings → boot and validate.
FAQ
What is the fastest method to migrate VMware VMs to Proxmox?
The Proxmox Import Wizard (available in PVE 8.1+) is the fastest method when the ESXi host is running and reachable on the network from Proxmox. It eliminates manual file transfer and conversion steps, handling everything through the Proxmox web UI with automatic VMDK-to-QCOW2 conversion.Do I need to shut down the VM to migrate it from ESXi to Proxmox?
For the Import Wizard: the VM can remain running during the initial disk import, but must be shut down for the final cutover (to ensure no data is written to the ESXi VMDK after the import begins). For qemu-img convert and OVF/OVA methods: the VM must be powered off before export to ensure VMDK consistency.Why does my Windows VM blue screen after migrating to Proxmox?
Windows doesn't ship with VirtIO drivers. If you didn't pre-install them while the VM was on ESXi, the post-migration procedure is: change the disk bus back to IDE or SATA in the Proxmox VM hardware settings, boot Windows, install VirtIO drivers from the VirtIO ISO, then switch the disk bus back to VirtIO SCSI.Can I migrate a vSAN VM to Proxmox?
Yes — but not directly.
- Why: vSAN stores VM data in a distributed object format, not standard flat VMDK files. Proxmox cannot read vSAN objects natively.
- Workaround:
- 1. Export the VM from vCenter/ESXi as OVF/OVA. This process reconstructs the VM from vSAN objects into portable VMDK files.
- 2. Copy the exported files to the Proxmox host (via SCP or NFS staging).
- 3. Convert VMDKs with
qemu-imginto QCOW2 or RAW. - 4. Import into Proxmox using
qm importovforqm importdisk.
- Alternative path: If vSAN is degraded or inaccessible, use a VMFS/vSAN‑aware recovery tool (e.g., DiskInternals VMFS Recovery™) to extract VMDKs before conversion.
👉 Bottom line: you cannot migrate vSAN VMs “as is.” You must first export or recover them into standard VMDK files, then follow the same conversion/import workflow used for non‑vSAN VMs.
What is the difference between QCOW2 and RAW format for migrated VMs?
QCOW2 (QEMU Copy‑On‑Write v2)
- Supports snapshots (point‑in‑time rollback).
- Space‑efficient: thin‑provisioned, only consumes actual data blocks.
- Allows compression and encryption.
- Slight performance overhead compared to RAW.
- Best for environments where flexibility and snapshotting matter (e.g., ZFS storage, testing labs).
RAW
- No metadata layer → maximum performance.
- Consumes full allocated size on disk (e.g., 500 GB RAW file even if only 80 GB used).
- No snapshot support, no compression.
- Best for production workloads where speed is critical and storage space is abundant.
👉 Rule of thumb:
- Use QCOW2 if you need snapshots, thin provisioning, or storage efficiency.
- Use RAW if you want raw speed and have enough disk capacity.
How do I migrate VMs with multiple disks from ESXi to Proxmox?
You handle each disk individually, then attach them all to the new VM in Proxmox:
- 1. Identify all VMDK files on the ESXi datastore. Each disk has its own
*-flat.vmdk. - 2. Copy each disk to Proxmox staging via SCP or NFS mount.
- 3. Convert each VMDK with
qemu-imginto QCOW2 or RAW format. Example:
qemu-img convert -p -f vmdk -O qcow2 disk2-flat.vmdk disk2.qcow2
- 4. Create a shell VM in Proxmox (CPU, RAM, NIC, machine type) but no disks.
- 5. Import each disk one by one:
qm importdisk 105 disk2.qcow2 local-zfs --format qcow2
Repeat for all converted disks.
- 6. In the VM’s Hardware tab, attach each imported disk to the right bus:
- OS disk → VirtIO SCSI or SATA (depending on drivers).
- Data/log disks → VirtIO SCSI for performance.
- 7. Set boot order so the OS disk is first.
- 8. Power on VM and verify all disks mount correctly inside the guest OS.
👉 Tip:
- For Windows, check drive letters after migration — they may shift.
- For Linux, confirm UUIDs in
/etc/fstabso data disks mount properly.
- 1. Identify all VMDK files on the ESXi datastore. Each disk has its own