Migrate VMware vSphere VMs to Proxmox VE

Migrating virtual machines from VMware vSphere to Proxmox VE lets you move off proprietary hypervisor licensing while keeping your guest OS, applications, and data intact. The process involves exporting each VM as an OVF/OVA or using a direct disk transfer, then importing it into Proxmox and adjusting the VM configuration for the new hypervisor. You’ll need administrative access to both environments, enough storage on the Proxmox side, and a brief maintenance window for each VM.

What You’ll Need

• Access to the VMware vSphere Client or ESXi host (to export or copy VMDK files).
• Access to the Proxmox VE web interface (root or a user with VM creation privileges).
• SSH access to the Proxmox node (for command-line steps).
• Sufficient free storage on the Proxmox node (at least the size of the source VMDK files).
• Optional: A shared network location or a temporary staging area for the disk images.
• A backup of the VM before starting (always recommended).

Step-by-Step

1. Prepare the VM in VMware. Shut down the VM cleanly from the guest OS. In vSphere, remove any VMware Tools that are not needed (optional, but can reduce clutter). Note the VM’s hardware settings: CPU count, memory, disk size, network adapter type, and any passthrough devices.
2. Export the VM as OVF/OVA. In vSphere Client, right-click the VM and select Export OVF Template. Choose a location that is accessible from the Proxmox node (e.g., a shared NFS or SMB share, or a local path you can copy later). If you export as OVA, you’ll get a single file; OVF gives a folder with multiple files. For large disks, OVA can be easier to handle.
3. Transfer the OVF/OVA to the Proxmox node. Use SCP, SFTP, or a mounted network share to copy the exported files to a directory on the Proxmox node, for example /var/lib/vz/template/iso/ or a temporary folder like /tmp/. If you used an OVA, you may need to extract it first (it’s a tar archive). You can do this with tar -xvf vm.ova on the Proxmox shell.
4. Import the disk into Proxmox. Open the Proxmox web interface, select your node, and click Create VM. In the wizard, set the VM ID and name. On the OS tab, choose Do not use any media. On the Hard Disk tab, select Import disk image (or Import in newer versions). Browse to the VMDK or OVF file you uploaded. If you have multiple disks, you’ll need to import them one by one, or use the command-line tool qm importdisk for each VMDK.
5. Configure the VM hardware. Match the CPU type (choose host for best performance, or a specific model if needed), memory, and network adapter. For the network, select the bridge that corresponds to your Proxmox network (e.g., vmbr0). Set the disk bus to VirtIO Block or SATA (VirtIO is faster but requires drivers; SATA is more compatible). If the VM used a SCSI controller in VMware, you may need to change it to LSI or VirtIO SCSI in Proxmox.
6. Adjust the boot order. Ensure the disk is set as the first boot device. In the Options tab of the VM, check the boot order and set it to the disk (or the appropriate controller).
7. Start the VM and install drivers. Power on the VM. If it doesn’t boot, you may need to boot from a rescue CD (like a Linux live ISO) to fix the bootloader. For Windows VMs, install the VirtIO drivers (balloon, network, storage) from the VirtIO ISO available on the Proxmox wiki. For Linux VMs, the kernel usually includes VirtIO support, but you may need to update initramfs if the root device changes.
8. Remove VMware Tools and finalize. Once the VM is running, uninstall VMware Tools (or just leave it). Update the guest OS drivers as needed. Test all applications and network connectivity.

Common Mistakes

• Not matching the disk controller. VMware often uses LSI Logic SCSI. Proxmox defaults to VirtIO. If you don’t change the controller to match (or install VirtIO drivers), the VM won’t see the disk.
• Forgetting to set the boot order. The VM might try to boot from the network or a CD-ROM and fail.
• Using the wrong CPU type. If you set CPU to host and later migrate the VM to another node with a different CPU, it may crash. Use a common baseline like qemu64 for compatibility, or accept the risk.
• Not checking disk size. The imported disk might be smaller than the original if you didn’t export the full VMDK (e.g., using thin provisioning). Always verify the disk size in Proxmox.
• Ignoring network adapter type. The default e1000 works, but VirtIO is faster. If you use VirtIO, you must install the drivers first, or you’ll lose network connectivity.

Tips

• For large VMs, use qm importdisk from the command line. It’s faster and more reliable than the web interface for big files.
• Convert VMDK to qcow2 during import if you want to use Proxmox’s native format. The import tool can do this automatically.
• Test with a non-critical VM first to get comfortable with the process.
• If you have many VMs, consider scripting the import with a loop in bash, using the Proxmox API or CLI tools.
• Keep the VM powered off during the entire migration to ensure data consistency.

Troubleshooting

• VM doesn’t boot after import. Check the disk controller. If you used VirtIO, try switching to SATA or IDE. Also check the boot order in the VM options. If the bootloader is broken, boot from a rescue ISO and reinstall GRUB (for Linux) or fix the BCD (for Windows).
• Network not working. If you used VirtIO NIC, the guest may not have the driver. Switch to e1000 temporarily to get network, then install VirtIO drivers and switch back. Also verify the bridge is correct and the network is up on the Proxmox node.
• Disk not detected. Confirm the disk is attached to the VM and the controller type is supported. Check the Proxmox logs (/var/log/pve/tasks/ and dmesg in the guest) for errors.
• Import fails with an error. Make sure the VMDK file is not corrupted. Try re-exporting from VMware. Also ensure there is enough free space on the Proxmox storage. If the OVA is very large, split it or use a direct copy method.
• Performance is poor. Install VirtIO drivers for disk and network. Also set the CPU type to host if the VM will stay on the same node. Check that the balloon driver is installed for memory management.

Frequently Asked Questions

Can I migrate a VM without shutting it down?

Yes, you can use a tool like qemu-img convert to copy a live VMDK, but it’s risky. The disk may be inconsistent. For production, always shut down the VM.

Do I need to convert VMDK to qcow2?

No, Proxmox can use VMDK directly, but qcow2 is recommended for better features like snapshots and compression. The import process can convert automatically.

Will my Windows license still work?

Usually yes, but Windows may deactivate if it detects a major hardware change. You may need to reactivate by phone or with your volume license key.

Can I migrate VMs with multiple disks?

Yes, export all disks from VMware and import each one into the VM in Proxmox. Make sure to attach them in the correct order.

What about VMware Tools?

You can leave them installed; they won’t cause issues, but they are unnecessary. Uninstall them after migration to reduce clutter.

Is there a way to automate this for many VMs?

Yes, you can script the export using PowerCLI on the VMware side, and use the Proxmox API or qm commands on the Proxmox side. However, each VM may need individual attention for driver and boot configuration.

Related

• Protect the Border Codes? Meaning and Practical Advice
• Best WordPress Themes: How to Choose the Right One
• How to Audit an AI Agent’s Permissions and Data Access