Migrating from VMware ESXi to Proxmox VE: What I Learned

I spent four years running VMware ESXi on a pair of Dell PowerEdge boxes in my garage. Paid for vSphere licensing, managed vCenter, the whole enterprise song and dance. Last spring, I tore it all down and rebuilt on Proxmox VE. This isn’t a “why open source is better” essay. It’s what actually changed when I migrated from VMware ESXi to Proxmox VE, why I did it, and what I genuinely miss about the old setup.

Why I Left ESXi in the First Place

The licensing model broke first. A single vSphere license runs $500+ per year per socket. I had two sockets per node, times two nodes. Do the math. For a homelab running maybe five VMs and a handful of containers, that’s real money I was spending to check “it’s the same stack as production.” That justification wore thin around year three.

The second reason was slower. VMware’s pace of innovation felt glacial compared to what was happening in the open-source virtualization space. Proxmox had already shipped native LXC container support. They had ZFS integration that wasn’t bolted on like an afterthought. ESXi still wanted me to wrestle vSAN for shared storage, or buy expensive NetApp gear, or use some Byzantine iSCSI setup.

Then came the announcement that vSphere licensing was changing again. Fewer features in the base tier. More upselling. I’d been dreading the next renewal email anyway. That email was the final push. I set a migration window for the spring and started reading Proxmox documentation.

The Physical Migration: What Stayed the Same

Here’s what surprised me: the hardware didn’t change at all. Both ESXi and Proxmox are thin hypervisors that sit directly on the metal. My two Dell PowerEdges with dual Xeons, 256GB RAM each, and direct-attached NVMe—all perfectly compatible. The only hardware prerequisite was making sure IOMMU and virtualization extensions were enabled in BIOS. They already were from the ESXi days.

I built Proxmox on a separate pair of NVMe drives while leaving ESXi intact. Spent two days verifying that every VM could be imported. This is where the process got interesting. VMware VMs are portable, but not *that* portable. You can’t just drop a VMDK file into Proxmox and boot it. You have to convert them.

I used qemu-img to convert VMDK to QCOW2 format. Each VM conversion took about thirty minutes per 100GB of data, running sequentially because my storage controller was already under load. For four VMs, that’s a couple hours of wall-clock time.

qemu-img convert -f vmdk -O qcow2 /mnt/vmware/vm01.vmdk /var/lib/vz/images/vm01.qcow2

Once converted, I created new VMs in Proxmox and attached the qcow2 disks as existing volumes. Powered them on. They booted. Linux and Windows machines both came up without issues. Network configuration persisted. No grief there, which I appreciated.

Storage: Where the Real Divergence Happened

On ESXi, I was running VMFS datastores across a pair of SAS SSDs in RAID 1. Reliable, boring, worked for years without surprising me. On Proxmox, I moved to ZFS. This was the biggest philosophical shift between the two platforms.

ZFS is not RAID. I mean, it is, but it’s not only that. It’s a storage system with built-in integrity checking, snapshot management, and compression all integrated at the filesystem layer. ESXi’s storage layer felt like it was bolted on from 1997. Proxmox’s storage story felt modern.

Setting up ZFS pools for VM storage was straightforward. I created a zpool across the two SSDs in mirror config (equivalent to RAID 1), then created datasets for each VM. The syntax is unfamiliar if you’re coming from traditional LVM, but it’s not hard:

zpool create -f -o ashift=12 tank mirror /dev/sda /dev/sdb
zfs create tank/vms
zfs set compression=lz4 tank/vms

What I didn’t expect was how much I’d use snapshots. On ESXi, I had never touched the snapshot feature. On Proxmox, I’m snapping VMs before any change, then deleting them after verification. The built-in snapshot-to-disk API made it trivial to automate. It’s not revolutionary, but it’s the kind of feature that you use constantly once it’s frictionless.

One surprise that wasn’t pleasant: ZFS has a learning curve around IOPS and latency if you don’t tune it. My first week, I had VM performance that was noticeably worse than ESXi. Turns out I hadn’t tuned the ARC cache settings, and I was using the wrong compression algorithm for my workload. A couple of sysctl tweaks later, performance exceeded what I had before. But that tuning cost me an evening of troubleshooting and reading Jepsen reports about ZFS behavior under load.

Clustering and Management: Less Polish, More Flexibility

ESXi’s vCenter is a polished, mature management platform. You point vSphere Client at vCenter, you see all your hosts, all your VMs, all your alerts, everything in a unified GUI. It’s not pretty, but it’s complete. Proxmox’s web UI is also complete, but it’s simpler. Intentionally simpler.

Setting up a two-node Proxmox cluster was five minutes: generate a key on node one, feed it to node two, they talk to each other and sync the cluster state. No additional services to manage. No vCenter appliance to maintain. The trade-off is that the UI is less feature-dense, and if you want to do anything beyond the UI, you’re reading API documentation and writing curl commands.

Clustering on ESXi had the same concept, but vCenter was a separate VM you had to maintain, patch, and backup. I’d upgraded vCenter twice during my four years running ESXi. One of those upgrades broke something with SSL certificates. The Proxmox equivalent? It’s built in, no separate service, no upgrades beyond the host OS itself.

The VM migration between nodes is where I felt the lack of polish. ESXi does vMotion, which is slick: you can live-migrate a running VM from one host to another without downtime. Proxmox can do this with KVM VMs (vMotion equivalent), but it’s less automatic. You’re managing it through the UI or the API explicitly. For my use case—migrating VMs maybe once a year during maintenance—it doesn’t matter. But if I were running a larger environment with more churn, the slickness of vMotion would be noticeable.

Containers: Where Proxmox Pulled Ahead

ESXi doesn’t do containers natively. If you wanted LXC or Docker, you spun up a Linux VM and ran them inside. It worked, but it was an extra layer of abstraction. Proxmox has first-class LXC container support built in. You create a container, it runs directly on the host, dramatically lower overhead than a full VM.

This changed how I architect my lab. I used to run three VMs: one for Docker, one for databases, one for my home automation stack. On Proxmox, I run those three as LXC containers plus one GPU-accelerated KVM VM for Ollama. The containers spin up in seconds instead of minutes. Resource overhead is measurable—we’re talking 100MB per container versus 2GB per VM.

The GPU passthrough support is what made the migration worth it for me, specifically. I have an RTX 4060 I wanted to dedicate to Ollama and local LLM inference. On ESXi, passthrough is possible but it’s finnicky. Proxmox has a straightforward process: disable the IOMMU groups you don’t want, pass the GPU to the VM, enable IOMMU in the guest kernel. I had Ollama running on a dedicated VM with full GPU access in about an hour. On ESXi, I’d have spent a day troubleshooting driver issues and reset quirks.

What I Actually Miss About VMware

I should be honest about this. There are things about ESXi I genuinely preferred.

The first is the web client experience. vSphere Web Client is verbose and slow, but every feature is discoverable. It’s consistent. Proxmox’s UI is faster and cleaner, but it assumes you know what you’re looking for. If you’re new to the platform, some workflows are opaque. I spent twenty minutes the other day trying to find where to expand storage on a container. It was in the Resources tab under a dropdown. On vSphere, there would be a button labeled “Expand Storage” and a wizard.

The second is documentation. VMware’s documentation is encyclopedic and obsessively detailed. Proxmox’s is good, but it’s smaller. If you hit an edge case, there’s a good chance your answer is on a forum post from 2019 or you’re reading source code. I’ve had to do both.

Third—and this is petty—alarms. ESXi alerts you to problems proactively. Storage degrades, a fan is failing, NTP is out of sync. Proxmox is more quiet. It tells you what’s happening, but it doesn’t nag. For a homelab, that’s actually preferable. For production systems, VMware’s chattiness was genuinely useful.

Performance and Reality Check

I can’t claim Proxmox is faster or slower than ESXi because both hit the hardware limits of my Dell PowerEdges at almost exactly the same point. When I’m maxing out CPU or RAM, both platforms are equally bottlenecked. What matters is what I can do with the resources, and that’s where Proxmox’s container support and simpler management actually freed up capacity I was wasting before.

Where performance got interesting: I was able to run my entire homelab on one of the two nodes for maintenance windows. On ESXi, doing that would have been sketchy with vMotion working as hard as it could. On Proxmox, moving three containers and one VM took thirty seconds. No drama. That kind of operational simplicity doesn’t show up on a benchmark, but it’s why I’d make the switch again.

I won’t claim this was painless. The migration itself took three weekends, and I spent a few nights that first month fixing things I’d overlooked—like realizing my backup strategy was incompatible with Proxmox’s snapshot format and having to rewrite all my automation. But I’m six months in now, and I’m running fewer resources on hardware I already owned, with more operational simplicity than I had before. That feels like a win to me.

FAQ

Can I import my VMware ESXi VMs directly into Proxmox?

Not directly. You need to convert VMDK files to QCOW2 or raw format using qemu-img, then create new VMs in Proxmox and attach the converted disks. The process takes about 30 minutes per 100GB of storage, and the guest OS boots without issues once imported.

Is Proxmox VE free for homelab use?

Yes, completely free. There’s no licensing cost, no feature restrictions for non-commercial use. The enterprise subscription is optional and covers support and access to premium repositories.

Does Proxmox VE support GPU passthrough like VMware?

Yes, and it’s simpler than ESXi. You enable IOMMU in BIOS and the kernel, isolate the GPU using vfio drivers, and pass it to a VM. The process is documented straightforwardly, and it works well for dedicated GPU workloads like Ollama or local LLM inference.

What hardware do I need to run Proxmox VE?

Any x86-64 server or workstation with virtualization support (Intel VT-x or AMD-V). Minimum specs are a dual-core CPU, 4GB RAM, and 30GB storage, though you’ll want at least 32GB RAM for a useful homelab setup. It runs on repurposed enterprise hardware just fine.

Is Proxmox harder to manage than ESXi?

The learning curve is different, not necessarily steeper. ESXi’s web client is more feature-discoverable but slower. Proxmox’s UI is faster but requires more familiarity. Both are manageable; it depends whether you prefer visual navigation or reading documentation to find features.

Explore Proxmox VE in our AI Homelab Toolkit.