Migration from VMware vSphere: the complete playbook

Migrating from VMware vSphere to Proxmox is a real production project — not a weekend hack. This lesson walks through the complete playbook, from planning to cutover.

Migration phases

A typical migration runs in five phases over 3–12 months:

1. Pilot (week 1–2): Migrate 2–3 non-critical VMs, validate the toolchain, document deviations.
2. Lab/dev (week 3–6): Migrate dev and lab environments. Low risk, high learning value.
3. Pre-prod (week 7–10): Migrate non-critical production VMs. Performance test, validate backups, validate HA.
4. Production (week 11–18): Migrate critical production VMs in waves of 5–10 per wave.
5. Decommission (week 19–24): After 30 days of stable production, shut down VMware.

Discovery: what are we migrating?

Before any technical work, you need a complete inventory:

VM Inventory (extract from vSphere)
- Total VMs: 247
- By OS: Windows 124, RHEL 67, Ubuntu 38, others 18
- By criticality: Tier 1 (production) 89, Tier 2 (internal) 102,
  Tier 3 (dev/lab) 56
- Total vCPUs allocated: 1,840
- Total RAM allocated: 4.2 TB
- Total disk allocated: 96 TB
- Largest single VM: 8 TB (database)
- VMs with > 1 TB RAM: 12 (databases, SAP)
- VMs with USB passthrough: 7 (license dongles)
- VMs with raw device mapping (RDM): 4 (databases requiring direct
  LUN access)
- VMs with vGPU: 3 (VDI)
- VMs in a cluster: 198 (most)
- VMs standalone: 49 (test/lab)

This inventory drives the migration plan. VMs with USB passthrough, RDM, or vGPU need special handling.

virt-v2v: the conversion tool

virt-v2v converts VMs from foreign hypervisors (VMware, Hyper-V, Xen) to KVM-compatible formats. PVE 9.x supports it directly.

Installation

# On a PVE node (or a dedicated conversion host)
apt install -y virt-v2v libguestfs-tools

# Verify
virt-v2v --version
# virt-v2v 2.4.x

Basic conversion

# Convert a VMware VM via vCenter
virt-v2v -i vmx ssh://root@vcenter.example.com/vmfs/volumes/datastore1/vmware/web-01/web-01.vmx \
  -o local -os /var/tmp/v2v-output/

# The output is a converted disk + OpenStack-style metadata
ls /var/tmp/v2v-output/
# web-01-disk-sda.qcow2
# web-01.xml   (libvirt XML)

# Or convert directly to PVE
virt-v2v -i vmx ssh://root@vcenter.example.com/vmfs/volumes/datastore1/vmware/web-01/web-01.vmx \
  -o pve -os pve-01:local-zfs --bridge vmbr0

Conversion options

Driver handling

virt-v2v handles the critical Windows driver replacement:

• Removes VMware Tools
• Installs virtio drivers (balloon, blk, scsi, net)
• Updates the Windows registry to load virtio at boot

For Windows VMs that don’t have virtio drivers, the conversion installs them. After conversion, the first boot may take longer than usual while Windows installs the new drivers.

Validation before cutover

For every converted VM, validate:

# 1. Boot the converted VM in test mode
qm start <vmid> --debug
# Check: did Windows/Linux boot?
# Check: do drivers load?

# 2. Verify network
# - Does the VM get a DHCP address?
# - Can it ping the gateway?
# - Can it reach internal services?

# 3. Verify storage performance
# Run your standard storage benchmark inside the VM
# Compare to VMware baseline (deviations > 20% are worth investigating)

# 4. Verify application functionality
# For a database: connect, run a few queries
# For a web server: load a few pages
# For a domain controller: auth a test user

# 5. Verify backup
# Take a PBS backup, restore to test, boot, verify

A VM that passes all five checks is ready for cutover. Document the results — they’re the evidence that the migration is safe.

Cutover patterns

Big-bang cutover

All VMs migrated at once during a maintenance window. Fastest but highest risk. Only for small clusters (<20 VMs) with tolerant workloads.

Wave cutover

Migrate in waves of 5–10 VMs per week. Each wave has its own planning, test, and cutover cycle. This is the standard pattern for medium clusters.

Continuous cutover

Migrate one VM at a time as part of regular maintenance. Slowest but lowest risk. For clusters where every minute of downtime matters.

Application-by-application

Migrate by application (database, then app, then web) rather than by VM. This catches application-level issues that per-VM testing misses.

Validation after cutover

After cutover, monitor for 30 days:

• Performance vs baseline (CPU, memory, I/O)
• Application errors (any new errors after migration?)
• Network latency (sometimes virtio introduces changes)
• Backup success (does PBS backup the new VM correctly?)
• HA behaviour (if HA-managed, does failover work?)

Document the deltas. Some are real (different virtio drivers have slightly different performance); some are noise.

Handling problematic VMs

Some VMs don’t migrate cleanly. Common cases:

VMs with USB passthrough

USB passthrough requires the device to be present on the PVE host. If the USB dongle is in the VMware host, you must physically move it.

For VMs that don’t need USB after migration (e.g., software-licensed software you can relicense), remove the USB dependency first.

VMs with RDM (Raw Device Mapping)

RDM gives a VM direct access to a LUN. On PVE, you have two options:

• iSCSI LUN passthrough: present the same LUN via iSCSI to the PVE host, pass it through to the VM as a raw device
• Migrate to LVM/iSCSI-backed disk: convert the RDM to a regular VM disk during migration

Option 2 is simpler but requires a copy operation during the migration.

VMs with vGPU

NVIDIA vGPU requires specific PVE host configuration (kernel modules, licensing). For most workloads, software GPU rendering is acceptable. For CUDA workloads, the choice is vGPU or pass-through PCIe GPUs.

Production considerations

• Concurrent conversions. virt-v2v uses local CPU. Run 2–3 conversions in parallel per host; more saturates CPU.
• Storage bandwidth. Conversion reads from source (vCenter datastore) and writes to target (PVE). Both must have headroom.
• DNS and DHCP reservations. Converted VMs often have the same MAC and IP. Update DHCP reservations to avoid conflicts.
• Time zone. VMs migrated across time zones may have UTC drift. Verify NTP after cutover.

Common mistakes

• Skipping the pilot. Without testing the toolchain on 2–3 VMs, you discover issues at scale.
• No rollback plan. If a converted VM doesn’t boot, you need to be able to power it back on VMware within hours.
• Cutover without performance test. A converted VM may be 30% slower on PVE than VMware (different I/O scheduler, different drivers). Test before cutover.
• Forgetting licences. Windows licences, Oracle licences, and others often key on the hypervisor or MAC address. Re-key after migration.

Key takeaways

• Migration is a project, not a hack. Use a phased approach.
• virt-v2v handles most conversions, but validate every VM.
• Test thoroughly before cutover; have a VMware rollback.
• Monitor for 30 days after cutover to catch delayed issues.

Knowledge check