More and more organizations are weighing a migration from VMware ESXi to Proxmox VE after the license changes Broadcom introduced. But moving virtual machines between these platforms is far more than converting a VMDK file or importing a VM. The gap between a planned migration and a rushed one can mean hours of downtime, blue screens, Linux systems that won’t boot, or performance losses that are hard to diagnose.
Migrating from VMware to Proxmox VE in 20 seconds
- Migrating a VM isn’t just converting disks; it also changes the hypervisor, drivers, and input/output architecture.
- Windows and Linux should be prepared before the final shutdown in VMware to avoid boot problems.
- Storage, networking, and VirtIO drivers are among the most delicate points in the transition.
- Testing the whole process in a lab and having verified backups sharply cuts the risk in production.
The good news is that Proxmox VE offers a mature platform built on open technologies like KVM, QEMU, Linux, and ZFS. The catch is that this flexibility also means understanding how all these components interact. This guide pulls together the main technical recommendations to reduce risk during migration.
Migration isn’t just copying a virtual disk
A common misconception is thinking it’s enough to shut down a VMware ESXi VM, convert the VMDK, and import it into Proxmox VE.
In reality, several fundamental components change during the process:
- The hypervisor switches from VMware ESXi to KVM.
- The virtual hardware presented to the OS is different.
- Storage and network drivers change.
- Storage management is altered.
- Snapshot and backup mechanisms are different.
If the guest operating system isn’t ready for these changes, boot errors can appear right after migration.
On Windows, you’ll often hit the well-known INACCESSIBLE_BOOT_DEVICE (0x0000007B) error when the system tries to boot with a driver that no longer exists.
On Red Hat-based Linux distributions like Rocky Linux, AlmaLinux, or SUSE, a typical symptom is dropping into the dracut emergency shell, because initramfs lacks the modules needed to reach the new disk.
Preparing Windows before shutting down the VM
A good practice is to prepare the OS while it’s still running on VMware.
Common checks include:
| Check | Reason |
|---|---|
| Install VirtIO drivers | Enables access to KVM’s virtual hardware |
| Enable the viostor service | Prevents boot errors when switching the SCSI driver |
| Remove VMware Tools if appropriate | Reduces conflicts with VMware-specific components |
| Install QEMU Guest Agent after migration | Improves integration with Proxmox VE |
In many migrations, the viostor service is also set to start automatically by editing the Windows registry.
Linux needs to rebuild initramfs
On Linux, the problem often sits in initramfs.
Before the final shutdown, it’s a good idea to regenerate it with the VirtIO modules KVM will use.
On RHEL-based distributions, you can use a procedure like this:
dracut --add-drivers "virtio_blk virtio_scsi virtio_net virtio_pci" --forceIt’s also worth checking:
- The presence of VirtIO modules
- Removal of VMware-specific components once they are no longer needed
- Installation of the qemu-guest-agent package
Note that not all distributions use the same tools. Debian, Ubuntu, or SUSE follow different procedures, so always check the official documentation.
Storage matters more than it looks
Disk conversion is usually done with tools like:
qemu-img convert -f vmdk -O raw source.vmdk destination.rawBut the process doesn’t stop there.
Final performance depends on the backend used in Proxmox VE.
If you use ZFS
You want to tune parameters carefully, such as:
- volblocksize
- ashift
- compression
- ARC
In databases especially, a wrong volblocksize can sharply increase the phenomenon known as Write Amplification, cutting performance.
On servers with lots of memory, it’s common to cap ARC use with parameters like zfs_arc_max so it doesn’t compete with the memory assigned to VMs.
If you use Ceph
In Ceph RBD environments, it’s often recommended to enable support for TRIM and discard commands to help reclaim space.
Common configurations include options like:
- discard=on
- issue_discards=1
These settings depend on the storage type and the version in use.
The virtual network changes too
Another aspect that’s often underestimated is networking.
On VMware, common setups include:
- vSwitch Standard
- VMware Distributed Switch (vDS)
- Port Groups
- VLAN Trunking
On Proxmox VE, the main options are:
- Linux Bridge
- Open vSwitch (optional)
- Proxmox SDN
- VXLAN
- EVPN
It’s not enough to copy the visual setup.
Other things to check include:
- MTU settings
- VLAN tagging
- Bonding
- LACP
- Jumbo Frames
A misconfiguration, like an MTU mismatch between 9000 and 1500, can cause intermittent connectivity issues that are hard to diagnose.
Don’t forget backups
Another critical change is data protection.
On VMware, many organizations rely on VMware VADP with third-party backup solutions.
On Proxmox VE, the integration is different and usually leans on Proxmox Backup Server (PBS), which offers technologies like:
- Incremental backups using QEMU’s Dirty Bitmaps
- Block-based deduplication
- Compression
- Encryption
- Automatic backup verification
Before starting a migration, make sure your backup strategy still meets your recovery objectives (RPO and RTO).
Pre-migration checklist
Before scheduling a maintenance window, review at least the following:
| Verification | Status |
|---|---|
| Verified backups | ☐ |
| VirtIO drivers prepared | ☐ |
| Viostor service enabled (Windows) | ☐ |
| Initramfs regenerated (Linux) | ☐ |
| VMware Tools reviewed | ☐ |
| QEMU guest agent prepared | ☐ |
| Network design validated | ☐ |
| End-to-end MTU verified | ☐ |
| Storage configuration reviewed | ☐ |
| Lab testing conducted | ☐ |
Migrating also changes how you manage the infrastructure
One of the most common mistakes is assuming that leaving VMware only cuts licensing costs.
In reality, some of that saving often shifts to the technical expertise needed to run an open platform.
Managing Proxmox VE well means getting comfortable with technologies like:
- Linux
- QEMU/KVM
- ZFS
- Ceph
- Linux networking
- Automation
- High availability
That can be a benefit for many organizations, since it removes dependence on proprietary software. But it also needs staff with experience, or a specialized provider during the transition.
Frequently Asked Questions
Is converting a VMDK enough to migrate a VM?
No. Besides the virtual disk, you have to review drivers, OS configuration, network, storage, and integration tools for the new hypervisor.
Do all Windows systems need VirtIO drivers installed?
Most of the time, yes. Preparing these drivers before migration sharply reduces boot errors related to disk access.
What if Linux doesn’t include VirtIO modules in initramfs?
The system may fail to detect the storage device at boot and land in a recovery shell like dracut or emergency initramfs, depending on the distribution.
Does Proxmox VE provide backup tools comparable to VMware?
Yes. Proxmox Backup Server offers incremental backups, deduplication, compression, encryption, and integrity verification, though its ecosystem is different from VMware’s.
Important notice
This guide is purely technical and informational. Every infrastructure has its own particulars in hardware, VMware ESXi and Proxmox VE versions, guest OS, storage, and deployed applications.
The configurations, commands, and parameters mentioned are common examples and should not be considered valid for all environments. Before running any migration in production, test the procedure in a representative lab, make sure you have verified backups, and always consult the official documentation for VMware, Proxmox, QEMU, Microsoft, Red Hat, SUSE, Debian, Ubuntu, OpenZFS, Ceph, and the other vendors involved.
Likewise, parameters such as volblocksize, zfs_arc_max, discard, issue_discards, or VirtIO driver settings should be adjusted to your workload, storage architecture, and the specific platform recommendations. Running these procedures and handling any consequences is the sole responsibility of the administrator or organization performing them.