Migrate VMs from VMware ESXi to Proxmox VE (Import Wizard Guide)

If you've been running production workloads on VMware ESXi and you're eyeing the exit — because of licensing changes, cost, or just wanting a platform you actually control — the part that stops most people isn't Proxmox VE itself. It's moving the VMs you already have without rebuilding them from scratch or taking a weekend of downtime to do it.

Since Proxmox VE 8.1/8.2, there's a built-in Import Wizard that talks directly to an ESXi host's API, lists every VM sitting on it, and imports the disks and configuration into Proxmox VE with minimal manual translation. No OVF export, no third-party conversion tool, no scripting required. By Proxmox VE 9.x it's the default, first-choice path for ESXi migrations for most homelabs and small-to-mid production environments.

This guide walks through the entire process: adding an ESXi host as an import source, what the wizard actually does with the VM's configuration, the live-import option and when to trust it, the driver and BIOS gotchas that catch people out afterward, and the specific limitations (vSAN, encrypted disks, snapshots) that mean this isn't always a one-click job.

What You Will Learn

How the Proxmox VE ESXi Import Wizard works and what it does and doesn't migrate automatically
How to add an ESXi host as an import-source storage, from both the GUI and the command line
The full step-by-step import process, including the Advanced and Resulting Config tabs
When to use Live-Import versus a plain offline import, and the real risk trade-off between them
Pre-migration prep that prevents the most common import failures (snapshots, vSAN, vTPM, datastore names)
Post-migration steps for VirtIO drivers, BIOS/UEFI matching, and networking
How to migrate several VMs at once without hitting ESXi's API connection limits

What Is the ESXi Import Wizard?

The Import Wizard is a storage plugin, not a separate application. You add your ESXi host to Proxmox VE the same way you'd add an NFS share or a Ceph pool — as a storage entry of type esxi. Once it's added, Proxmox VE talks to the ESXi host's own API and mounts it as a read-only, browsable source. Every VM registered on that host shows up in the resource tree under the new storage entry, and each one has an Import button next to it.

Under the hood, the tool (shipped as the pve-esxi-import-tools package, written in Rust) reads VMX configuration files through a FUSE-based virtual filesystem with tuned read-ahead caching, and maps as much of that configuration as it reasonably can onto Proxmox VE's own config model: CPU count and type, memory, disk layout, network interfaces, and BIOS/EFI firmware type. It doesn't touch the source VM beyond reading it — nothing is modified or deleted on the ESXi side.

This is meaningfully different from the older, manual approach of exporting an OVF template, converting disks with qemu-img, and hand-writing a new VM config. The wizard does all three of those steps in one guided flow, and it exposes the intermediate config so you can review and adjust anything it got wrong before committing.

Why Migrate from ESXi to Proxmox VE?

The reasons vary, but a few come up constantly in the Proxmox community and support forums:

Broadcom's post-acquisition licensing changes made per-core VMware licensing prohibitively expensive for smaller shops that used to run on free ESXi or modestly priced vSphere Essentials
Proxmox VE is free and open source, with an optional paid subscription for enterprise repo access and support — there's no forced per-socket or per-core licensing model
Built-in clustering, live migration between nodes, ZFS and Ceph storage, and a firewall are included out of the box, where the VMware equivalents often sit behind vCenter or higher licensing tiers
It's a straightforward fit for existing Linux/KVM operational knowledge, since Proxmox VE is Debian-based QEMU/KVM under a management layer

None of that matters much if the migration path is painful, though, which is exactly the gap the Import Wizard was built to close.

Prerequisites

Before you open the wizard, get these sorted first — skipping any of them is the most common cause of an import that fails halfway through:

A Proxmox VE node on version 8.1 or newer, fully updated (apt update && apt full-upgrade), so you have the current pve-manager, libpve-storage-perl, and pve-esxi-import-tools packages
Network connectivity from the Proxmox VE node to the ESXi host's management interface, and enough bandwidth between them — this is a full disk copy, not a metadata operation
An ESXi account with administrative rights on the host (root, or an account with equivalent read/export privileges)
ESXi version 6.5 through 8.0 — this is the tested range; newer or much older versions may work but aren't officially validated
The source VM powered off, or a clear decision to use Live-Import (covered below) if you need it running during the copy
All snapshots on the source VM consolidated and removed in the vSphere/ESXi client — unconsolidated snapshots are the single most common cause of import failures and painfully slow imports
Disks not backed by vSAN — vSAN-backed storage isn't currently supported as an import source at all
No virtual TPM (vTPM) requirement, since vTPM state cannot currently be migrated from VMware to Proxmox VE — if the guest needs it (e.g., BitLocker-encrypted Windows relying on vTPM), decrypt or disable that dependency first

Step-by-Step Tutorial

Step 1: Clean Up the Source VM in vSphere/ESXi First

Before touching Proxmox VE at all, go into the vSphere Client (or the ESXi host client directly) and:

Delete or consolidate every snapshot on the VM you're migrating
Note down its static network configuration if it has one, since adapter names and sometimes MAC addresses will change after import
Uninstall VMware Tools inside the guest if you can — it's much easier to remove before migration than to hunt down leftover VMware-specific drivers and services afterward
Confirm the VM's datastore name doesn't contain special characters like +. Datastores with certain punctuation in their names have been reported to break the import; renaming the datastore is the workaround if you hit this
Shut the VM down cleanly, unless you're planning to use Live-Import

Step 2: Add the ESXi Host as Import Storage

In the Proxmox VE web interface, go to Datacenter → Storage → Add → ESXi. Fill in:

ID: any name you'll recognize, e.g. esxi-host01
Server: the ESXi host's IP address or hostname (connect directly to the host, not through vCenter — going through vCenter works but is noticeably slower)
Username / Password: your ESXi admin credentials
Skip Certificate Verification: check this if the host uses a self-signed certificate (the default on most ESXi installs), unless you've already added its CA to the Proxmox VE trust store

If you'd rather do this from the shell, the CLI equivalent is:

pvesm add esxi esxi-host01 \
  --server 192.168.1.50 \
  --username root \
  --password 'your-password-here' \
  --skip-cert-verification 1

Which produces an entry like this in /etc/pve/storage.cfg:

esxi: esxi-host01
        server 192.168.1.50
        username root
        content import
        skip-cert-verification 1

Note that this storage type only ever has content import — it's a read-only source for pulling VMs in, not a place you can store backups or ISOs.

Step 3: Browse the VM List

Once added, the new storage entry appears in the left-hand resource tree. Click it, and Proxmox VE queries the ESXi host and lists every VM it finds, whether powered on, off, or suspended. This confirms connectivity and credentials are working before you commit to importing anything.

Step 4: Start the Import

Select the VM you want and click Import. The dialog that opens has three areas worth understanding:

General tab: set the target VM ID, name, and which storage on the Proxmox VE side the disks should land on
Advanced tab: per-disk target storage overrides, network bridge and model (VirtIO is the recommended default for both NIC and SCSI controller), whether to attach the ISO/CD-ROM the source VM had mounted, and options to disable specific hardware you don't want carried over
Resulting Config tab: a plain key-value preview of the exact VM configuration that will be created — review this before clicking through, since it's much easier to fix a wrong disk controller or missing network bridge here than after the copy has already run

Pick VirtIO for the network adapter and VirtIO SCSI for the disk controller unless you have a specific reason not to (older or unusual guest OSes sometimes need SATA or IDE instead, at least until you can install drivers post-migration). Match the source firmware type: BIOS on the ESXi side maps to SeaBIOS on Proxmox VE, and EFI maps to OVMF.

Step 5: Choose Offline Import or Live-Import

You now have two ways to actually run the copy:

Mode	How it works	Best for
Offline import	VM is powered off on ESXi first, then the wizard copies all disk data before the VM can be started on Proxmox VE	Anything where a maintenance window is acceptable — the safer default
Live-Import	The VM is started on Proxmox VE almost immediately; the blocks needed to boot are fetched first, with the rest of the disk copied asynchronously in the background	Minimizing downtime on VMs you can't take offline for long, over a fast and stable network link

Live-Import sounds like a free lunch, and mostly it is — but read the fine print: if the import process fails partway through, any data written to the VM since the import started is lost, because that data only exists on the Proxmox VE side and the background copy never finished pulling in the rest. Proxmox's own guidance is to test Live-Import on a non-critical VM first before trusting it for anything you can't afford to lose. It also assumes a genuinely stable, low-latency network path to the ESXi host; over anything flaky, use the plain offline import instead.

Step 6: Run the Import and Wait

Click through to start. Progress shows as a standard Proxmox VE task in Datacenter → Tasks. Time to completion depends almost entirely on disk size and whether the ESXi datastore is spinning disk or flash — a 50 GB VM on SSD-backed storage over a gigabit link typically finishes in a few minutes; multi-terabyte VMs on HDD-backed datastores can take hours.

Step 7: Migrating Several VMs? Don't Run Them All at Once

If you're clearing out an entire ESXi host, resist the urge to queue every VM's import simultaneously. The ESXi API has a limited number of concurrent connections, and each import disk uses a read-ahead cache of roughly 8 blocks of 128 MiB. Run too many at once and you'll see 30-second stalls or outright 503 Service Unavailable errors from the ESXi API as it throttles you.

Proxmox's own guidance is to keep concurrent disk imports to four or fewer. If you genuinely need more parallelism, ESXi's session/connection limit can be raised: on ESXi 7.0, through Host → Manage → System → Advanced Settings; on 6.5/6.7, by editing /etc/vmware/hostd/config.xml directly on the host. For most people, serializing imports in small batches is simpler and only costs a bit of wall-clock time.

Post-Migration: What Still Needs Manual Attention

The wizard gets you a bootable VM, not a finished one. Expect to do the following afterward:

Install or Verify VirtIO Drivers

Linux guests generally already have VirtIO drivers in the kernel, but confirm they're actually built into the initramfs (update-initramfs -u on Debian/Ubuntu guests, dracut -f on RHEL-family guests) before switching the disk controller to VirtIO SCSI, otherwise the guest won't find its root disk at boot.

Windows guests need the VirtIO driver ISO (available from the Fedora/Proxmox-maintained virtio-win project) attached as a CD-ROM. If the VM won't boot after switching straight to VirtIO SCSI, temporarily set the disk controller back to SATA or IDE, boot into Windows, install the VirtIO SCSI driver from the attached ISO, shut down, switch the controller to VirtIO SCSI, and boot again. Trying to jump straight to VirtIO without this intermediate step is the single most common "VM won't boot after ESXi import" support thread.

Reconcile Networking

Network adapter names almost always change after migration — a Linux guest that had ens192 under VMware may come up as a different interface name under Proxmox VE's VirtIO NIC, and static IP configuration tied to the old interface name won't apply automatically. This is why documenting the VM's network config before migrating (Step 1) matters: you'll need to reapply it to whatever the new interface is called. For Windows guests, expect a "new network adapter detected" prompt and possibly a reset of the network profile (public/private) on first boot.

Remove Leftover VMware Tooling

If you weren't able to uninstall VMware Tools before migrating, do it now from inside the guest. Leftover VMware Tools services don't typically break anything, but they serve no purpose anymore and are worth cleaning up. Install the QEMU Guest Agent in its place (qemu-guest-agent package on Linux, or via the VirtIO driver ISO on Windows) so Proxmox VE gets proper guest status reporting, clean shutdowns, and IP address visibility in the GUI.

Double-Check BIOS/UEFI Boot Mode

If the source VM used UEFI, confirm the imported VM is set to OVMF, not SeaBIOS, and that it has an EFI Disk defined (Proxmox VE needs a small dedicated volume to store UEFI variables). Some guest OSes need a manual boot entry re-added in the UEFI menu after the underlying firmware implementation changes, even though the boot mode itself matches.

Troubleshooting Common Import Issues

Import Storage Shows a 500 Error or Fails to List VMs

Almost always a credentials or certificate problem. Double-check the ESXi username/password, confirm the account isn't locked out from a previous failed attempt, and if you didn't check "Skip Certificate Verification," make sure the ESXi host's certificate (or its issuing CA) is actually trusted by the Proxmox VE node.

Import Is Extremely Slow or Times Out

Check for two things first: leftover snapshots on the source VM (consolidate them in vSphere/ESXi, then retry), and whether you're connecting through vCenter instead of directly to the ESXi host — going direct is significantly faster. If several imports are running at once, ESXi's connection limits may be throttling you; drop to one or two concurrent imports and see if throughput improves.

VM Won't Boot After Import

This is almost always a missing driver issue. For Linux, boot from a rescue/live ISO to confirm the disk contents are intact, then check that VirtIO modules are present in initramfs. For Windows, temporarily switch the disk controller to SATA or IDE, boot, install VirtIO drivers from the attached ISO, then switch back to VirtIO SCSI.

"Repeated 503 Service Unavailable" from the ESXi API

You've hit ESXi's session/connection cap, usually from running too many simultaneous imports. Wait a few minutes for existing sessions to time out, then retry with fewer concurrent imports, or raise the session limit on the ESXi host as described in Step 7.

vSAN or Encrypted Datastore VM Won't Import

Neither is currently supported as an import source. For vSAN-backed VMs, storage vMotion the disks to a non-vSAN datastore first, then import from there. For disks encrypted via a VM Storage Policy, remove the encryption policy before migrating — there's currently no path to bring an encrypted VMware disk into Proxmox VE encrypted-at-rest through this tool.

Best Practices

Migrate one or two low-priority VMs first as a dry run before touching anything business-critical, so you learn the driver and networking quirks on something disposable. Keep a full backup of the source VM (a VMware-side snapshot export or Proxmox Backup Server target, if you have one available) until you've confirmed the migrated VM is fully working — the import reads from ESXi without modifying it, but you still want a safety net independent of both platforms during the transition period.

When migrating an entire ESXi host's worth of VMs, batch them by priority and size: import small, non-critical VMs first to validate your process, then move to larger or more important ones once you've ironed out the VirtIO driver and networking steps for your particular guest OS mix.

Finally, don't decommission the ESXi host or delete the source VMs until the migrated versions have been running cleanly under normal load for at least a few days. Import problems that don't show up immediately — a missing scheduled task, a service that depended on the old MAC address, a monitoring agent tied to the old hostname — tend to surface after the first few days of real use, not in the first hour.

Frequently Asked Questions

Do I need vCenter to use the Import Wizard?

No. The wizard connects directly to an ESXi host's own API using host-level credentials. Connecting through vCenter is possible but noticeably slower than going directly to the host, so direct is the recommended path when you have the choice.

Which ESXi versions are supported?

ESXi 6.5 through 8.0 have been tested and are the officially supported range. Other versions may work but aren't validated, so treat them as best-effort.

Can I import a running VM without any downtime at all?

Not with zero downtime, but Live-Import gets close: the VM is stopped on ESXi, then started almost immediately on Proxmox VE while the rest of its disk copies in the background. It carries real risk if the import fails mid-copy, so test it on a non-critical VM first and use a stable, fast network link.

The migration is a one-way copy, not a sync, so there's no rollback path built into the tool itself — if you need to fall back, you'd restart the original VM on ESXi (assuming you haven't deleted it) rather than "undo" the import.

What happens to snapshots on the source VM?

They aren't migrated as Proxmox VE snapshots — they need to be consolidated (merged into the base disk) on the ESXi side before you import. VMs with existing snapshots import much more slowly and are more likely to fail, so removing them beforehand isn't optional in practice, even if it's not a hard technical block.

Does the Import Wizard work for vSAN-backed VMs?

Not currently. You'll need to Storage vMotion the VM's disks to a standard (non-vSAN) datastore on the ESXi side first, then run the import from there.

Will my Windows VM's activation survive the migration?

Often yes for volume-licensed or KMS-activated Windows, since the underlying hardware ID changes are usually tolerated. Retail/OEM activations tied more tightly to hardware fingerprints occasionally require reactivation after the hypervisor and virtual hardware change. Keep your license key on hand just in case.

Conclusion

The ESXi Import Wizard turns what used to be a multi-tool, multi-hour manual conversion process into a guided GUI flow: add the host as storage, pick a VM, review the resulting config, and import. The mechanics are genuinely simple. What takes actual care is everything around the edges — consolidating snapshots beforehand, picking VirtIO drivers correctly, matching BIOS/UEFI mode, and testing Live-Import before trusting it on something you can't afford to lose mid-copy.

Do the prep work in Step 1, keep concurrent imports to a handful at a time, and budget for a short round of driver and networking cleanup afterward, and moving a VMware ESXi environment onto Proxmox VE is a weekend project, not a re-architecture.

Vormox is an independent virtualization management platform built on Proxmox VE. Proxmox® and Proxmox VE® are trademarks of Proxmox Server Solutions GmbH. Vormox is not affiliated with, endorsed by, or sponsored by Proxmox.

How to Migrate VMs from VMware ESXi to Proxmox VE Using the Import Wizard