Professional VMware to Proxmox migration
migrate from VMware ESXi to Proxmox — delivery with a full technical playbook

Prerequisites and PVE preparation

A production-grade vmware to proxmox migration starts with a stable target cluster — not with copying the first virtual machine. Proxmox VE 8.2 and later ships the integrated ESXi Import Wizard (package pve-esxi-import-tools) for VMware ESXi 6.5 through 8.0. Older PVE releases still support migration through virt-v2v, OVF import, or manual VMDK attach-and-move workflows.

Before touching production workloads, take a verified backup of every VMware VM (Veeam, NetBackup, or storage-level snapshots) and configure Proxmox Backup Server or scheduled vzdump jobs on the destination cluster. VMware remains the source of truth until formal cutover — do not power off ESXi hosts until validation is complete. Delete all VM snapshots before import, because they slow it down. The rollback point is the original powered-off VM on ESXi plus the backup — no snapshot is needed for that.

Infrastructure checklist

• Proxmox VE 8.2+ fully patched with pve-esxi-import-tools installed
• Management network: 1 GbE minimum; large VM migrations benefit from a dedicated 10/25 GbE VLAN between ESXi and PVE
• ESXi administrator account (e.g. root) — vCenter is not required, and importing directly from the ESXi host is much faster
• Target storage: local-zfs, NFS, iSCSI, or Ceph — free space ≥ 120% of VM size (snapshots, logs, buffer)
• Proxmox Backup Server or vzdump schedule configured before production migration
• VLAN mapping document: VMware port groups → Proxmox vmbr bridges
• Maintenance window for final import (VM must be powered off on ESXi for standard import)

Network planning deserves equal attention. Separate management, storage, migration, and guest traffic onto dedicated VLANs where possible. Corosync cluster traffic should use a low-latency link — never route it over a congested production LAN. If you plan Ceph, reserve a dedicated 10/25 GbE network before installing OSDs.

VMware inventory and audit

Without a complete inventory you cannot choose the right migration method or estimate cutover time. Collect VM resource usage, application dependencies, network configuration, and exceptions (RDM disks, vGPU passthrough, vSAN-backed VMs that the native importer cannot read).

PowerCLI remains the standard tool for VMware inventory export. Run scripts against vCenter for a cluster-wide view, or connect directly to standalone ESXi hosts for smaller environments. Store exports in version control or a secure document repository — they become the baseline for post-migration validation.

How to interpret each record

• VMs with snapshots — delete them all before import (the importer still starts with snapshots, only more slowly)
• RDM (physical mode) disks — not supported by Import Wizard; migrate to VMDK or PCIe/NVMe passthrough first
• vSAN — not supported by the native importer; use OVF export or virt-v2v over the network
• VMs with VMware Tools installed — uninstall them on ESXi before migration (especially on Windows); removing them after the move to Proxmox can be difficult
• Application HA pairs — mark cluster members for near-live migration (one instance at a time)

Classify VMs into migration waves: non-critical dev/test first, then internal services, then production databases and customer-facing applications. Each wave should have a defined rollback owner and communication plan.

Migration methods comparison

Proxmox does not offer a native equivalent of vMotion from ESXi to KVM — near-live cutover is an engineering process (background copy + short source shutdown), not a one-click live migration between hypervisors. The table below helps you pick the right tool for scale and VM type.

Decision matrix: Import Wizard vs virt-v2v vs OVF/OVA

Use this vmware to proxmox migration matrix in internal runbooks — link directly to #vtp-method-matrix.

30-second method picker checklist

• Datastore is vSAN? → virt-v2v -it vddk (NBD reads vSAN) or OVF. Use the Import Wizard only after moving the disk off vSAN. Encrypted VMDK? → decrypt in vCenter first, then OVF
• Snapshots on the VM? → delete them all before import. The wizard still starts with snapshots, only more slowly
• Windows without VirtIO? → virt-v2v, or Wizard plus the controller switch via a temporary VirtIO SCSI disk (section 08)
• Single VM, ESXi online, no exceptions? → Import Wizard
• No host access, files only? → OVF or local virt-v2v -i disk

ESXi Import Wizard — step by step

The official Import Wizard (PVE 8.2+) adds an "ESXi" source under Datacenter → Storage → Add. The importer uses the public ESXi API — no proprietary VMware hooks. For automation, use the equivalent qm import command.

Pass the source VM's MAC address in virtio= (from the .vmx file — ethernet0.address or ethernet0.generatedAddress — or from qm config $VMID right after import). Without it Proxmox generates a random MAC, which breaks DHCP reservations and MAC-bound licences.

The Proxmox API exposes the same workflow: first call GET /nodes/{node}/storage/{storage}/content?content=import to list importable VMs, then GET /nodes/{node}/storage/{storage}/import-metadata?volume= for the chosen VMX, then POST /nodes/{node}/qemu with import-from= syntax for disk volumes. This enables Ansible or Terraform pipelines for large-scale migrations.

virt-v2v workflow — vmware to proxmox converter

virt-v2v from the libguestfs project is a proven VMware-to-KVM disk converter. It injects VirtIO drivers in Windows only when virtio-win is present on the conversion host (a directory or an ISO); on Linux it rebuilds initramfs. Use it when Import Wizard hits unusual VMX configurations, when you need offline conversion on a dedicated conversion host, or when batch-converting many VMs the same way.

Install virt-v2v on a Linux conversion host (Debian/Ubuntu/RHEL) or directly on a Proxmox node with sufficient disk space. It is a separate package (apt install virt-v2v); for vCenter access, also unpack the VMware VDDK library into /opt/vmware-vix-disklib. The example below converts prod-db-01 to VMID 201 (VMID 200 is already taken by prod-web from the Import Wizard).

Alternative: local VMDK conversion

If VMDK files are already copied to the PVE host:

virt-v2v 2.6, the version shipped with Proxmox VE 9, supports Windows Server 2008 R2 through 2022. Windows Server 2025 needs virt-v2v 2.8, which Debian 13 does not ship. It also supports RHEL/CentOS/Rocky/Alma 7–9, Ubuntu LTS, Debian, SLES, and Oracle Linux. Always test one representative VM per OS generation before batch conversion.

Network mapping: VLANs and bridges

Map VMware port groups with VLAN IDs to Linux bridges with 802.1Q tags. In Proxmox the standard pattern is vmbr0 as a VLAN-aware trunk carrying multiple guest VLANs, or dedicated bridges per segment for simpler firewall rules.

For environments migrating from NSX or complex vDS policies, plan a parallel networking phase: stand up Proxmox SDN or EVPN/VXLAN fabrics before cutover so security groups and micro-segmentation rules are ready on day one.

Storage design: ZFS, iSCSI, Ceph

Storage choice determines live migration between PVE nodes, I/O performance, and total cost. The three most common models when migrating from VMware:

When sizing storage, account for Proxmox snapshots, PBS deduplication, and Ceph recovery overhead. A rule of thumb: provision 130–150% of current VMware used capacity for the first year of growth.

Guest tuning: VirtIO for Windows and Linux

After migration replace emulated VMware devices (vmxnet3, LSI Logic) with VirtIO for better performance and lower CPU overhead. Import Wizard partially maps interfaces. virt-v2v installs Windows drivers only when virtio-win is present on the conversion host. QEMU Guest Agent enables clean shutdowns, IP reporting, and freeze/thaw for application-consistent backups.

Windows Server

• Before migration, still on ESXi: uninstall VMware Tools via Control Panel (Programs and Features) right before powering off the VM — removing them after the move to Proxmox can be difficult
• Mount virtio-win.iso — it is not in the Proxmox repositories; download it from the Fedora project: fedorapeople.org/groups/virt/virtio-win/direct-downloads/
• Install drivers from the virtio-win-guest-tools package: VirtIO SCSI, VirtIO Net, QEMU Guest Agent
• Enable QEMU Guest Agent in VM config: --agent enabled=1
• Switch the system disk controller to VirtIO SCSI only after Windows has loaded the vioscsi driver (temporary-disk procedure below)
• Check Windows activation — motherboard UUID change may require KMS reactivation

Windows Server — avoiding BSOD (0x7B INACCESSIBLE_BOOT_DEVICE)

The most common failure after vmware to proxmox migration on Windows: blue screen 0x0000007B right after switching the disk controller to VirtIO SCSI. For Windows guests the Import Wizard offers a “Prepare for VirtIO-SCSI” option (checked by default for UEFI boot): it maps SCSI disks to SATA and sets the controller to VirtIO SCSI. Without it the disks stay on the SCSI controller mapped from the VMX file (LSI or PVSCSI). A SATA disk boots straight away, but installing virtio-win alone is not enough: until Windows detects a device on the VirtIO SCSI controller, it does not load the vioscsi driver at boot and cannot find the boot volume.

• Method A (preparation on ESXi): on the running VM mount virtio-win.iso and install virtio-win-guest-tools. The VirtIO SCSI driver must be installed and set to boot-start — the installer alone does not guarantee that, so after import the temporary-disk step (Method B) is still the safest option
• Method B (recommended): after import the system disk should be on SATA or IDE — the only buses Windows handles without extra drivers, so if the wizard left it on SCSI, reattach it before the first boot; boot the VM; install virtio-win-guest-tools from the ISO; add a small temporary disk on the VirtIO SCSI controller and boot so Windows loads vioscsi; shut down, remove the temporary disk, reattach the system disk as scsi0 on VirtIO SCSI, set the boot order and start the VM
• Method C: virt-v2v injects drivers during conversion when virtio-win is on the host (on PVE 9 you must supply the ISO — section 05) — lowest BSOD risk on first PVE boot
• Uninstall VMware Tools before migration, while still on ESXi — leftover VMware services can conflict with QEMU Guest Agent, and removing them after migration can be difficult
• Verify UEFI vs BIOS — Import Wizard preserves firmware; with OVF check qm set <vmid> --bios ovmf vs seabios

Linux

• Modern kernels include virtio_blk/virtio_scsi modules by default
• After virt-v2v: update-initramfs -u (Debian/Ubuntu) or dracut --force (RHEL)
• Install qemu-guest-agent and enable the service
• Check lsblk and fstab — device names may change from /dev/sda to /dev/vda

Example for VM 201 (prod-db-01 from the virt-v2v section): move the disk from virtio0 to scsi0 and put the NIC on VLAN 100 with the original MAC address. On Windows, do the temporary VirtIO SCSI disk step described above first.

CPU type selection also matters post-migration: start with x86-64-v2-AES or x86-64-v3 for broad live-migration compatibility across heterogeneous hosts, then tighten to host only on dedicated single-socket database nodes. See our CPU type guide for details.

Edge cases: snapshots, vSAN, Windows BSOD

Most failed imports are source-state issues, not Proxmox bugs. Seven common problems during vmware to proxmox migration and how to fix them.

1. Snapshots slow the Import Wizard

A VM with snapshots still imports, but much more slowly. Ideally the VM has no snapshots at all: delete them before import. That shortens the run, although the importer does not require it to start.

2. vSAN VMs — Import Wizard will not work

The native importer reads datastores via ESXi API — vSAN objects are not exportable on that path. Workarounds:

• Storage vMotion VM to NFS/VMFS (off vSAN) — then Import Wizard
• Export OVF/OVA from vCenter → qm importovf on Proxmox
• virt-v2v via VDDK from vCenter (VM powered off; NBD reads vSAN and does not require moving the disk)
• Large VMs: clone to staging LUN, import from staging, delete clone after validation

3. RDM and independent disks (physical mode)

Physical-mode RDM has no VMDK data file to copy, and Storage vMotion of such a disk moves only the mapping file — the data stays on the LUN. To get a VMDK, do a cold migration (VM powered off) to another datastore with a Thin Provision or Thick Provision target disk format, or detach the RDM, re-add the same LUN as a virtual-mode RDM and run Storage vMotion with a disk format change. Alternatively, plan direct LUN attachment to the VM in Proxmox or PCIe passthrough for exceptions (e.g. licensed HBA).

4. Encrypted VMs and vTPM

Encrypted VM disks (e.g. via a VM Encryption storage policy) cannot be imported — remove the encryption first by assigning a non-encrypting storage policy in vCenter. vTPM state cannot be migrated from VMware to Proxmox — add a new TPM device in the QEMU config, and if full-disk encryption keys (e.g. BitLocker) are sealed in the vTPM, disable the encryption before migration or keep the recovery key at hand.

5. VLAN — VM boots but no network

Most common post-migration network issue: a wrong VLAN tag, or a bridge missing bridge-vlan-aware yes and bridge-vids.

6. Windows BSOD 0x7B on first reboot

See VirtIO section above. Short version: do not switch the system disk to VirtIO SCSI right after installing the drivers. virt-v2v injects drivers only when virtio-win is on the host. With the Wizard the disk lands on SATA only when “Prepare for VirtIO-SCSI” is enabled (the default for UEFI); without it the disk stays on the SCSI controller from the VMX and must be moved to SATA or IDE before the first boot. Then install virtio-win, add a temporary disk on VirtIO SCSI and boot so Windows loads vioscsi — only then remove the temporary disk and move the system disk to scsi0.

7. Import Wizard “certificate verify failed”

ESXi uses self-signed certs. In lab: skip verification. In production: add ESXi cert to PVE trust store or use FQDN matching the certificate SAN.

HA cluster migration on Proxmox

VMware HA (vSphere DRS/HA) has no direct equivalent during ESXi → PVE migration. Enable Proxmox HA after VMs run on shared storage with a minimum of 3 nodes.

Application cluster migration order

• Migrate passive / secondary node first — validate on isolated VLAN
• Switch traffic (DNS/LB) to the PVE instance
• Migrate primary in maintenance window (near-live cutover)
• Add both VMs to HA group only after failover tests
• Set anti-affinity rules so replicas do not land on the same node

Validation checklist and near-live cutover

Near-live cutover is a phased sequence that minimizes downtime — it is not native live migration from ESXi. Use it for production systems where seconds to minutes of unavailability are acceptable.

Pre-production validation checklist

• Clean VM boot — Proxmox console and guest system logs
• Network: gateway ping, DNS resolution, application port tests (curl, nc)
• Disk: I/O performance (fio or CrystalDiskMark on Windows)
• PBS backup: first full backup after migration with verified restore test
• Monitoring: Prometheus node_exporter or SNMP — alerts configured
• HA: VM added to HA group, failover test in maintenance window
• Documentation: updated CMDB, network diagram, operational runbook

Automate smoke tests where possible: Ansible playbooks that check service ports, HTTP 200 responses, and database query latency against baseline metrics captured during the VMware audit phase.

Rollback and VMware decommission

Until formal decommission, the VMware environment remains ready for rollback. Rollback is typically DNS/VIP switch back to ESXi and starting the original VM — minutes, not hours. Keep the original VMs and datastores intact through the observation period.

• Keep the original powered-off VM on ESXi through the observation period (30–90 days)
• Do not delete VMFS datastores until all VMs are verified on PVE
• After stable period: remove the powered-off VMs from the ESXi inventory and reclaim datastore space
• Close Broadcom licenses / cancel vSphere subscription after management sign-off
• Archive PowerCLI exports and VMware configuration documentation (compliance)

Rollback runbook (template)

Pre-cutover checklist (printable)

Copy or print this list before final production switchover. Anchor: #vtp-checklist.

• VMware backup + PBS snapshot of PVE VM after test
• No snapshots on the source VM; the original VM stays powered off on ESXi
• VirtIO / Guest Agent installed and tested
• VLAN mapping and firewall verified on test VLAN
• DNS TTL lowered (300 s) 24 h before cutover
• Rollback runbook signed by application owner
• Maintenance window and user notice sent
• Monitoring and alerts configured on target VM

Frequently asked questions