Migrating from VMware ESXi to Proxmox VE: A Technical Guide to Avoid the Most Critical Mistakes

An increasing number of organizations are evaluating the migration from VMware ESXi to Proxmox VE following the license model changes introduced by Broadcom. However, moving virtual machines between these platforms involves much more than just converting a VMDK file or importing a VM. The difference between a planned migration and a hasty one can result in hours of downtime, blue screens, Linux systems that fail to boot, or performance losses that are difficult to diagnose.

The keys to migrating from VMware to Proxmox VE in 20 seconds

• Migrating a VM isn’t just about converting disks; it also involves changing the hypervisor, drivers, and input/output architecture.
• Windows and Linux should be prepared before the final shutdown in VMware to avoid boot issues.
• Storage, networking, and VirtIO drivers are some of the most delicate points during the transition.
• Testing the entire process in a lab environment and having verified backups drastically reduces risks in production.

The good news is that Proxmox VE offers a mature platform based on open technologies such as KVM, QEMU, Linux, and ZFS. The less positive aspect is that this flexibility also requires understanding how all these components interact. This guide compiles the main technical recommendations to minimize risks during migration.

Migration isn’t just about copying a virtual disk

One common misconception is thinking that simply shutting down a VMware ESXi VM, converting the VMDK and importing it into Proxmox VE is enough.

In reality, multiple fundamental components change during this 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 prepared for these changes, boot errors may occur immediately after migration.

In Windows environments, it’s quite common to encounter the well-known INACCESSIBLE_BOOT_DEVICE (0x0000007B) error when the system tries to boot using a driver that no longer exists.

In Red Hat-based Linux distributions like Rocky Linux, AlmaLinux, or SUSE, a typical symptom is ending up in the dracut emergency shell because initramfs lacks the modules needed to access 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:

In many migrations, the viostor service is also configured to start automatically by editing the Windows registry.

Linux needs to rebuild initramfs

In Linux systems, the problem often lies in initramfs.

Before finally shutting down, it’s advisable to regenerate it with the VirtIO modules that KVM will use.

In RHEL-based distributions, a procedure similar to the following can be used:

dracut --add-drivers "virtio_blk virtio_scsi virtio_net virtio_pci" --force

It’s also recommended to check:

• 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 have different procedures, so always follow the official documentation.

Storage is more critical than it appears

Disk conversion is typically done using tools like:

qemu-img convert -f vmdk -O raw source.vmdk destination.raw

However, the process doesn’t end there.

Final performance depends on the backend used in Proxmox VE.

If using ZFS

It’s important to carefully tune parameters such as:

• volblocksize
• ashift
• compression
• ARC

Especially in databases, an incorrect volblocksize can significantly increase the phenomenon known as Write Amplification, reducing performance.

In servers with large amounts of memory, it’s common to limit ARC consumption with parameters like zfs_arc_max to avoid competing with the memory allocated for VMs.

If using 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 type of storage and the version in use.

Virtual network also changes

Another aspect often underestimated is networking.

In VMware, common configurations include:

• vSwitch Standard
• VMware Distributed Switch (vDS)
• Port Groups
• VLAN Trunking

In Proxmox VE, the main options are:

• Linux Bridge
• Open vSwitch (optional)
• Proxmox SDN
• VXLAN
• EVPN

It’s not enough to simply replicate the visual setup.

Other aspects to verify include:

• MTU settings
• VLAN tagging
• Bonding
• LACP
• Jumbo Frames

A misconfiguration, such as an MTU mismatch between 9000 and 1500, can cause intermittent connectivity issues that are hard to diagnose.

Don’t forget backups

Another critical change concerns data protection.

In VMware, many organizations rely on VMware VADP combined with third-party backup solutions.

In Proxmox VE, integration is different and typically leverages 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, it’s advisable to ensure that your backup strategy still meets your recovery objectives (RPO and RTO).

Pre-migration checklist

Before scheduling a maintenance window, review at least the following:

Migrating also means changing how you manage the infrastructure

One of the most common mistakes is thinking that abandoning VMware only reduces licensing costs.

In reality, some of those savings often shift to the technical expertise required to operate an open platform.

Managing Proxmox VE effectively involves familiarization with technologies such as:

• Linux
• QEMU/KVM
• ZFS
• Ceph
• Linux networking
• Automation
• High availability

This can be a benefit for many organizations, as it eliminates dependence on proprietary software. However, it also requires personnel with experience or engaging a specialized provider during the transition process.

Frequently Asked Questions

Is converting a VMDK enough to migrate a VM?

No. Besides the virtual disk, you must 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 significantly 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. Each infrastructure has unique features related to hardware, VMware ESXi versions, Proxmox VE, 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 executing any migration in production, it’s advisable to test the procedure in a representative lab, ensure verified backups are available, and always consult the official documentation for VMware, Proxmox, QEMU, Microsoft, Red Hat, SUSE, Debian, Ubuntu, OpenZFS, Ceph, and other involved vendors.

Likewise, parameters such as volblocksize, zfs_arc_max, discard, issue_discards, or VirtIO driver settings should be adjusted according to workload, storage architecture, and specific platform recommendations. Executing these procedures and handling any potential consequences is the sole responsibility of the administrator or organization performing them.