ESXi to Proxmox VE: disk import, drivers, networking and what does not carry over

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Copying the disks is the easy part of leaving ESXi. Most failed moves come from the guest meeting different virtual hardware, so the work is in three places: boot firmware and disk bus, then the VirtIO driver switch on Windows, then guest network identity. Bring Windows up first on SATA or IDE, then switch to VirtIO with a temporary disk. Linux needs its VirtIO drivers in the initramfs before the move.

Validate the illustrated migration on an isolated pilot. Identifiers are examples.

Interpretations are editorial; no lab testing was performed.

Why it matters

The ESXi importer is new and still changing. The Proxmox VE documentation describes the import wizard as a tech preview, added during the 8.2 development cycle. It is tested on ESXi 6.5 through 8.0. If you run ESXi 9, the pages opened for this article do not cover you, so test before you plan around it.

Windows is the harder guest. Proxmox says it cannot guarantee a successful import of Windows VMs in all cases, and that Linux can usually be imported without hassle.

How it works

What the importer does

Proxmox adds an ESXi host as a special import-source storage. A FUSE filesystem provides the interface between Proxmox VE and ESXi. Most of the VM's configuration is mapped to Proxmox's model, and the Resulting Config tab shows the exact key and value pairs before you start.

Point it at the ESXi host, not vCenter. Going through vCenter is 5 to 10 times slower.

Limits that stop or slow an import

Two separate limits apply. To protect ESXi, esxi-folder-fuse holds itself to four parallel connections, and an overloaded API blocks every request, including other running imports, "which can result in hanging IO for guests that get live-imported". To protect the Proxmox host, each disk takes a read-ahead cache of 8 blocks of 128 MiB, 1 GiB by our arithmetic. Proxmox advises no more than four VM disks at once and says some setups can manage only one import at a time.

If you still hit rate limiting or 503 errors, Proxmox documents raising or disabling the session limit. On ESXi 7.0 that is Config.HostAgent.vmacore.soap.maxSessionCount. On 6.5 and 6.7 it is sessionTimeout and maxSessionCount in /etc/vmware/hostd/config.xml, followed by a hostd restart. The wiki gives no setting for 8.0. Our caution: this changes a production host. Plan any hostd restart and put the limit back afterwards.

Choosing an import method

Proxmox warns against live import on networks with low bandwidth or high error rates. Read the failure rule again before using it on a database: a failed live import throws away the new writes.

Warning. With attach and move, the VM must be powered on in only one of VMware or Proxmox, never both. Both at once corrupts the disk. Stop the source and disable anything that might restart it, such as VM autostart.

The manual disk import

# Run from the directory holding the descriptor and flat files
qm disk import 104 Server.vmdk local-zfs --target-disk sata0
qm set 104 --boot order=sata0
qm config 104

--format applies only where the storage holds images as files, and its options are raw, vmdk and qcow2. It is left out here because ZFS volumes are not files. Without --target-disk, the volume appears as an unused disk that you attach by hand. Proxmox needs both the .vmdk and the -flat.vmdk.

When virt-v2v earns its place

virt-v2v converts the guest offline: it installs VirtIO drivers for Windows from an ISO or from /usr/share/virtio-win. Proxmox is not one of its output targets. The supported outputs are QEMU and KVM, OpenStack, oVirt, local libvirt and local disk, so you write to a directory and then import each disk with qm:

virt-v2v -i vmx -it ssh \
  "ssh://root@esxi.example.com/vmfs/volumes/datastore1/guest/guest.vmx" \
  -o local -os /var/tmp --block-driver virtio-scsi

Five things to check before committing to it:

• Authentication. The command above needs one of two methods: a password file passed with -ip, or ssh-agent with your public key in /etc/ssh/keys-root/authorized_keys on the ESXi host. Adding a root key to a hypervisor is a security decision, so make it deliberately. We would remove the key afterwards.
• The default block driver is virtio-blk. Proxmox recommends SCSI with VirtIO SCSI single and says VirtIO block may be deprecated, so set --block-driver virtio-scsi and present that same bus afterwards. The option only affects pre-installation of Windows storage drivers. It does not change the bus Proxmox presents and has no effect on Linux guests. By our reading a mismatch is a route to the 0x7B boot failure described below.
• The SSH transport refuses guests with snapshots, and needs SSH enabled on the ESXi host, which is off by default.
• Upstream support for ESXi input needs vCenter 5.0 or later unless VDDK is available. VDDK is VMware's proprietary library. VMX files are listed as a separate input.
• Windows can reboot four or more times on first boot. Do not interrupt this.

Whether Proxmox VE 9.2 packages virt-v2v and the Windows driver set was not confirmed in the pages opened. Check before you plan on it.

virt-v2v also refuses or fails some guests:

• Windows on a Dynamic Disk system volume cannot be converted.
• Guests using Fast Startup or hibernation must have it disabled first.
• Antivirus and Group Policy can prevent driver installation. The manual advises disabling or removing them for the conversion.

Firmware and virtual hardware

Match the source firmware. Legacy BIOS maps to SeaBIOS and UEFI maps to OVMF. Getting this wrong produces a VM that finds no boot device.

UEFI has a second trap. Some operating systems register only their own boot entry and not the default path /EFI/BOOT/BOOTX64.EFI, so the VM will not boot even with OVMF set. Add the entry in the firmware menu, and configure an EFI disk so that it persists:

qm set 104 -efidisk0 local-zfs:1,efitype=4m,pre-enrolled-keys=1

pre-enrolled-keys=1 also enables Secure Boot by default, so set it to match what the source guest used.

Check the certificates too. An EFI disk with only the 2011 certificates will reject bootloaders signed with the 2023 certificates. New EFI disks carry both from pve-edk2-firmware 4.2025.05-1, shown by ms-cert=2023k in the VM configuration. Enrolling them on an older EFI disk needs BitLocker protectors disabled first, or Windows will ask for the recovery key on the next boot.

For Windows, the machine version is pinned at creation because Windows is sensitive to hardware changes, including how network devices enumerate. Linux uses the latest by default.

Windows: the VirtIO switch

Windows has no native VirtIO support. Only IDE or SATA work out of the box, so import to one of those and switch afterwards.

Switching the boot disk straight to VirtIO SCSI without first letting Windows meet the driver produces an INACCESSIBLE_BOOT_DEVICE blue screen. Returning to the previous supported attachment can help diagnosis, but does not guarantee recovery. The documented sequence uses a temporary disk:

1. Boot on SATA or IDE. Mount the virtio-win ISO.
2. Add a 1 GB disk on the VirtIO SCSI controller. Windows should detect it, hot-plugged or after a reboot.
3. Install the driver for the unknown device from the ISO, using vioscsi for SCSI. Wait for the disk to appear in Disk Management.
4. Shut down. Detach and remove the temporary disk.
5. Detach the boot disk, then re-attach it from the unused list as SCSI.
6. Set the boot order again. Until you do, it still names the old disk.
7. Start. If it fails, re-attach as IDE or SATA and repeat.

virtio-win-gt-x64.msi on the ISO installs the remaining drivers and services. Check Device Manager afterwards for unknown devices and point them at the ISO with Include subfolders ticked.

Which driver version

Do not simply take the newest ISO. As of 10 September 2026, Proxmox's wiki says:

Boot failure 0x7B

If Windows stops with 0x0000007B, the cause is that it cannot find or load the right disk driver. Check the complete storage path and firmware before choosing a supported recovery procedure. The manual's checks are that you are "presenting a virtio-blk interface (not virtio-scsi and not ide)", that Group Policy is not restricting device installation, and that no antivirus is blocking the driver. The first check reflects virt-v2v's default. After --block-driver virtio-scsi, we read it as requiring VirtIO SCSI instead.

Linux: get the driver into the initramfs before you leave

Proxmox's advice is direct: ensure VirtIO drivers are installed in the guest and loaded in the initramfs before migrating.

An initramfs built for the current hardware may lack them. dracut's manual says a --hostonly image holds only what this machine needs, so the disk cannot move to another controller until the image is recreated. On Debian the equivalent is MODULES in initramfs.conf: most adds "most file system, all ata, sata, scsi and usb drivers", while dep adds only what the running box appears to need. Proxmox's QEMU chapter says Linux distributions "have all the necessary drivers installed by default", while the wiki says it "might be necessary" to add them to the initramfs. The image contents and the selected kernel's configuration together provide the evidence for your guest. In the kernel source the relevant modules are virtio_scsi and virtio_pci. Depending on the kernel, these may be built in rather than loadable, so a missing .ko is not proof of a problem until you check the kernel's configuration.

# Red Hat family: rebuild, then confirm
dracut --force --add-drivers "virtio_scsi virtio_pci"
lsinitrd | grep -i virtio

# Debian family: add virtio_scsi and virtio_pci to /etc/initramfs-tools/modules, then
update-initramfs -u
lsinitramfs /boot/initrd.img-$(uname -r) | grep -i virtio

If a guest has already moved and will not boot, the rescue boot entry often carries more drivers. Failing that, set the disk bus to IDE or SATA, boot, and rebuild.

virt-v2v does not help here in the way it does for Windows. This version does not install new Linux kernels or drivers; it warns if they are missing.

Networking

Each virtual switch on Proxmox is a Linux bridge, named vmbr{X}. A VLAN that sat on an ESXi port group becomes a tag on the VM's NIC, on a VLAN-aware bridge, or a cluster-wide SDN VLAN zone.

qm set 104 --net0 virtio,bridge=vmbr0,tag=20,macaddr=BC:24:11:AA:BB:CC

The wizard's Advanced tab selects bridges and NIC models, but the steps opened do not state that it carries over VLAN IDs. Check tag= in the Resulting Config tab before you start. A wrong tag produces a VM that boots with no connectivity.

NIC model. VirtIO needs the guest driver. vmxnet3 is offered but documented as something to use only when importing from another hypervisor. Windows has no VirtIO network driver until you install it, so use a temporary model if you need connectivity during the driver work. Jumbo frames need attention, because per-NIC MTU is only available on VirtIO devices. Leave it empty to inherit from the bridge.

MAC addresses. Proxmox generates a random MAC for each new NIC. Proxmox's guidance is to adapt any DHCP reservation or set the MAC manually. Software licensed against a MAC or a BIOS UUID also needs checking. macaddr= and --smbios1 set these explicitly. Our suggestion is to make a deliberate choice for each VM rather than leaving it to the defaults.

Windows static addresses. After migration the adapter is a new device, and Windows warns if you assign an address still held by the old, absent adapter. Proxmox suggests considering removing the static configuration before migrating. Record it first.

Linux interface names. The name will most likely change. Slot-based names are derived from the PCI slot, and a new hypervisor presents a new slot layout. Update the network configuration that names the old device, whether netplan, NetworkManager or /etc/network/interfaces. Do this from the console, because you have no network yet.

What does not carry over

The ordering of Tools removal deserves its own warning. Remove it the normal way first, through the Windows installed-programs list or your Linux package manager (our wording, as the pages opened do not describe the routine). Broadcom's KB 315629 is the fallback when an install, upgrade or uninstall fails. It deletes files and registry entries by hand, says to take a backup or snapshot first, and notes the steps may fail once a VM has moved to another hypervisor. A snapshot slows the import and blocks virt-v2v's SSH path. Our suggested order is to snapshot, remove Tools and verify, then delete the snapshot before the import window.

The pages opened do not address a guest whose boot disk or NIC depends on a driver that came with Tools. Our inference: try the removal on a clone first. If the guest relies on PVSCSI or VMXNET3, move it to SATA and E1000 before removing Tools.

Warning. If BitLocker keys live only in the vTPM, have the recovery key in hand before powering off. Proxmox says to keep manual keys available and to consider disabling the encryption first. Without the key, the imported disk cannot be read.

What to choose and why

These are editorial recommendations.

Order for one VM:

1. Test the whole path on a non-production VM of the same OS. Proxmox highly recommends this.
2. Record firmware type, disk layout, NIC details, VLANs and static addressing.
3. Back up. Confirm a restore path to ESXi still exists.
4. Linux: rebuild the initramfs with VirtIO. Windows: fetch recovery keys and confirm the driver ISO.
5. Remove VMware Tools. Clear static addressing if you have chosen to. Delete snapshots.
6. Power off the source and disable restart.
7. Import. Windows goes to SATA first.
8. Boot, fix networking from the console, install the guest agent.
9. Switch Windows to VirtIO using the temporary disk.
10. Validate the application, then take the first Proxmox backup.

Risks and limits

• Tech preview. A tech preview importer may change between releases. Read the current wiki when you start, because its import section is dated November 2024.

Sources

Opened 2026-11-10.

• Software-Defined Network, Proxmox VE
• initramfs.conf(5), Debian trixie
• Migrate to Proxmox VE, wiki
• QEMU/KVM Virtual Machines, Proxmox VE
• qm(1), Proxmox VE
• Paravirtualized Block Drivers for Windows, wiki
• Windows VirtIO Drivers, wiki
• Windows 2025 guest best practices, wiki
• Qemu-guest-agent, wiki
• Host System Administration, Proxmox VE
• Proxmox VE Firewall
• High Availability, Proxmox VE
• virt-v2v(1)
• virt-v2v-input-vmware(1)
• virt-v2v-support(1)
• Installing, upgrading or uninstalling VMware Tools fails, Broadcom KB 315629
• dracut(8)
• lsinitrd(1)
• initramfs-tools(7)
• update-initramfs(8)
• lsinitramfs(8)
• systemd.net-naming-scheme(7)
• Linux kernel source, drivers/scsi/Makefile and drivers/virtio/Makefile

This article was originally published on 10 November 2026.