Professional VMware to Proxmox migration migrate from VMware ESXi to Proxmox — complete technical guide

// Table of Contents

Prerequisites and PVE preparation
VMware inventory and audit
Migration methods comparison
Matrix: Wizard vs virt-v2v vs OVF
ESXi Import Wizard step-by-step
virt-v2v workflow (vmware to proxmox converter)
Network mapping: VLANs and bridges
Storage design: ZFS, iSCSI, Ceph
Guest tuning: VirtIO for Windows and Linux
Edge cases: snapshots, vSAN, Windows BSOD
HA cluster migration on Proxmox
Validation checklist and near-live cutover
Rollback and VMware decommission
Pre-cutover checklist (printable)

01 Prerequisites

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.1 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 delete snapshots or power off ESXi hosts until validation is complete.

ℹ️

Production HA topology: minimum 3 Proxmox nodes for Corosync quorum (pmxcfs). A two-node cluster cannot safely survive a single host failure without risking split-brain.

Infrastructure checklist

Proxmox VE 8.1+ 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/vSphere account with VM and datastore read access (vCenter optional; direct ESXi import is 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)

pve-prep.sh
# Verify PVE version and ESXi import package
root@pve1# pveversion -v | grep -E 'pve-manager|pve-esxi'
root@pve1# apt install pve-esxi-import-tools -y
 
# Test connectivity to ESXi host (port 443)
root@pve1# openssl s_client -connect esxi01.company.com:443 -brief </dev/null
 
# Next free VMID in cluster
root@pve1# pvesh get /cluster/nextid
✓ PVE ready for import · next VMID: 200

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.

02 Inventory

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.

vmware-inventory.ps1
# Export inventory via PowerCLI
PS> Connect-VIServer -Server vcenter.company.com
PS> Get-VM | Select-Object Name,PowerState,NumCpu,MemoryGB,VMHost,@{N='ProvisionedGB';E={($_.ExtensionData.Summary.Storage.Uncommitted+$_.ExtensionData.Summary.Storage.Committed)/1GB}} | Export-Csv vm-inventory.csv -NoTypeInformation
 
# Snapshots and VMware Tools status
PS> Get-VM | Get-Snapshot | Select VM,Name,SizeGB,Created | Export-Csv snapshots.csv -NoTypeInformation
PS> Get-VM | Select Name,@{N='Tools';E={$_.ExtensionData.Guest.ToolsVersionStatus}} | Export-Csv tools-status.csv -NoTypeInformation
 
# Port groups and VLAN IDs
PS> Get-VirtualPortGroup | Select Name,VLanId,VirtualSwitch | Export-Csv portgroups.csv -NoTypeInformation
 
# Datastores and utilization
PS> Get-Datastore | Select Name,Type,CapacityGB,FreeSpaceGB | Export-Csv datastores.csv -NoTypeInformation
✓ Exported 52 VMs · 14.2 TB provisioned · 8 port groups · 5 datastores

How to interpret each record

VMs with snapshots — consolidate before import or plan a separate virt-v2v conversion
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 outdated VMware Tools — update before Windows migration (simplifies later VirtIO installation)
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.

03 Methods

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.

Method	Description	Downtime	Best for
ESXi Import Wizard	Native PVE 8.1+ importer via ESXi API; maps VMX → QEMU config	VM powered off on ESXi (live-import option starts VM on PVE earlier)	Standard ESXi 6.5–8.0 VM migration
virt-v2v (libguestfs)	Converts VMDK → qcow2/raw + installs VirtIO drivers in guest	VM powered off during conversion	Windows/Linux, large disks, automatic VirtIO
OVF/OVA import	`qm importovf` or GUI wizard for exported templates	Depends on OVA size	VMs without direct ESXi access, OVF templates
Attach-and-move (VMDK)	Copy VMDK files to PVE storage + `qm disk import`	VM powered off	Single disks, NFS shared between ESXi and PVE
Near-live cutover	Full online copy + delta sync + brief source shutdown	Seconds–minutes (NOT native ESXi live migrate)	HA production, databases, critical services

⚠️

Live-import in PVE starts the VM on Proxmox after copying minimal boot data — the VM on ESXi must still be powered off. This reduces downtime but is not equivalent to vMotion or live migration without shutting down the source.

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.

Criteria	ESXi Import Wizard	virt-v2v	OVF / OVA
ESXi API access required	Yes (443/tcp)	Optional (VDDK)	No — export file only
VM on vSAN	Not supported	After disk staging off vSAN	Yes, via vCenter OVF export
VM snapshots	Blocks import — consolidate first	VM must be snapshot-free	Export typically without snapshots
Auto VirtIO (Windows)	Partial — often manual post-import	Yes (virtio-win injection)	No — manual driver install
VMX → QEMU mapping	Automatic	Manual `qm set`	From OVF metadata
Proxmox GUI	Full wizard	CLI on conversion host	`qm importovf` + GUI
Batch (dozens of VMs)	API / `qm import` scripts	Scalable via Ansible/cron	One VM per export
Typical downtime	Full offline import	Offline conversion	Depends on OVA size
Choose when	Standard ESXi 6.5–8.0, local/SAN datastore	Windows, unusual disks, bulk conversion	vSAN, no API, archival VMs

30-second method picker checklist

Datastore is vSAN or encrypted VMDK? → OVF/OVA or virt-v2v after staging off vSAN
Snapshots on the VM? → remove or consolidate before any method
Windows without VirtIO? → virt-v2v or pre-install virtio-win on ESXi, then Wizard
Single VM, ESXi online, no exceptions? → Import Wizard
No host access, files only? → OVF or local virt-v2v -i disk

04 Import Wizard

ESXi Import Wizard — step by step

The official Import Wizard (PVE 8.1+) 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.

Add ESXi source

In the GUI: Datacenter → Storage → Add → ESXi. Enter host IP/FQDN and administrator credentials. For self-signed certificates, add the CA to the trust store or check "Skip Certificate Verification" (lab only).

Select VM and target storage

Browse the ESXi storage content, select the VM, click Import. Map network interfaces to vmbr bridges. Choose target storage (e.g. local-zfs, ceph-pool).

Power off VM on ESXi and run import

Standard import requires the VM to be powered off on the source. Optionally enable live-import so PVE starts the guest after copying boot-critical data.

qm-import-esxi.sh
# After adding ESXi storage "esxistore" in /etc/pve/storage.cfg
root@pve1# VMID=$(pvesh get /cluster/nextid)
root@pve1# qm import $VMID esxistore:ha-datacenter/datastore1/prod-web/prod-web.vmx --storage local-zfs
 
# Network mapping after import (net0 → vmbr0 VLAN 100)
root@pve1# qm set $VMID --net0 virtio,bridge=vmbr0,tag=100
 
# Start and verify
root@pve1# qm start $VMID
root@pve1# qm status $VMID
✓ Import complete · VMID 200 · status: running

💡

Import through vCenter works but is significantly slower than direct ESXi host import. In production we recommend adding each ESXi host as a separate import source.

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

05 virt-v2v

virt-v2v workflow — vmware to proxmox converter

virt-v2v from the libguestfs project is a proven VMware-to-KVM disk converter. It automatically installs VirtIO drivers in Windows (via virtio-win) and updates initramfs on Linux. Use it when Import Wizard hits unusual VMX configurations, when you need offline conversion on a dedicated conversion host, or when batch-processing dozens of VMs with consistent virtio injection.

Install virt-v2v on a Linux conversion host (Debian/Ubuntu/RHEL) or directly on a Proxmox node with sufficient disk space. For vCenter access, install VMware VDDK libraries (libguestfs-tools + VDDK in /usr/lib/vmware-vix-disklib).

virt-v2v-proxmox.sh
# Conversion via vCenter API (VM must be powered off)
$ virt-v2v -ic vpx://vcenter.company.com/Datacenter/cluster/esxi01 \
    -it vddk \
    --vddk-libdir /usr/lib/vmware-vix-disklib \
    -o local -os /var/lib/vz/images/200 \
    -of qcow2 \
    "prod-db-01"
 
# Create VM and attach disk in Proxmox
root@pve1# qm create 200 --name prod-db-01 --memory 16384 --cores 8 --net0 virtio,bridge=vmbr0
root@pve1# qm importdisk 200 /var/lib/vz/images/200/prod-db-01-sda qcow2 local-zfs
root@pve1# qm set 200 --virtio0 local-zfs:vm-200-disk-0 --boot order=virtio0 --agent enabled=1
✓ Conversion: 240 GB VMDK → 178 GB qcow2 · VirtIO installed in guest

Alternative: local VMDK conversion

If VMDK files are already copied to the PVE host:

virt-v2v-local.sh
$ virt-v2v -i local -i disk /mnt/import/vm-disk.vmdk -o local -os /var/lib/vz/images/201 -of qcow2
root@pve1# qm disk import 201 /var/lib/vz/images/201/vm-disk.qcow2 local-zfs --format qcow2

virt-v2v supports Windows Server 2008 R2 through 2025, RHEL/CentOS/Rocky/Alma 7–9, Ubuntu LTS, Debian, SLES, and Oracle Linux. Always test one representative VM per OS generation before batch conversion.

06 Network

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.

VMware	Proxmox VE	Example
vSS / vDS portgroup VLAN 100	bridge=vmbr0,tag=100	Application production
Portgroup without VLAN (native)	bridge=vmbr0 (no tag)	Management
vDS LACP uplink	Linux bond + vmbr or OVS bridge	2×25 GbE aggregation
NSX overlay	SDN EVPN/VXLAN (separate project)	Micro-segmentation

/etc/network/interfaces (excerpt)
auto vmbr0
iface vmbr0 inet static
  address 10.0.10.11/24
  gateway 10.0.10.1
  bridge-ports bond0
  bridge-stp off
  bridge-vlan-aware yes
 
# VM on VLAN 200: qm set 200 --net0 virtio,bridge=vmbr0,tag=200

ℹ️

After migration verify MAC addresses and firewall rules (iptables/nftables, Proxmox firewall). Interface reordering (eth0/eth1) in the guest may require netplan fixes or /etc/udev/rules.d/70-persistent-net.rules updates on Linux.

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.

07 Storage

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:

Local-ZFS

Simple start: each node has its own ZFS pool. No shared storage — live migration requires copying disks over the network. Good for smaller clusters and dev/test. Use ZFS snapshots for local backup before risky changes.

iSCSI / NFS (SAN)

Shared LUN or NFS export mounted on all nodes. Enables native live migration between PVE hosts (qm migrate). Integrates with existing SAN after VMFS decommission. Match LUN alignment and thin-provisioning policies to your RPO/RTO targets.

Ceph RBD

Distributed storage built into Proxmox — 3× replication, self-healing, horizontal scaling. Requires dedicated storage network (minimum 10 GbE, recommended 25 GbE). A vSAN replacement without Broadcom licensing. Plan MON + OSD topology before the first VM import.

storage-example.sh
# Add iSCSI LUN as LVM-thin storage
root@pve1# pvesm add iscsi iscsi-san --portal 10.0.20.50 --target iqn.2024-01.com.company:prod
root@pve1# pvesm add lvmthin iscsi-thin --thinpool data --vgname pve-iscsi --content images,rootdir
 
# Local ZFS pool status
root@pve1# zpool list && zfs list

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.

08 VirtIO

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 drivers automatically. QEMU Guest Agent enables clean shutdowns, IP reporting, and freeze/thaw for application-consistent backups.

Windows Server

Mount virtio-win.iso (available from Proxmox repositories or virtio-win.org)
Install drivers: VirtIO SCSI, VirtIO Net, QEMU Guest Agent
Enable QEMU Guest Agent in VM config: --agent enabled=1
Verify boot: switch disk controller to VirtIO SCSI before reboot
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. The disk boots on emulated SATA/IDE from Import Wizard, but VirtIO drivers are missing from the boot volume.

Method A (recommended): on the running VM in ESXi mount virtio-win.iso, install VirtIO SCSI + Net + Guest Agent, then import and switch controller
Method B: after import keep disk on SATA/IDE, boot, install VirtIO from ISO, switch to VirtIO SCSI, reboot
Method C: virt-v2v injects drivers during conversion — lowest BSOD risk on first PVE boot
After migration uninstall VMware Tools — leftover VMware services can conflict with QEMU Guest Agent
Verify UEFI vs BIOS — Import Wizard preserves firmware; with OVF check qm set <vmid> --bios ovmf vs seabios

windows-post-migrate.ps1
# Remove VMware Tools after successful Proxmox boot
PS> Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like '*VMware Tools*' } | ForEach-Object { $_.Uninstall() }
 
# Verify QEMU Guest Agent
PS> Get-Service QEMU-GA | Select Status, StartType
✓ Guest Agent: Running · VMware Tools removed

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

qm-virtio-tuning.sh
root@pve1# qm set 200 --scsihw virtio-scsi-pci --scsi0 local-zfs:vm-200-disk-0
root@pve1# qm set 200 --net0 virtio,bridge=vmbr0,tag=100
root@pve1# qm set 200 --agent enabled=1
root@pve1# qm set 200 --serial0 socket

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.

09 Edge cases

Edge cases: snapshots, vSAN, Windows BSOD

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

1. Snapshots block Import Wizard

The importer refuses to start when snapshot chains exist. Consolidate or delete snapshots before import — not during.

remove-snapshots.ps1
PS> Get-VM prod-app-01 | Get-Snapshot | Select Name,SizeGB,Created
PS> Get-VM prod-app-01 | Remove-Snapshot -Snapshot (Get-Snapshot -Name 'backup-2026-06') -RemoveChildren -Confirm:$false
PS> Get-VM prod-app-01 | Get-View | ForEach-Object { $_.RunConsolidateVM_Task() }
✓ Snapshots removed · disk consolidated · ready to import

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, disk already off vSAN)
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 file to copy. Convert RDM to VMDK (Storage vMotion) before migration, or plan PCIe passthrough in Proxmox for exceptions (e.g. licensed HBA).

4. Encrypted VMs and vTPM

VM Encryption requires KMS key export or OVF export with decryption in vCenter. vTPM does not transfer 1:1 — recreate TPM in QEMU config or disable TPM requirement in the application before cutover.

5. VLAN — VM boots but no network

Most common post-migration network issue: wrong VLAN tag or missing bridge-vlan-aware yes on the host.

Symptom	Cause	Fix
No IP after boot	Wrong tag in `qm set --net0`	Match VMware port group VLAN ID with PVE `tag=`
eth0 → eth1 on Linux	NIC reordering	netplan / `70-persistent-net.rules`
Windows “unidentified network”	New MAC → new profile	Reassign static IP or reset network profile
Traffic blocked despite IP	PVE firewall / no trunk	`bridge-vlan-aware yes` + verify switch port mode

6. Windows BSOD 0x7B on first reboot

See VirtIO section above. Short version: do not switch to VirtIO SCSI until drivers are in the boot volume. virt-v2v handles this automatically; with Wizard — pre-install on ESXi or boot via SATA.

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.

10 HA

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.

VMware	Proxmox VE	Migration notes
vSphere HA	pve-ha-manager + 3-node quorum	Enable HA only after VMs on shared storage
DRS	Dynamic Load Balancer (PVE 9.2+)	Requires HA + affinity rules
vMotion within vSphere	`qm migrate` between PVE nodes	Only with shared storage (SAN/Ceph)
FT (Fault Tolerance)	No 1:1 — application replication	Plan active/passive or K8s/DB cluster

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

ℹ️

Without shared storage Proxmox HA restarts VMs on another node but does not move disks — you need iSCSI/NFS/Ceph or ZFS/ceph replication.

11 Validation

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.

Initial copy (VM online on ESXi)

Import Wizard with live-import option, or preparatory rsync/virt-v2v run. Production VM continues running on VMware.

Testing on PVE (isolated network)

Start the copy on Proxmox in a test VLAN. Verify login, services, database connectivity, and application health endpoints.

Final cutover

Power off VM on ESXi, run final delta sync, start on PVE, switch DNS/load balancer. Typical downtime: 30 s – 2 min. For HA pairs behind a load balancer, migrate one instance at a time for zero perceived downtime.

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.

12 Rollback

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 VMware snapshots and datastores intact through the observation period.

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

🎯

Always document rollback in writing: for each critical VM record RTO, decision owner, and switch steps (DNS, VIP, firewall). Test rollback in staging before production cutover.

Rollback runbook (template)

Step	Action	Owner	Time
1	Stop VM on Proxmox (`qm stop`)	PVE admin	30 s
2	Start original VM on ESXi (pre-cutover snapshot)	VMware admin	1–2 min
3	Switch DNS / VIP / firewall to VMware addresses	Network team	1–5 min
4	Application verification (health check, logs)	App owner	5–15 min
5	User communication + post-mortem	IT manager	—

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 ESXi source
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

No — there is no native vMotion equivalent between ESXi and KVM. Import Wizard requires the VM to be powered off on ESXi for standard import. The live-import option reduces downtime by starting the VM on PVE early, but the source must still be stopped. Near-live cutover (copy + delta) is a separate engineering procedure.

Proxmox VE 8.1 or later with the pve-esxi-import-tools package (pve-manager ≥ 8.1-8, libpve-storage-perl ≥ 8.1.3). Tested with ESXi 6.5–8.0. Older environments migrate via virt-v2v or OVF/VMDK import.

The tools are complementary. Import Wizard is faster for GUI/API integration and automatic VMX mapping. virt-v2v (libguestfs) excels at offline batch conversion, unusual disk layouts, and automatic VirtIO installation — especially on Windows.

Minimum 3 nodes for safe Corosync quorum. With 2 nodes, a single host failure can lock the cluster (split-brain). Proxmox HA (pve-ha-manager) requires shared storage or replication for live migration between nodes.

Remove or consolidate all snapshots on the VM in vSphere before import. This is the most common failure cause. After disk consolidation, retry import — see snapshots edge case.

Not directly. Storage vMotion off vSAN, export OVF, or use virt-v2v after disk staging. Details in the vSAN section.

Boot from SATA/IDE controller, install VirtIO SCSI from virtio-win.iso, then change disk type in qm set. Alternatively use virt-v2v which injects drivers during conversion. See VirtIO / BSOD.

Two tools act as a VMware to Proxmox converter: the built-in Import Wizard in Proxmox VE and virt-v2v. Both convert VMDK disks to the QEMU format (QCOW2/raw) and inject VirtIO drivers, so you do not need any separate conversion software to migrate VMware VMs to Proxmox.

Yes — we migrate VMware VMs to Proxmox in batches, grouping machines by dependency. For larger estates we script the virt-v2v conversion so the process is repeatable and auditable, with a rollback point for every batch and minimal downtime per workload.

Yes. An enterprise VMware to Proxmox migration — a full VMware to Proxmox VE migration — covers an HA cluster (minimum 3 nodes), shared storage (Ceph/iSCSI/NFS), VLAN network mapping and a near-zero-downtime cutover. We handle environments from a handful to well over 100 VMs.

Need help with your migration?

We audit your VMware environment and execute vmware to proxmox migration with rollback guarantees and minimal downtime, as part of our end-to-end Proxmox implementation services.

⚡ Free Environment Analysis