Since Broadcom reshaped VMware’s catalogue and pricing, the question stopped being whether to look at alternatives and became how much it costs to move. Proxmox VE is the one most people run into along the way, and the migration deserves telling without decoration: it can be done, there is a sensible way to do it, and there is a list of things that bite if you ignore them.
What Proxmox is, and what it is not
Proxmox VE is Debian with KVM and QEMU underneath, LXC containers alongside, and a web interface and an API that bring both together in a cluster. It is not a vSphere clone: it shares the concepts — cluster, high availability, live migration, shared storage — but neither the architecture nor the tooling.
What you get out of the box, with no per-socket licences or mandatory subscription:
- A corosync cluster, with automatic restart of the VMs from a failed node and fencing of the problem node.
- Integrated storage: Ceph spread across the compute nodes themselves, or local ZFS for latency-sensitive workloads, with snapshots and checksums.
- Backups with Proxmox Backup Server: incremental, deduplicated and encrypted.
What you do not get: vSphere’s ecosystem of certified integrations, the same load-balancing behaviour, and the partner network you may be used to. That is not a flaw in the product, it is the price of changing platform.
The migration, in phases
The people at Cloud Privado run these migrations on a four-phase scheme that matches what works in practice:
- Inventory. Before touching anything, know what is there: machines, dependencies between them, who talks to whom, which arrays and which networks. It is the phase most often skipped and the most expensive one to skip.
- Pilot. A small, non-critical batch, measured seriously: real performance, not impressions.
- Batches. Move in groups with the old environment still standing. Rolling back is still possible here.
- Final cutover. The only phase with no way back, which is why you only enter it once the previous three are verified.
With the machine powered off, the move is measured in minutes per VM; with disks replicated beforehand, a batch’s cutover window usually stays under two hours. Databases are the exception: there you keep logical replication running until the cutover, rather than copying a disk and crossing your fingers.
The details that bite
- VirtIO drivers on Windows, before moving. If the VM reaches Proxmox without them it will boot — slowly, on emulated disk and network — and look like it “works”. It is mechanical, but it gets forgotten.
- Remove VMware Tools before or right after. They coexist badly with the new agents.
- UEFI and secure boot: check each VM’s firmware and EFI disk. It is one checkbox, and it is the checkbox that leaves a machine unable to boot.
- Networks and VLANs: port group names do not travel on their own. You have to reproduce the map, and it is worth doing before the pilot.
- Storage: decide Ceph or ZFS before moving, not after. Changing your mind with 200 VMs on top is a different project.
What if Proxmox is not the answer?
It is not always. If you come from XenServer, XCP-ng will feel more familiar. If your thing is orchestrating hundreds of VMs on a cloud model, OpenNebula has its own migration path from VMware. And if the destination is Kubernetes, perhaps the debate is not which hypervisor but how many of those VMs should still be VMs.
To understand what sits underneath all these options, the Linux virtualisation stack — KVM, QEMU and libvirt explains who does what; nearly everything else is management layers on top.
Where to go next
- Cloud Privado’s platform comparison, to put Proxmox, VMware and Nutanix in the same table.
- Their analysis of why Broadcom is preparing a new vSphere Standard, which explains a good deal of the current moment.
- And if networking is what worries you, how firewall and NAT rules are actually written in Proxmox.
On where to run it: Proxmox works just as well on your own iron as on bare metal servers or a managed private cloud, which is the usual route when you do not want to maintain the hardware yourself but do not want to share a machine with anyone either.
The Proxmox VE and ESXi entries carry their versions and end-of-support dates, worth checking before planning any cutover: migrating to a version that expires in six months is starting out in debt.
The author of this article is a co-founder of Stackscale, which appears among the links. Said here so you know while reading, not in the small print.