I've run ESXi at home for years. The free hypervisor was always a slightly awkward gift: a properly engineered platform, handed to hobbyists with most of the management lopped off, and a vSphere client you weren't really meant to have. After the Broadcom acquisition closed and the free ESXi licence quietly went away, the awkwardness stopped being charming. So I've spent the last two weekends moving everything to Proxmox VE, and this is the write-up I wish I'd had before I started.
The short version: it went well, Proxmox is a better fit for a homelab than ESXi ever was, and the only genuinely painful part was the bits where I'd let myself depend on VMware-specific behaviour.
Why bother
I could have stayed put. The existing install kept running; nobody was going to come and switch it off. But an unlicensed, unsupported, no-longer-distributed hypervisor is a slow-motion trap. The day a disk dies and I need to reinstall, the installer I need won't be a friendly download any more. Better to move while everything is healthy and I can take my time.
Proxmox also fits the way I actually work. It's Debian underneath, so when something breaks I'm in familiar territory with apt, systemd and plain logs rather than an appliance shell that hides everything. It does KVM and LXC containers in one interface, which matters because half my "VMs" were really just a service that wanted its own root filesystem and didn't need a full kernel. And ZFS is a first-class citizen, which is the feature that actually sold me.
The migration
I had one host and nowhere to live-migrate to, so the plan was: stand Proxmox up on a spare SSD, boot it alongside, move VMs across one at a time, then reclaim the old datastore.
For the Linux VMs this was almost boring. Export each one as OVF from ESXi, then qm importovf on the Proxmox side. The disks come in as the original format and you convert them on import:
qm importovf 101 mailserver.ovf local-zfs
qm set 101 --boot order=scsi0 --scsihw virtio-scsi-single
Two gotchas. First, the network device. ESXi guests are often on vmxnet3, and after import the interface name changes, so anything pinned to ens192 or similar comes up with no network. Easiest fix is to switch the VM to a VirtIO NIC and fix the interface name in the guest, or use predictable naming and a systemd-networkd match on MAC address so it stops mattering.
Second, the boot mode. A couple of my VMs were UEFI and I'd forgotten. If you import a UEFI guest as SeaBIOS it sits there refusing to boot and you stare at it wondering what you broke. Set the machine to OVMF and add an EFI disk:
qm set 101 --bios ovmf --efidisk0 local-zfs:1,format=raw
The one Windows VM was the only real fight. VirtIO drivers aren't in the stock Windows image, so the disk controller has to be SATA or IDE on first boot or Windows won't see its own disk. Boot it once like that, install the VirtIO guest tools from the ISO, then switch the controller to virtio-scsi and reboot. Faff, but well documented, and I only had to do it once.
What's better
ZFS on the host is the big one. I get snapshots, send/receive for backups, and compression without a separate storage appliance. zfs snapshot before any risky change, and rolling back is instant. Under ESXi I'd been using the free version's anaemic snapshot story and an external NAS for anything serious.
The web UI is also just... there, included, with no licensing dance. Console access works in the browser without a fat client. And LXC containers are a revelation for the small stuff. My Pi-hole, my reverse proxy and a couple of utility services are now containers that boot in under a second and use almost no memory, where before each was a whole VM pretending to be a whole computer.
Backups deserve a mention too. Proxmox Backup Server is a separate install, but it does deduplicated, incremental backups of both VMs and containers, and restoring a single file out of a backup actually works. I've got it running on the old NAS and it's quietly become the part I'd miss most.
What's worse, or at least different
It isn't all upside. ESXi's hardware compatibility is broader and its driver story for oddball NICs is better; Proxmox inherits Debian's, which is good but not infinite. If you have an exotic storage controller, check before you commit.
The defaults are also more "here are the tools, configure it yourself" than ESXi's. That suits me, but if you wanted an appliance that just works without reading anything, Proxmox will ask more of you. The first time you hit the subscription nag screen and the "no valid subscription" repository warning, you'll want to know that the no-subscription repo is a supported, normal way to run it at home, not a crack.
Was it worth it
Yes, easily. The hardware is the same, the VMs are the same, but the platform underneath is now something I own outright, understand, and can rebuild from a Debian install and a backup if it all falls over. The Broadcom situation forced my hand, but I should have done this years ago. The only thing I miss is the muscle memory, and that's fading fast.