Migrate VMware virtual machines to Proxmox VE: ESXi import and virt-v2v
Two migration paths for a Proxmox target. The built-in ESXi import wizard connects directly to an ESXi host and converts disks during the import, with no intermediate staging. The virt-v2v / qemu-img path keeps every intermediate artefact under control and scripts cleanly for bulk waves. Commands are illustrative: each engagement adapts them to your Proxmox version, storage backend (local-lvm, ZFS, Ceph RBD) and security constraints.
1. Qualify the VM before converting it
Same discipline as any hypervisor migration: for every VM, record the guest OS and version, firmware type (BIOS or UEFI), number and size of disks, snapshot chain, network interfaces with their MAC and fixed IPs, and any licence bound to hardware identifiers. Proxmox adds one Proxmox-specific question: which storage backend will host the disks (local-lvm, ZFS, or Ceph RBD if the cluster is hyperconverged), since that choice constrains which import path is fastest.
# Inventory with govc (read-only against vCenter or a standalone ESXi host)
export GOVC_URL='https://<VCENTER_OR_ESXI_HOST>' GOVC_USERNAME='<USER>' GOVC_INSECURE=1
govc vm.info -json <VM_NAME> | jq '.virtualMachines[0] | {guest: .config.guestFullName, firmware: .config.firmware, cpu: .config.hardware.numCPU, memMB: .config.hardware.memoryMB}'
govc device.info -vm <VM_NAME> disk-* ethernet-*
govc snapshot.tree -vm <VM_NAME> # must be empty (or consolidated) before export
# On the Proxmox side: confirm target storage type and free space
pvesm statusIf the target is hyperconverged Ceph
A converged Proxmox + Ceph cluster runs OSDs and VMs on the same hosts with no built-in CPU/bandwidth reservation between the two. Schedule migration waves outside Ceph-heavy windows (scrubbing, rebalance after a host change) and watch OSD latency during the first waves rather than assuming headroom.
2. Path A: native ESXi import wizard
Recent Proxmox VE releases can register an ESXi host as a storage source and import its guests directly: disks are streamed and converted on the fly into the chosen target storage, with no manual OVA export or staging area. It is the fastest path for a handful of VMs or a first pilot, and it is driven from the web UI.
2.1 Register the ESXi host as an import source
# Datacenter → Storage → Add → ESXi, or from the CLI on a cluster node
pvesm add esxi esxi-src \
--server <ESXI_HOST> --username <ESXI_USER> --password <ESXI_PASSWORD> \
--skip-cert-verification 1
# List the guests Proxmox discovered on that ESXi host
pvesm list esxi-src2.2 Import through the wizard
Open the target node, select the esxi-src storage, then Import for the VM to migrate. The wizard lets you pick the target storage (local-lvm, ZFS, Ceph RBD), the disk format, the bridge for each network interface and the VirtIO SCSI controller, then creates the VM and converts the disks in one operation. For scripted bulk imports across many VMs, drive the same operation through the Proxmox API rather than clicking through each guest individually.
The wizard converts disks but does not rewrite the guest OS: Windows guests still need VirtIO storage and network drivers injected before or at first boot on VirtIO hardware (see the pitfalls below), and the source VM must be reachable and powered off for a consistent disk state.
3. Path B: virt-v2v / qemu-img and qm importdisk
virt-v2v has no dedicated Proxmox output plugin, so the path runs in two steps: convert the guest to a local raw or qcow2 image (from vCenter directly, or from an OVA export), then attach that image to a Proxmox VM shell with qm importdisk. This path keeps every intermediate artefact under control, works without network access from Proxmox to vCenter, and scripts cleanly for scripted bulk migrations.
3.1 Convert the guest with virt-v2v
# Install virt-v2v and guestfs tools on a Linux conversion host (Debian/Ubuntu)
apt-get install virt-v2v libguestfs-tools -y
# Windows guests: virt-v2v needs the virtio-win drivers (ISO from the Fedora virtio-win project)
export VIRTIO_WIN=/opt/virtio-win.iso
# Power off the source VM first, then convert to a local raw image (-o local)
export LIBGUESTFS_BACKEND=direct
mkdir -p /tmp/converted
virt-v2v -ic 'vpx://<VCENTER_USER>@<VCENTER_HOST>/<DATACENTER>/<ESXI_HOST>' \
-ip /root/vcenter-password <VM_NAME> \
-o local -os /tmp/converted/ -of raw
# Output is named <VM_NAME>-sda, -sdb, and so on in /tmp/converted/3.2 Create the VM shell and import the disks
# Create an empty VM with the target hardware profile
qm create 9001 --name <VM_NAME>_migrated --memory 8192 --cores 4 --sockets 1 \
--net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single --ostype l26
# Import each converted disk into the chosen storage (returns the new volume as unused disk)
qm importdisk 9001 /tmp/converted/<VM_NAME>-sda local-lvm --format qcow2
qm importdisk 9001 /tmp/converted/<VM_NAME>-sdb local-lvm --format qcow2
# Attach the imported disk and set the boot order
qm set 9001 --scsi0 local-lvm:vm-9001-disk-0
qm set 9001 --scsi1 local-lvm:vm-9001-disk-1
qm set 9001 --boot order=scsi0
qm set 9001 --agent enabled=13.3 Large disks: stream straight into Ceph RBD
# Skip local staging for multi-terabyte disks: convert directly into the Ceph pool
qemu-img convert -p -f raw -O raw /tmp/converted/<VM_NAME>-sda rbd:<CEPH_POOL>/vm-9001-disk-0
# Then attach the existing RBD image to the VM
qm set 9001 --scsi0 <CEPH_STORAGE_ID>:vm-9001-disk-04. Which path for which fleet
Prefer the ESXi import wizard when
Proxmox has direct network access to the ESXi host, the fleet is small enough to migrate guest by guest or through a scripted API loop, and the team wants the fewest manual steps per VM.
Prefer virt-v2v / qemu-img when
Proxmox has no direct network path to vCenter, every intermediate artefact must be kept and checked, or bulk migrations are scripted into a repeatable migration factory across dozens of VMs.
5. Pitfalls we neutralize before they occur
- ■Windows VirtIO drivers: without VirtIO storage drivers injected before first boot, Windows guests crash or blue-screen on startup. virt-v2v injects them automatically; through the ESXi import wizard, inject the virtio-win drivers before switching the boot disk controller to VirtIO.
- ■QEMU Guest Agent is not installed for you: ticking the QEMU Agent box in the VM's Options tab only tells Proxmox to expect it. You still have to install qemu-guest-agent inside the guest yourself and start the service, or Proxmox keeps reporting no IP address and cannot request a clean guest shutdown.
- ■UEFI versus BIOS: a UEFI guest booted with the default SeaBIOS fails. Set bios: ovmf and add an efidisk0 on the target storage before first boot; inventory the firmware type per VM beforehand.
- ■SCSI controller and network model: a VM created with the default LSI controller and e1000 NIC boots but loses most of the performance benefit. Use virtio-scsi-single for the controller and virtio for the network interface once the guest drivers are in place.
- ■IP and MAC preservation: application licences, firewall rules and hardcoded configurations depend on addresses. Set net0's macaddr explicitly and keep the guest's static IP configuration when continuity requires it.
- ■Snapshots and CBT chains: unconsolidated snapshot chains corrupt or bloat both the ESXi import and an OVA export. Consolidate snapshots and pause backup integrations before any disk leaves vSphere.
6. Acceptance and rollback
The source VM stays powered off but intact on vSphere until acceptance is signed. Rollback is a documented, tested runbook: power the source back on, reconnect flows, log the deviation and feed it back into the eligibility matrix. Only then is the vSphere VM deleted and its storage reclaimed.
# Post-migration checks on the Proxmox side
qm status 9001
qm config 9001
qm terminal 9001 # serial console; or use the noVNC console from the web UI
# Rollback (vSphere side): the source VM was never deleted
govc vm.power -on <VM_NAME>