Moving a VM off VMware and onto Proxmox VE is mostly an exercise in two things: getting the virtual disk across, and convincing the guest OS to boot on slightly different virtual hardware. Neither is hard once you know where the snags are, and the snags are predictable.
This guide walks the manual route — export the VM as OVF and VMDK, import it with qm importovf or qm importdisk, and sort out the disk controller and drivers so it boots. It also points out where the newer built-in import wizard saves you steps. The commands target Proxmox VE 8.x.
Before anything else: power the source VM off for the actual disk copy. A VMDK copied from a running machine is inconsistent, and you’ll spend longer chasing filesystem corruption than the downtime would have cost.
Plan the cutover first
Migration is a sequence of small changes, and a couple of them are easy to forget until the VM won’t boot. Note these from the VMware side before you touch anything.
Before you migrate
- Source VM firmware: BIOS or EFI (you'll match it in Proxmox)
- Disk size and how many disks the VM has
- OS type and version (drives the VirtIO driver choice)
- Static IP, gateway, DNS, and the interface name if Linux
- VMware Tools uninstalled from inside the guest
- A Proxmox host with storage and a target VMID ready
The firmware setting catches people most often. If the VMware VM boots in EFI mode and you build the Proxmox VM with the default SeaBIOS, the disk imports cleanly and then sits at a black screen because there’s no bootloader where the firmware expects one. Match the firmware and that whole class of problem disappears.
Step 1: Export the VM from VMware
Power the VM off, then export it. The cleanest output is OVF, which gives you a small .ovf descriptor file plus one .vmdk per disk.
From vSphere/ESXi you can export through the client (File → Export → Export OVF Template), or use VMware’s ovftool from the command line:
# export VM "web01" from an ESXi host to a local folder
ovftool "vi://root@esxi-host/web01" /export/web01/If you only have the datastore files, you really just need the -flat.vmdk (the data) and its descriptor .vmdk. Copy both. Either way, get the files onto the Proxmox host — scp to a directory you can reach, for example /var/lib/vz/import/.
Step 2: Import the disk into Proxmox
You have two ways in, depending on what you exported.
If you have the full .ovf, qm importovf reads the descriptor and builds a VM definition with the right disk size and basic hardware in one shot:
# create VM 200 from an OVF, putting disks on local-lvm storage
qm importovf 200 /var/lib/vz/import/web01/web01.ovf local-lvmIf you only have a lone .vmdk, first create an empty VM in the GUI (set the OS type, memory, CPU, and firmware), note its VMID, then attach the disk with qm importdisk:
# import a standalone VMDK into existing VM 200, onto local-lvm
qm importdisk 200 /var/lib/vz/import/web01/web01-disk1.vmdk local-lvmimportdisk converts the VMDK into whatever format the target storage uses — a raw volume on LVM-Thin or ZFS, or qcow2 on a directory store. After it finishes, the disk shows up in the VM’s Hardware tab as an Unused Disk. You attach it in the next step.
If you’re unsure which storage format to import onto, the trade-offs between raw-on-LVM and qcow2-on-directory are covered in Proxmox LVM vs LVM-Thin vs ZFS.
Step 3: Attach the disk and set the controller
Open the VM’s Hardware tab. The imported disk is listed as Unused Disk 0. Double-click it to attach it, and here’s the decision that makes or breaks the first boot.
Disk controller choice at first boot
| SATA or IDE | Universally bootable. Windows and Linux both have built-in drivers, so the migrated guest boots without any prep. Slower, but it gets you in the door. |
|---|---|
| VirtIO SCSI | The fast paravirtualized controller you want long-term. Needs the VirtIO driver present in the guest first, or Windows bluescreens on boot. |
For the first boot, attach the disk as SATA (or IDE). Get the VM running on hardware the guest already understands, install the VirtIO drivers from inside it, then switch the controller to VirtIO SCSI and reboot. Trying to go straight to VirtIO is the number-one cause of a migrated VM that imports perfectly and then refuses to boot.
Step 4: Install VirtIO drivers (especially on Windows)
VirtIO is what makes disk and network I/O fast on Proxmox, but Windows ships with no VirtIO drivers, so you add them.
Download the virtio-win driver ISO (the signed builds are published by Fedora’s virtio-win project), upload it to Proxmox storage, and attach it as a second CD/DVD drive on the VM. Then:
- Boot the VM with the disk on SATA so Windows comes up normally.
- Open Device Manager — you’ll see unknown devices for the VirtIO hardware.
- Install the drivers from the virtio-win ISO, or run the included
virtio-win-guest-toolsinstaller, which also installs the QEMU guest agent. - Shut the VM down.
- In Hardware, detach the SATA disk and re-add it as VirtIO SCSI. Set the SCSI Controller to VirtIO SCSI single.
- Boot again. Windows now has the driver and comes up on the fast controller.
Linux guests are easier. Most modern distributions include VirtIO drivers in the kernel already, so they boot on VirtIO SCSI straight away. The thing to watch on Linux is the network interface name (covered next).
Step 5: Fix boot and network after migration
A few post-import items separate “it boots” from “it works.”
Firmware (BIOS/UEFI). In the VM’s Options → BIOS, match the source. EFI guests need OVMF (UEFI) plus an EFI disk added under Hardware; BIOS guests stay on the default SeaBIOS. Get this wrong and you’ll see a UEFI shell prompt or a no-bootable-device message.
Boot order. After attaching the real disk, check Options → Boot Order so the VirtIO/SATA disk is enabled and first. An imported disk that isn’t ticked in the boot order won’t be booted from.
Network interface. The virtual NIC is new hardware, so the guest renames or re-detects it:
# Linux: check what the interface is actually called now
ip a
# the old static config may reference an interface name that no longer exists,
# e.g. /etc/network/interfaces or a netplan/NetworkManager file pointing at "ens160"
# update it to the new name (often "ens18" on Proxmox) and restart networkingOn Windows, the migrated adapter appears as a new connection, so reassign the static IP, gateway, and DNS if it doesn’t pull them automatically. This is why noting the old network settings before you start saves a trip to the console.
Post-migration checklist
Once the VM boots and reaches the network, close out the migration properly so you’re not living with half-removed VMware bits.
After the VM boots on Proxmox
- VMware Tools fully removed from the guest
- VirtIO disk and network drivers installed (Windows)
- QEMU guest agent installed and enabled in VM Options
- Disk switched to VirtIO SCSI and booting cleanly
- Network reachable with the correct static IP and DNS
- A first backup taken before you decommission the VMware copy
That last item matters: take a Proxmox backup of the migrated VM before you delete it from VMware. Keep the source VM powered off but intact for a few days as a rollback until you’re confident the migrated one is solid.
If you’re weighing the platforms more broadly while you plan a fleet-wide move, Proxmox VE vs VMware ESXi lays out where each fits. And if the Proxmox host itself is still being built, start with installing Proxmox VE on bare metal. For more walkthroughs, browse the Proxmox guides.
