VMware to Proxmox Migration: Complete 2025 Guide

November 2023 changed everything. Broadcom acquired VMware and immediately restructured licensing. Free ESXi disappeared. vSphere pricing skyrocketed. Homelabbers and small businesses faced an impossible choice: pay enterprise prices or migrate.

Thousands chose migration. This guide ensures yours succeeds.

Proxmox VE offers everything VMware provided—and more—without licensing fees. But migration isn’t simple. VMs won’t “just work” on a new hypervisor. Storage formats differ. Networks require reconfiguration. Performance needs optimization. This guide addresses every challenge.

Why This Migration Matters

Your VMware environment represents years of work:

• Production VMs running critical services
• Complex networking configurations
• Snapshot chains and backup strategies
• Performance tuning and resource allocation
• License investments now worthless

This guide preserves your investment while escaping vendor lock-in.

What You’ll Accomplish

By the end of this guide, you will:

• Understand Broadcom’s licensing changes and impacts
• Plan comprehensive migration strategy
• Export VMs from ESXi/vCenter
• Convert VMDK disks to Proxmox-compatible formats
• Import VMs to Proxmox with minimal downtime
• Reconfigure networking for new environment
• Migrate storage to Proxmox backends
• Optimize performance post-migration
• Implement equivalent features (HA, DRS, vMotion)
• Validate successful migration

Prerequisites

Required Knowledge:

• VMware ESXi/vCenter administration
• Basic Linux command line
• Networking fundamentals
• Storage concepts (datastores, LUNs)

Required Access:

• Administrative access to ESXi/vCenter
• Root access to Proxmox host(s)
• Network connectivity between environments
• Sufficient storage on Proxmox side

Before You Begin:

• Backup all VMs (multiple copies)
• Document configurations (networks, storage, settings)
• Test migration (non-production VMs first)
• Schedule maintenance window (for production)
• Verify hardware compatibility (CPU, network, storage)

---

Section 1: Understanding the Broadcom Changes

What Changed in 2024-2025

Pre-Broadcom VMware (Before November 2023):

Free Tier:
- ESXi Free: Unlimited for personal/homelab use
- vCenter limited but functional
- Community support available
- Feature restrictions but core functionality free

Paid Tiers:
- vSphere Essentials: ~$500-1000/year (3 hosts)
- vSphere Standard: ~$1000-2000/year per socket
- vSphere Enterprise Plus: ~$5000+/year per socket
- Perpetual licenses available
- SMB-friendly pricing

Post-Broadcom VMware (2024-2025):

Eliminated:
✗ Free ESXi (completely removed)
✗ Perpetual licenses (subscription-only)
✗ Lower-tier products (Essentials, etc.)
✗ SMB-friendly pricing

New Structure:
- VMware Cloud Foundation (VCF): Starting $3000+/year per CPU
- Minimum purchase: Often 50+ licenses
- Bundled products (forced purchases)
- 3-5x price increases for existing customers
- Complex licensing audits

Impact on Homelabs:
- Free ESXi: Discontinued
- Existing free installations: Still work (for now)
- No updates without license
- Community support ended
- Uncertain long-term viability

Result: Exodus from VMware to open-source alternatives.

Why Proxmox is the Answer

Proxmox VE Advantages:

Cost:
✓ Completely free and open-source
✓ All features available (no tiers)
✓ Optional commercial support (not required)
✓ No license audits or compliance issues

Features:
✓ KVM hypervisor (proven, performant)
✓ LXC containers (VMware lacks)
✓ Built-in high availability
✓ Live migration (vMotion equivalent)
✓ Web UI (vCenter equivalent)
✓ Clustering (DRS-like features)
✓ Backup and restore (integrated)
✓ API for automation
✓ Active development community

Performance:
✓ Near-native (KVM mature)
✓ Virtio drivers (paravirtualization)
✓ GPU passthrough
✓ CPU pinning
✓ NUMA awareness

Compatibility:
✓ Import VMware VMs
✓ Standard formats (qcow2, raw)
✓ Industry-standard tools
✓ Runs on commodity hardware

What You Lose (and Alternatives):

VMware Feature → Proxmox Alternative

vCenter → Proxmox Web UI + Clustering
vMotion → Proxmox Live Migration
DRS (auto-balancing) → Manual or scripted
vSAN → Ceph (included in Proxmox)
NSX → Linux networking + SDN
vRealize → Prometheus + Grafana
VSAN Encryption → LUKS encryption
vSphere Replication → Proxmox Replication

Trade-offs:

You Lose:
- Polished commercial UI (Proxmox UI is functional but less refined)
- VMware ecosystem integration
- Enterprise support contracts (unless paid)
- Some advanced automation (DRS)

You Gain:
- Complete freedom and control
- No licensing costs forever
- Open-source transparency
- Active community
- Modern containerization (LXC)
- Flexibility to customize

---

Section 2: Planning Your Migration

Migration Strategies

Strategy 1: Parallel Migration (Recommended)

Timeline: 2-4 weeks
Downtime: Minimal (per-VM)

Process:
1. Install Proxmox on new hardware
2. Migrate VMs one by one
3. Test each VM on Proxmox
4. Redirect traffic/DNS
5. Decommission VMware when complete

Advantages:
✓ Minimal risk
✓ Easy rollback
✓ Validate each VM
✓ Learn Proxmox gradually

Disadvantages:
✗ Requires additional hardware (temporary)
✗ Longer overall timeline
✗ Duplicate resources during migration

Strategy 2: In-Place Migration

Timeline: 1-2 days (maintenance window)
Downtime: Hours to days (all VMs)

Process:
1. Backup all VMs
2. Export all VMs from ESXi
3. Wipe ESXi hardware
4. Install Proxmox on same hardware
5. Import all VMs
6. Restore services

Advantages:
✓ No additional hardware required
✓ Faster completion
✓ Clean slate approach

Disadvantages:
✗ Extended downtime
✗ No easy rollback
✗ All-or-nothing risk
✗ High stress migration

Strategy 3: Hybrid Migration

Timeline: 1-2 weeks
Downtime: Moderate (per-VM)

Process:
1. Install Proxmox on one ESXi host
2. Migrate VMs to remaining ESXi hosts
3. Convert freed host to Proxmox
4. Migrate VMs to Proxmox
5. Repeat until complete

Advantages:
✓ Uses existing hardware
✓ Gradual migration
✓ Moderate risk

Disadvantages:
✗ Requires free capacity
✗ Complex juggling of VMs
✗ Partial Proxmox cluster during migration

Recommended for Most:

Homelab (10-50 VMs):
→ Parallel migration with used server or temporary hardware

Small Business (Critical Services):
→ Parallel migration (no downtime acceptable)

Testing Environment:
→ In-place migration (acceptable downtime)

Pre-Migration Checklist

Documentation Phase:

# Create spreadsheet documenting:

For Each VM:
- VM Name
- vCPUs
- RAM
- Disk size and type (thin/thick)
- Network(s) attached
- VLAN tags
- IP address (static/DHCP)
- Operating system and version
- VMware Tools version
- Snapshots (export or delete)
- Storage location (datastore)
- Boot order
- Virtual hardware version
- Special devices (USB, PCI passthrough, etc.)

For Infrastructure:
- Network topology
- VLAN configuration
- Storage (NFS, iSCSI, local)
- Resource pools
- DRS rules
- HA configuration
- Backup schedules

Capacity Planning:

Calculate Proxmox Storage Needs:

VMware Thin Provisioned Disk:
- Allocated: 500 GB
- Used: 150 GB
- Proxmox needs: 150 GB (minimum) + 20% buffer = 180 GB

VMware Thick Provisioned Disk:
- Allocated: 500 GB
- Proxmox needs: 500 GB (or convert to thin)

Total Proxmox Storage:
- Sum all VM disks (used space)
- Add 20-30% overhead
- Add space for snapshots
- Add space for ISO storage

Example:
- 20 VMs × 50 GB average = 1000 GB
- 30% overhead = 300 GB
- Snapshots = 200 GB
- Total needed: 1500 GB

Network Planning:

Map VMware Networks to Proxmox:

VMware Port Group → Proxmox Bridge
- VM Network (no VLAN) → vmbr0
- Production_VLAN10 → vmbr0.10
- DMZ_VLAN20 → vmbr0.20
- Management_VLAN30 → vmbr0.30

Ensure Proxmox bridges configured before import

---

Section 3: Exporting VMs from VMware

Method 1: OVF Export (Best for Small Deployments)

Via vSphere Client:

1. Connect to vCenter or ESXi
2. Navigate to VMs and Templates
3. Right-click VM → Export → Export OVF Template

Configuration:
- Name: web-server-01
- Directory: /exports/web-server-01/
- Format: OVF (folder) recommended
  - Creates .ovf, .vmdk, .mf files
- Alternative: OVA (single file, slower)

4. Click OK

Export Progress:
- Small VM (20 GB): 10-20 minutes
- Large VM (500 GB): 2-4 hours
- Network speed dependent

Output:
/exports/web-server-01/
├── web-server-01.ovf (VM definition)
├── web-server-01.vmdk (virtual disk)
└── web-server-01.mf (manifest/checksum)

Via ovftool (Command Line):

# Install ovftool (from VMware website)
# Available for Windows, Linux, macOS

# Export VM to OVF
ovftool   vi://[email protected]/web-server-01   /exports/web-server-01/web-server-01.ovf

# Export with options
ovftool   --noSSLVerify   --diskMode=thin   --name=web-server-01   vi://[email protected]@vcenter.homelab.local/Datacenter/vm/web-server-01   /exports/web-server-01.ovf

# Export to OVA (single file)
ovftool   vi://[email protected]/web-server-01   /exports/web-server-01.ova

Method 2: VMDK Copy (Fast, Requires SSH)

Enable SSH on ESXi:

1. vSphere Client → Host → Configure
2. Security Profile → Services → SSH
3. Start SSH service
4. Firewall: Allow SSH

Locate and Copy VMDKs:

# SSH to ESXi host
ssh [email protected]

# Find VM files
find /vmfs/volumes/ -name "web-server-01*"

# Output:
# /vmfs/volumes/datastore1/web-server-01/web-server-01.vmdk
# /vmfs/volumes/datastore1/web-server-01/web-server-01-flat.vmdk
# /vmfs/volumes/datastore1/web-server-01/web-server-01.vmx

# From another system, copy VMDKs
scp [email protected]:/vmfs/volumes/datastore1/web-server-01/*.vmdk /exports/web-server-01/

# Copy both files:
# - web-server-01.vmdk (descriptor, small)
# - web-server-01-flat.vmdk (actual data, large)

Method 3: Cloning Datastore (Bulk Export)

For Many VMs:

# Mount NFS export on ESXi
esxcli storage nfs add   --host=192.168.1.50   --share=/mnt/pool/esxi-export   --volume-name=export-storage

# Use vCenter/ESXi to Storage vMotion VMs to NFS
# Then access files directly from NFS server

# Alternatively, rsync entire datastore
rsync -avP /vmfs/volumes/datastore1/ /mnt/nfs-export/datastore1-backup/

---

Section 4: Converting VMDKs to Proxmox Format

Understanding Disk Formats

VMware Formats:

VMDK (Virtual Machine Disk):
- Descriptor file: .vmdk (small, metadata)
- Data file: -flat.vmdk (large, actual data)
- Formats: monolithicSparse, streamOptimized, etc.

Proxmox Formats:

qcow2 (QEMU Copy-On-Write):
- Single file
- Supports snapshots
- Thin provisioning
- Compression support
- Recommended for most use cases

Raw:
- No metadata, just data
- Slightly faster
- No snapshot support
- Thick provisioning only
- Use for maximum performance

VMA (Proxmox backup format):
- Proprietary to Proxmox
- Backup/restore only

Conversion Process

Install qemu-img:

# On Ubuntu/Debian workstation
sudo apt install qemu-utils -y

# On macOS
brew install qemu

# On Windows (use WSL or download QEMU)
# Or perform conversion on Proxmox host directly

Convert VMDK to qcow2:

# Basic conversion
qemu-img convert   -f vmdk   -O qcow2   web-server-01-flat.vmdk   web-server-01.qcow2

# Conversion with compression (smaller file, slower)
qemu-img convert   -f vmdk   -O qcow2   -c   web-server-01-flat.vmdk   web-server-01.qcow2

# Conversion with progress bar (using pv)
pv web-server-01-flat.vmdk | qemu-img convert -f vmdk -O qcow2 - web-server-01.qcow2

# Large disk conversion times:
# 50 GB: 5-10 minutes
# 500 GB: 30-60 minutes
# 2 TB: 2-4 hours

Convert VMDK to Raw:

# For maximum performance VMs
qemu-img convert   -f vmdk   -O raw   web-server-01-flat.vmdk   web-server-01.raw

Verify Conversion:

# Check converted disk info
qemu-img info web-server-01.qcow2

# Output:
# image: web-server-01.qcow2
# file format: qcow2
# virtual size: 50 GiB (53687091200 bytes)
# disk size: 15.2 GiB
# cluster_size: 65536

Handling Multiple Disks

VM with Multiple VMDKs:

# Example: VM with 3 disks
# web-server-01-disk1.vmdk (OS)
# web-server-01-disk2.vmdk (Data)
# web-server-01-disk3.vmdk (Logs)

# Convert each disk
qemu-img convert -f vmdk -O qcow2 web-server-01-disk1-flat.vmdk web-server-01-disk1.qcow2
qemu-img convert -f vmdk -O qcow2 web-server-01-disk2-flat.vmdk web-server-01-disk2.qcow2
qemu-img convert -f vmdk -O qcow2 web-server-01-disk3-flat.vmdk web-server-01-disk3.qcow2

# Import each to Proxmox (covered next section)

---

Section 5: Importing VMs to Proxmox

Method 1: Manual Import via Web UI

Step 1: Transfer Converted Disks to Proxmox:

# Copy qcow2 to Proxmox host
scp web-server-01.qcow2 [email protected]:/tmp/

# Or mount shared storage (NFS) accessible from both

Step 2: Create VM in Proxmox:

Web UI → Create VM:

General:
- Node: pve1
- VM ID: 100
- Name: web-server-01

OS:
- Do not use any media
- Guest OS: Linux (or Windows)

System:
- BIOS: SeaBIOS (or UEFI if ESXi was UEFI)
- Machine: q35
- SCSI Controller: VirtIO SCSI

Disks:
- Delete default disk (we'll import existing)

CPU:
- Sockets: 1
- Cores: 2 (match ESXi)
- Type: host

Memory:
- 4096 MB (match ESXi)

Network:
- Bridge: vmbr0
- Model: VirtIO (best performance)
- VLAN: (if needed)

Confirm: Create VM (DO NOT START YET)

Step 3: Import Disk:

# SSH to Proxmox host
ssh [email protected]

# Import disk to VM
qm importdisk 100 /tmp/web-server-01.qcow2 local-lvm

# Output:
# Successfully imported disk as 'unused0:local-lvm:vm-100-disk-0'

# Attach disk to VM
qm set 100 --scsi0 local-lvm:vm-100-disk-0

# Set boot order
qm set 100 --boot order=scsi0

# Start VM
qm start 100

Method 2: Automated Import Script

Bulk Import Script:

#!/bin/bash
# vmware-to-proxmox-import.sh

# Configuration
VMDK_DIR="/mnt/nfs-export/vmdks"
TEMP_DIR="/tmp/conversions"
STORAGE="local-lvm"
BRIDGE="vmbr0"

# VM definitions (Name:VMID:Cores:RAM:Disk)
VMS=(
  "web-server-01:100:2:4096:web-server-01-flat.vmdk"
  "db-server-01:101:4:8192:db-server-01-flat.vmdk"
  "app-server-01:102:2:4096:app-server-01-flat.vmdk"
)

mkdir -p $TEMP_DIR

for vm_def in "${VMS[@]}"; do
  IFS=':' read -r NAME VMID CORES RAM VMDK <<< "$vm_def"

  echo "Processing $NAME (VMID: $VMID)..."

  # Convert VMDK to qcow2
  echo "  Converting disk..."
  qemu-img convert -f vmdk -O qcow2     "$VMDK_DIR/$VMDK"     "$TEMP_DIR/$NAME.qcow2"

  # Create VM
  echo "  Creating VM..."
  qm create $VMID     --name $NAME     --memory $RAM     --cores $CORES     --net0 virtio,bridge=$BRIDGE     --ostype l26

  # Import disk
  echo "  Importing disk..."
  qm importdisk $VMID "$TEMP_DIR/$NAME.qcow2" $STORAGE

  # Attach disk
  echo "  Attaching disk..."
  qm set $VMID --scsi0 ${STORAGE}:vm-${VMID}-disk-0

  # Set boot order
  qm set $VMID --boot order=scsi0

  # Cleanup
  rm "$TEMP_DIR/$NAME.qcow2"

  echo "  $NAME imported successfully!"
done

echo "All VMs imported!"

Run Script:

chmod +x vmware-to-proxmox-import.sh
./vmware-to-proxmox-import.sh

---

Section 6: Post-Migration Configuration

Installing QEMU Guest Agent

Why Guest Agent?

Replaces VMware Tools:

• Proper shutdown/reboot
• IP address reporting
• Time synchronization
• File system freeze for backups

Linux VMs:

# SSH to migrated Linux VM
ssh user@vm-ip

# Ubuntu/Debian
sudo apt update
sudo apt install qemu-guest-agent -y

# RHEL/CentOS/Rocky
sudo yum install qemu-guest-agent -y

# Start service
sudo systemctl enable qemu-guest-agent
sudo systemctl start qemu-guest-agent

# On Proxmox host, enable agent
qm set 100 --agent enabled=1

# Restart VM
qm reboot 100

# Verify (Proxmox web UI shows IP in VM list)

Windows VMs:

1. Download VirtIO drivers ISO:
   https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/

2. In Proxmox: VM → Hardware → Add → CD/DVD Drive
   Select: virtio-win.iso

3. Boot Windows VM

4. In VM: Open CD drive
   Run: virtio-win-guest-tools.exe

5. Install drivers and guest agent

6. Reboot VM

7. In Proxmox: Enable agent
   qm set 100 --agent enabled=1

Network Reconfiguration

Static IP VMs:

# If VM boots but no network (different NIC name)

# Ubuntu/Debian (netplan)
sudo nano /etc/netplan/00-installer-config.yaml

# Change interface name from ens192 (VMware) to ens18 (Proxmox)
network:
  version: 2
  ethernets:
    ens18:  # Changed from ens192
      addresses:
        - 192.168.1.100/24
      gateway4: 192.168.1.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 1.1.1.1

# Apply
sudo netplan apply

# RHEL/CentOS (ifcfg)
sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

# Update interface name if needed
# Restart network
sudo systemctl restart NetworkManager

DHCP VMs:

Usually work without changes, but verify interface name.

Removing VMware-Specific Software

Linux VMs:

# Remove VMware Tools (open-vm-tools)
sudo apt remove open-vm-tools open-vm-tools-desktop -y  # Ubuntu/Debian
sudo yum remove open-vm-tools -y  # RHEL/CentOS

# Clean up residual files
sudo rm -rf /etc/vmware-tools
sudo rm -rf /usr/lib/vmware-tools

Windows VMs:

1. Uninstall VMware Tools:
   Control Panel → Programs → Uninstall
   Select: VMware Tools
   Uninstall

2. Reboot

3. Install VirtIO drivers (if not already installed)

Storage Optimization

Convert to Thin Provisioning (if needed):

# If disk was thick on VMware, consider converting

# On Proxmox host
qm set 100 --scsi0 local-lvm:vm-100-disk-0,discard=on

# Enable TRIM in guest OS (Linux)
# SSH to VM
sudo systemctl enable fstrim.timer
sudo systemctl start fstrim.timer

Resize Disk (if needed):

# Increase disk size
qm resize 100 scsi0 +50G

# In guest OS, expand filesystem
# Linux (ext4)
sudo resize2fs /dev/sda1

# Linux (XFS)
sudo xfs_growfs /

# Windows: Disk Management → Extend Volume

---

Section 7: Advanced Migration Topics

Migrating HA Configuration

VMware HA → Proxmox HA:

# On Proxmox (in cluster)

# Enable HA for VM
ha-manager add vm:100

# Set restart policy
ha-manager set vm:100 --state started --max_restart 3

# Priority groups
ha-manager groupadd critical_vms -nodes pve1:2,pve2:1,pve3:0
ha-manager set vm:100 --group critical_vms

Migrating DRS-like Features

VMware DRS → Proxmox Balancing:

No automatic DRS in Proxmox, but alternatives:

# Manual balance script
#!/bin/bash
# balance-vms.sh

# Get node CPU usage
pve1_cpu=$(pvesh get /nodes/pve1/status | grep cpu | awk '{print $3}')
pve2_cpu=$(pvesh get /nodes/pve2/status | grep cpu | awk '{print $3}')

# If pve1 > 80% and pve2 < 50%, migrate VMs
if (( $(echo "$pve1_cpu > 0.8" | bc -l) )) && (( $(echo "$pve2_cpu < 0.5" | bc -l) )); then
  qm migrate 100 pve2 --online
fi

# Run as cron job for basic balancing

Bulk Migration Automation

Terraform for Infrastructure as Code:

# main.tf

terraform {
  required_providers {
    proxmox = {
      source = "telmate/proxmox"
      version = "2.9.14"
    }
  }
}

provider "proxmox" {
  pm_api_url = "https://proxmox.homelab.local:8006/api2/json"
  pm_api_token_id = "terraform@pve!mytoken"
  pm_api_token_secret = "your-secret"
}

# Import existing migrated VMs
resource "proxmox_vm_qemu" "web_servers" {
  for_each = toset(["web-01", "web-02", "web-03"])

  name = each.key
  target_node = "pve1"

  cores = 2
  memory = 4096

  network {
    model = "virtio"
    bridge = "vmbr0"
  }

  lifecycle {
    ignore_changes = [disk, network]
  }
}

---

Section 8: Validation and Testing

Post-Migration Checklist

For Each VM:

✓ VM boots successfully
✓ Network connectivity (ping gateway)
✓ Services started automatically
✓ Guest agent installed and working
✓ IP address visible in Proxmox UI
✓ Storage I/O performance acceptable
✓ Backups configured
✓ Resource limits appropriate
✓ No VMware tools remnants
✓ Firewall rules applied
✓ Monitoring configured

Performance Comparison

Benchmark Tools:

# CPU performance
sysbench cpu --cpu-max-prime=20000 run

# Disk I/O
fio --name=randwrite --ioengine=libaio --iodepth=16 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=60

# Network
iperf3 -c target-host -t 30

# Compare VMware vs. Proxmox results

Rollback Planning

If Migration Fails:

1. Keep ESXi running until all VMs validated
2. Document any issues encountered
3. Maintain VM exports/backups
4. Test rollback procedure:
   - Re-import OVF to ESXi
   - Verify functionality
   - Switch back if needed

5. Decommission ESXi only after:
   - All VMs running on Proxmox for 2+ weeks
   - Backups tested and verified
   - Performance validated
   - Users satisfied

---

Conclusion

Migrating from VMware to Proxmox is more than escaping licensing costs—it’s gaining freedom, flexibility, and community support. Your infrastructure deserves a platform committed to open-source values and continuous improvement.

Key Takeaways:

• Broadcom’s changes make Proxmox migration essential for cost-conscious users
• Proper planning prevents migration disasters
• OVF export and qemu-img conversion are reliable methods
• Post-migration optimization ensures performance parity
• Proxmox offers equivalent features to VMware essentials

Migration Timeline:

Week 1: Planning and documentation
Week 2: Export VMs, install Proxmox
Week 3: Import and test non-critical VMs
Week 4: Import production VMs, validate
Week 5+: Optimize, decommission VMware

Next Steps:

• Join Proxmox forums for community support
• Explore advanced features (Ceph, GPU passthrough)
• Implement monitoring (Prometheus, Grafana)
• Automate with Terraform and Ansible
• Share your migration story to help others

Resources:

• Proxmox Documentation: https://pve.proxmox.com/wiki/
• Community Forum: https://forum.proxmox.com/
• r/Proxmox: Reddit community
• Migration Tools: https://github.com/topics/proxmox-migration

Welcome to the open-source virtualization future. Your migration marks the beginning of true infrastructure freedom.