Proxmox VE version: 9.2 | Proxmox Datacenter Manager: 1.1 | VMware: Generic (ESXi/vSphere)
This post is a companion reference to the video. Post corrections or additions below.
If you are looking for my other Proxmox tutorials you can find that here: Proxmox - YouTube
Why This Guide Exists
Broadcom’s acquisition of VMware changed the economics of virtualization overnight. Perpetual licenses are gone, pricing moved to subscription bundles, and a lot of shops that were happy running vSphere for years are now evaluating their options. Proxmox VE is the destination a large chunk of that crowd is landing on, and for good reason: it is fully open source, it has a deep feature set, and the recent 9.x releases have closed most of the gaps people used to point at. Making the jump means learning a new set of terminology. Some of it is just different names for the same thing. Some of it is genuinely different behavior. This guide is the translation layer so you are not starting from scratch. I also have a Proxmox VS XCP-ng 2026 Comparison
If XCP-ng is also on your shortlist, I put together the same kind of reference for it here: VMware to XCP-ng: Terminology & Feature Mapping Reference. Between the two you can line up how each open-source option maps back to the VMware concepts you already know.
Management Tools
Docs: Proxmox VE Administration Guide | Proxmox Datacenter Manager
| VMware | Proxmox Equivalent | Same or Different? |
|---|---|---|
| vCenter Server | Built-in web UI + cluster (single cluster) / Proxmox Datacenter Manager (multi-cluster) | Different approach |
| vSphere Client (web UI) | Proxmox VE web UI (on every node) | Different |
| ESXi Host Client | Same web UI, any node | Different |
| PowerCLI | qm / pct / pvesh / pvecm / pvesm CLI + REST API | Different |
vCenter vs. how Proxmox manages a cluster: This is the biggest conceptual shift, and it is the opposite of what VMware people expect. In VMware, vCenter is a separate licensed product you bolt on to manage ESXi hosts. In Proxmox there is no separate management product for a single cluster. The full management web UI ships on every node, and nodes join together into a cluster (peer-to-peer via corosync). You log into any node and manage the whole cluster from there. Nothing extra to license, nothing extra to run.
Where Proxmox Datacenter Manager (PDM) fits: When you grow past a single cluster, into multiple clusters or multiple sites, PDM is the new aggregation layer. It links all your PVE clusters, nodes, and Proxmox Backup Server instances into one interface, handles live migration between independent clusters, rolls out updates centrally, configures EVPN across remotes, and adds role-based access control. PDM is the closest thing to vCenter’s “single pane across everything” role, but it sits on top of independent clusters rather than being a required controller. It is open source (AGPLv3), and there is no separate subscription key for it: access to updates and support is bundled with the enterprise support you already have on the managed products. As of this post PDM is at 1.1.
CLI: There is no PowerCLI, but the native tooling is straightforward. qm manages VMs, pct manages LXC containers, pvesm manages storage, pvecm manages the cluster, and pvesh is a shell into the REST API. Everything in the UI is backed by that same API, so Terraform, Ansible, and packer workflows all work against it.
Licensing
| VMware | Proxmox | Notes |
|---|---|---|
| vSphere Essentials / Standard / Enterprise Plus | Proxmox VE (free, open source, AGPLv3) | Fundamentally different model |
| vCenter license | None required (built in); PDM is free | No separate management license |
| vSAN license | Ceph (free, built in) | See storage section |
| NSX license | SDN stack (free, built in) | See networking section |
| Per-socket / per-core licensing | Optional enterprise subscription, per CPU | Buys the stable repo + support, not the right to run |
This is the part that trips up people coming from VMware’s licensing world. Proxmox VE is AGPLv3 and free to run on as many hosts and CPUs as you want. The subscriptio does not “license” the software. It buys access to the enterprise (stable) package repository and Proxmox support. You can run the free no-subscription repo in production. Plenty of shops do, and plenty of shops buy the subscription for the tested-update channel and the support relationship. Either way there is no per-VM, per-core, or per-socket entitlement gate on features. You get the whole feature set regardless.
PDM follows the same logic: free software, and if you already pay for enterprise support on the clusters it manages, you get PDM updates and support included.
Compute / VM Concepts
Docs: Qemu/KVM Virtual Machines | Linux Container (LXC)
| VMware | Proxmox | Same or Different? |
|---|---|---|
| Virtual Machine (VM) | Virtual Machine (KVM/QEMU) | Same |
| vCPU | vCPU | Same |
| (no equivalent) | LXC Container | no VMware analog |
| Memory ballooning | Memory ballooning (KVM balloon driver) | Same |
| VMware Tools | QEMU Guest Agent | Same role, different name |
| OVA/OVF | Native ESXi import wizard / qm import | Different approach |
QEMU Guest Agent: Install the qemu-guest-agent package inside the guest and enable the agent toggle in the VM options. Without it you lose clean shutdown, IP address visibility in the UI, and the filesystem freeze that makes snapshots and backups consistent. Do not skip this.
LXC containers: Proxmox runs two kinds of guest from the same UI. Full KVM/QEMU virtual machines, and LXC system containers. Containers share the host kernel and are dramatically lighter than a full VM, which is great for a lot of Linux workloads where you do not need a separate kernel. There is no VMware equivalent to this, so it is a genuine “you gain something new” rather than a translation. Note that containers do not live-migrate the way full VMs do (they restart-migrate), so plan accordingly for HA workloads. I dive deeper into this topic here.
Migrating from VMware: Proxmox VE has a built-in ESXi import wizard. You add your ESXi or vCenter endpoint as a storage source, browse the VMs, and import them directly, disks and config, without manually exporting OVFs and converting VMDKs by hand. The usual prep applies on the VMware side: uninstall VMware Tools before or right after the move, install the QEMU guest agent after, and check NIC and disk controller types (VirtIO gives the best performance but may need driver prep for Windows). For Windows guests, having the VirtIO drivers ready before you switch the disk/NIC models to VirtIO saves a headache.
CPU types and 9.2 custom models: VM CPU type matters for live migration across mixed hardware (see the HA section). Proxmox VE 9.2 added a dedicated management interface for custom CPU models under the Datacenter section, plus a CPU flags selector that shows supported flags across all cluster nodes so you can spot cluster-wide compatibility problems before they bite you mid-migration.
Storage
| VMware | Proxmox | Thin Provisioned | Shared | Notes |
|---|---|---|---|---|
| Datastore | Storage (defined in Datacenter) | Depends on type | Depends on type | Same idea, different model |
| VMFS datastore (local) | LVM-Thin | Yes | No | Recommended local block |
| VMFS datastore (local) | Directory (qcow2 on ext4/xfs) | Yes | No | Most flexible local |
| VMFS datastore (local) | ZFS | Yes | No (use replication) | First-class, snapshots + send/recv |
| NFS datastore | NFS | Depends on format | Yes | Common shared option |
| iSCSI datastore | iSCSI + LVM | No (LVM is thick) | Yes | Block shared |
| vSAN | Ceph (RBD / CephFS) | Yes | Yes | Built in, free |
| RDM | Disk passthrough (qm set … /dev/disk/by-id/) | N/A | Depends | Similar concept |
| Storage vMotion | Move disk / storage migration | N/A | N/A | Same capability |
Storage model: Proxmox does not have a single monolithic “datastore” concept. You define storage backends at the Datacenter level, each with a type (LVM, LVM-Thin, ZFS, Directory, NFS, CIFS, Ceph RBD, CephFS, and so on) and a set of allowed content types (VM disks, container volumes, ISOs, backups, templates). A single backend can be scoped to specific nodes or shared across the cluster. The mental model is “what kind of storage is this, what can it hold, and who can see it,” rather than VMware’s one-format-fits-all datastore.
Thin vs. thick depends on the backend, not the disk: Like XCP-ng and unlike VMware, provisioning behavior is mostly a property of the storage type. LVM-Thin, ZFS, Ceph RBD, and qcow2-on-Directory are thin and support snapshots. Plain LVM and raw-on-block are thick and do not snapshot at the storage layer. Pick the backend with the behavior you want.
ZFS is a first-class citizen: Local ZFS gives you native snapshots, checksumming, compression, and built-in asynchronous replication between nodes. That replication is worth calling out, there is no direct VMware analog. You can schedule a VM’s disks to replicate to another node every few minutes, which gives you a cheap warm-standby / fast-failover story without shared storage and without Ceph. Great for two- and three-node setups. I have a deeper dive into that here
Ceph is the vSAN answer, and it is free: Proxmox has hyperconverged storage built directly into the platform via Ceph. It pools local disks across nodes into a replicated, self-healing cluster, managed from the same web UI, no separate license and no add-on purchase. This is the single biggest storage difference from VMware, where vSAN is a paid license, and it is also the biggest difference from XCP-ng, where the equivalent (XOSTOR) is a paid Vates add-on. Practical notes: plan for a minimum of three identical nodes (five recommended for production) , give Ceph its own fast network (ideally 10GbE or better, separated from VM traffic), and use enterprise/data-center SSDs with power-loss protection. Consumer SSDs will make you hate Ceph. Proxmox VE 9.2 ships Ceph Squid 19.2 and adds Ceph Tentacle 20.2 as a stable option. Check out their docs and consider carefully
Disk formats: qcow2 (thin, snapshots, on Directory storage), raw (best raw performance, snapshots handled by the storage layer on ZFS/Ceph/LVM-Thin), and vmdk (mainly for import). On block backends like LVM-Thin, ZFS, and Ceph, snapshots happen at the storage layer rather than inside the disk file.
Networking
Docs: Network Configuration | SDN | Firewall
| VMware | Proxmox | Same or Different? |
|---|---|---|
| vSwitch (vSS) | Linux bridge (vmbr0, etc.) | Different tech, similar role |
| Distributed vSwitch (vDS) | SDN (zones / VNets, cluster-wide) | Closest analog |
| Port Group | Bridge / VLAN-aware bridge / VNet | Same concept, different name |
| Uplink / vmnic | Physical NIC bridged into a vmbr | Similar |
| NIC Teaming / bonding | Linux bond | Same concept |
| VLAN Tagging | VLAN-aware bridge / tagged interfaces | Same concept |
| VMkernel adapter (vmk) | Node management interface / IP on a bridge | Similar |
| NSX | SDN (VXLAN/EVPN) + built-in firewall | Partial analog, see below |
Default networking is Linux bridges: Out of the box, Proxmox uses a Linux bridge (vmbr0) the way VMware uses a standard vSwitch. Make it VLAN-aware and you can hand VMs tagged VLANs by just setting a VLAN tag on the VM’s NIC. Your upstream switch port still needs to be a trunk. Bonding for redundancy and aggregation is standard Linux bonding (active-backup, LACP, balance modes).
The vDS gap, and how SDN closes it: Classic Proxmox networking is configured per node, so for live migration to work, the bridge names have to match across nodes. That is the part that feels a step behind vDS. The SDN stack is the answer. SDN configuration is cluster-wide and pushed to every node automatically, which is the vDS-style “configure once, applies everywhere” behavior. SDN gives you zones and VNets, simple VLAN zones up to full VXLAN/EVPN overlays with distributed routing.
9.2 SDN additions: This release pushed the SDN stack hard. Native WireGuard and BGP fabric protocols are now in the SDN stack, BGP/EVPN gained route maps and prefix lists for fine-grained route control, there is OSPF route redistribution, more EVPN controller options, and IPv6 underlay support for EVPN. If you were eyeing Proxmox for anything beyond flat L2, the networking story is a lot more serious than it was a couple of releases ago.
The NSX comparison is more favorable than you might expect: Proxmox ships a built-in, stateful firewall that works at the datacenter, node, and individual VM/NIC level, with security groups and IP sets. Combined with SDN VXLAN/EVPN overlays, that covers real micro-segmentation and isolated tenant networks. It is not NSX, there is no L7 application-aware policy, no built-in load balancing, no NSX-scale distributed services, but the combination of a real stateful firewall plus overlay networking, both free and built in, is genuinely more than the basic per-VIF filtering you get on some other open-source hypervisors.
High Availability, Clustering & Live Migration
Docs: Cluster Manager | High Availability
| VMware | Proxmox | Same or Different? |
|---|---|---|
| vSphere Cluster | Cluster (corosync) | Similar concept, different name |
| vMotion | Live Migration | Same capability |
| Storage vMotion | Storage Migration / Move disk | Same capability |
| vSphere HA | Proxmox HA (ha-manager) | Similar, different implementation |
| DRS | Dynamic Load Balancer (CRS dynamic mode, new in 9.2) | Now a real analog |
| Fault Tolerance (FT) | No equivalent | N/A |
| EVC | CPU type baseline / custom CPU models (9.2) | Similar outcome, manual |
Cluster: A group of nodes managed together is a cluster, coordinated by corosync. There is no dedicated “master” node the way VMware has vCenter or XCP-ng has a pool coordinator. It is a quorum-based peer cluster: as long as a majority of nodes can see each other, the cluster operates. The practical catch is two-node clusters, where you have no natural majority if one node drops. The fix is a QDevice (a lightweight external vote, even a small VM or Pi can serve), or just run an odd number of nodes. I don’t recommend this setup for production system, but good for learning.
Live Migration: This is vMotion. Move running VMs between nodes with no downtime. With shared storage (Ceph, NFS, iSCSI) it is a memory-only move and very fast. Without shared storage, Proxmox can do storage migration too, copying the disk as part of the move. Works well.
Proxmox HA (ha-manager): Mark a VM or container as an HA resource and the cluster will restart it on a surviving node if its node fails. Requires shared storage. Fencing via watchdog ensures a failed node is truly out before its VMs restart elsewhere.
Confident maintenance with HA Arm/Disarm (new in 9.2): One of the long-standing annoyances was doing planned maintenance on an HA-enabled cluster without the HA stack overreacting and fencing a node you were intentionally working on. 9.2 adds a cluster-wide HA “disarm” and “arm.” You disarm before maintenance to suspend HA actions, do your work, then arm again, and resource states and placement are preserved across the cycle. This is the analog to easing into VMware maintenance mode without drama.
DRS, finally (Dynamic Load Balancer, new in 9.2): This used to be the honest weak spot, Proxmox had no real DRS. 9.2 changes that. The cluster resource scheduler now has a dynamic mode that factors real-time node and guest resource utilization into placement, and the integrated load balancer can automatically migrate HA-managed guests to reduce imbalance across the cluster, while respecting your HA rules. There are tunable parameters to control how aggressive and how sensitive it is. It is newer and less battle-tested than DRS has decades of being, so ease into the automation, but the capability is now genuinely there rather than “do it by hand.”
CPU compatibility for live migration: VMware’s EVC sets a CPU baseline across hosts. In Proxmox you handle this by setting the VM’s CPU type to a common baseline (for example x86-64-v2-AES, or kvm64 for maximum compatibility) so a VM can migrate across nodes with dissimilar CPUs. 9.2’s new custom CPU model management and the cluster-wide CPU flags selector make it easier to define a safe baseline and catch mismatches before they cause a failed migration. It is more manual than EVC, but more flexible once set up.
Snapshots & Backup
Docs: Backup and Restore | Proxmox Backup Server
| VMware | Proxmox | Same or Different? |
|---|---|---|
| VM Snapshot | VM/Container Snapshot | Same concept, storage-dependent |
| Snapshot consolidation | Handled by the storage layer | Different mechanism |
| Changed Block Tracking (CBT) | QEMU dirty bitmaps | Same role, different name |
| vSphere Data Protection | Proxmox Backup Server (PBS) | Different product, similar capability |
| Veeam | Veeam (now supports Proxmox) + PBS | Ecosystem |
Snapshots: Conceptually the same, capture VM/container state at a point in time, but support depends on the storage backend. qcow2 (Directory), ZFS, Ceph RBD, and LVM-Thin all support snapshots. Plain LVM (thick) and raw-on-block do not. A caveat: Snapshots are non-portable across differing storage technologies. Because a ZFS snapshot relies on native zfs snapshot datasets and LVM-Thin relies on thin-pool metadata mappings, you cannot perform a storage migration on a VM that contains snapshots unless the source and target storage types are identical (e.g., ZFS to ZFS). To move a VM between differing storage backends, all existing snapshots must be deleted first.
CBT equivalent: Proxmox uses QEMU dirty bitmaps to track changed blocks, which is what makes incremental backups to PBS fast. Same purpose as VMware’s Changed Block Tracking.
Backup, two layers: Every Proxmox install has vzdump built in for full backups of VMs and containers to a local or shared target. The bigger story is Proxmox Backup Server (PBS), a separate free product that does incremental, deduplicated, compressed, and encrypted backups with verification, and uses dirty bitmaps for fast incrementals. For a many PBS fully replaces a third-party backup tool. If you were running Veeam Community Edition against VMware, PBS is the natural analog, and as of recent versions Veeam officially supports Proxmox too if you want to keep that ecosystem. I have a deeper dive on that here
Templates & Cloning
Docs: VM Templates and Clones | Cloud-Init Support
| VMware | Proxmox | Same or Different? |
|---|---|---|
| VM Template | Template (convert VM to template) | Same concept |
| Clone from Template | Clone (full or linked) | Same concept |
| Linked Clone | Linked Clone | Same mechanism |
| Content Library | No direct equivalent (shared storage for ISOs/templates) | Different |
| Customization Specification | cloud-init (built in) | Different, arguably cleaner |
Templates: Build a VM the way you want it, convert it to a template (it becomes read-only), and deploy clones from it. Full clones copy everything; linked clones share a base disk with the parent to save space, same tradeoffs as VMware linked clones.
No Content Library equivalent: VMware’s Content Library is a syncing repo of templates and ISOs across vCenter instances. Proxmox does not have a direct equivalent. ISOs and templates live on storage you designate for that content type, and you make them cluster-wide by putting them on shared storage (NFS/CIFS) so every node can reach them. For multi-site, this is where PDM and your storage design do the work the Content Library would have.
Guest customization with cloud-init: cloud-init support is built directly into the VM config, you set hostname, IP, SSH keys, and user data right in the UI or via the API, and the VM configures itself on first boot. For Linux this is cleaner than VMware’s Customization Specifications in a lot of workflows. For Windows, the equivalent path is cloudbase-init or sysprep with a first-boot script.
Quick Reference Cheat Sheet
| VMware Term | Proxmox Term |
|---|---|
| ESXi Host | Proxmox VE Node |
| vCenter | Built-in cluster UI (single cluster) / Proxmox Datacenter Manager (multi-cluster) |
| Cluster | Cluster (corosync) |
| Datastore | Storage |
| Port Group | Bridge / VNet |
| vmnic / uplink | Physical NIC bridged into a vmbr |
| vMotion | Live Migration |
| Storage vMotion | Storage Migration / Move disk |
| vSphere HA | Proxmox HA (ha-manager) |
| DRS | Dynamic Load Balancer (CRS dynamic mode, 9.2) |
| Fault Tolerance | (No equivalent) |
| EVC | CPU type baseline / custom CPU models |
| VMware Tools | QEMU Guest Agent |
| VMDK | qcow2 (thin) / raw |
| OVA/OVF | ESXi import wizard / qm import |
| Snapshot Consolidation | Handled by storage layer |
| Changed Block Tracking | QEMU dirty bitmaps |
| Template | Template |
| Linked Clone | Linked Clone |
| vSwitch (vSS) | Linux bridge (vmbr) |
| vDS | SDN (zones / VNets) |
| vSAN | Ceph (built in, free) |
| NSX | SDN (VXLAN/EVPN) + built-in firewall |
| Customization Specification | cloud-init |
| PowerCLI | qm / pct / pvesh / pvecm CLI + REST API |
| (no equivalent) | LXC Container |
What’s Different (Honest Assessment)
Proxmox VE is not a feature-for-feature clone of a full vSphere Enterprise Plus stack. Here is what you are actually giving up or trading:
- Fault Tolerance: There is no lockstep, zero-downtime FT equivalent that keeps a shadow VM running in real time. HA restart-on-failure is what you get. For the vast majority of workloads that is fine, but if you genuinely relied on FT, note the gap.
- DRS maturity: The 9.2 Dynamic Load Balancer is real and welcome, but it is new. VMware’s DRS has many years of tuning behind it. Turn the automation up gradually and watch how it behaves in your environment first.
- Content Library: No direct equivalent. ISO and template distribution is solved with shared storage and, at scale, PDM, but it is a different workflow.
- Single-pane-at-huge-scale: PDM is the multi-cluster answer and it is good, but it is young (1.1). If your expectation is the depth of a long-matured vCenter Linked Mode across dozens of sites on day one, calibrate accordingly. It is improving fast.
- Third-party ecosystem: VMware’s ecosystem for backup, monitoring, and ops tooling is broader and more mature, though the gap keeps closing (Veeam supporting Proxmox is a good example).
- Ceph is not free of cost in effort: The software is free, but Ceph wants real hardware (fast dedicated network, enterprise SSDs, three-plus nodes). Done right it is excellent. Done on consumer drives and a 1GbE link, it will disappoint.
What You Gain
- No hypervisor licensing at all, and an optional support subscription instead of a per-core entitlement gate
- LXC containers alongside full VMs, from the same UI, something VMware simply does not do
- Ceph hyperconverged storage built in and free, where vSAN is a paid license
- ZFS as a first-class citizen, with built-in asynchronous replication for cheap warm-standby
- Proxmox Backup Server built in and free: deduplicated, incremental, encrypted, verified backups
- A built-in stateful firewall plus SDN overlays (VXLAN/EVPN, and now WireGuard/BGP in 9.2) for real segmentation without an NSX license
- A real DRS-style dynamic load balancer and cleaner HA maintenance controls as of 9.2
- A built-in ESXi import wizard that pulls VMs straight off your existing vCenter/ESXi
- Proxmox Datacenter Manager for multi-cluster and multi-site, included with existing enterprise support
- AGPLv3 open source, a very large community, and a platform reported to power over two million hosts, so you are not beholden to a vendor’s next acquisition decision
This reference may be updated as Proxmox VE, PBS, and PDM evolve. Post corrections or additions below.