Migration from VMware, Hyper-V, and physical systems

Why this matters in production

Migrations are expensive projects. Doing them wrong takes months and produces fragile environments. Doing them right takes careful planning and methodical execution.

Mental model

A migration has three phases:

flowchart LR
  A[Assessment] --> B[Conversion]
  B --> C[Validation]
  C --> D[Cutover]
  D --> E[Decommission]

Assessment

For each workload, document:

• Source (VMware vSphere / Hyper-V / physical).
• Disk size, CPU, RAM.
• Network dependencies (VLANs, IP, firewall rules).
• Storage dependencies (which datastore, which shares).
• Application owner.
• Recovery procedure.
• Acceptance criteria (how will you know it works?).

This becomes the migration manifest.

Conversion

Proxmox supports several import paths:

VMware ESXi/vSphere

GUI: Datacenter → Storage → Add → ESXi. Provide ESXi host/IP and credentials.

Or CLI via qm importdisk:

qm importdisk 100 vm-100-disk-0.vmdk local-zfs --format qcow2

Hyper-V (VHDX)

Convert VHDX to a Proxmox-compatible format using qemu-img:

qemu-img convert -f vhdx -O qcow2 source.vhdx output.qcow2

Then qm importdisk.

OVF/OVA

tar xvf workload.ova -C extracted
qemu-img convert -f vmdk -O qcow2 extracted/disk1.vmdk output.qcow2
qm importdisk <vmid> output.qcow2 <storage>

Physical

Use Clonezilla or dd to image the disk; convert with qemu-img; import.

Windows driver preparation

Windows guests need VirtIO drivers for:

• Network (virtio-net).
• Block (virtio-scsi).
• Balloon (memory dynamic allocation).
• Guest agent (faster snapshots, clean shutdown).

For Windows guests, install VirtIO drivers BEFORE migration:

• ISO download from fedorapeople.org.
• Mount ISO in the source VM.
• Install drivers via the bundled installer.
• Reboot and verify.

Validation

For each migrated VM:

1. Start the VM in Proxmox.
2. Verify it boots (UEFI/BIOS matches source).
3. Verify network (IP assigned, can ping gateway).
4. Verify storage (filesystem mounts, applications start).
5. Verify guest agent (fstrim/snapshots work).
6. Verify backups (PBS can back up the migrated VM).

Cutover

Cutover is the moment of truth:

1. Schedule a maintenance window.
2. Shut down the source VM.
3. Take a final snapshot or backup of the source.
4. Re-import or update the migrated VM with the latest state.
5. Start the migrated VM in Proxmox.
6. Update DNS to point to the new IP (or reconfigure IP).
7. Verify from external systems.

Production considerations

Common mistakes

• Importing Windows without VirtIO drivers.
• Forgetting to install the guest agent.
• Not validating backup after migration.

Key takeaways

• Assess, convert, validate, cut over, decommission.
• Windows needs VirtIO drivers before migration.
• Pilot first.

Knowledge check