What Proxmox VE provides
Proxmox VE is a Debian-based virtualization platform that runs KVM virtual machines and LXC containers, managed through a web interface, a REST API and command-line tools. It includes clustering, high availability, a built-in firewall, software-defined networking and support for local and shared storage, including integrated Ceph. The code is licensed under the GNU Affero General Public License, version 3.
Many organizations are reviewing their VMware estates after Broadcom changed VMware licensing and packaging, and Proxmox VE is one of the platforms they evaluate. A move works best as a platform design: cluster layout, storage, networking, backup and access control come before the first import.
Design the cluster around quorum
Proxmox VE clusters depend on Corosync for membership. Most cluster design work is about keeping quorum and fencing predictable.
| Decision | Guidance from the documentation | What to verify |
|---|---|---|
| Node count | Use at least three nodes for reliable quorum and HA. A two-node cluster needs a QDevice for a third vote. | Shutting down one node leaves the cluster quorate. |
| Corosync network | Keep latency under 5 ms, ideally on a dedicated physical network, with a second link on a different network. | Saturating storage or guest traffic does not break quorum. |
| Fencing | HA uses watchdog-based self-fencing. A hardware watchdog is more reliable than the software fallback. | A hung test node reboots before its HA guests start elsewhere. |
| Shared storage | HA guests need storage every node can reach, such as Ceph, NFS or a SAN. | Live migration and HA recovery work for each storage type. |
| Placement rules | Proxmox VE 9 replaces HA groups with node affinity rules. | Critical guests stay on permitted nodes during failure tests. |
Choose storage per workload
Proxmox VE supports several storage types side by side. Pick each one for a workload and a failure model.
Hyper-converged Ceph
Ceph runs on the guest nodes. The documentation calls for at least three, preferably identical, servers, at least 10 Gbps reserved for Ceph, separation from Corosync, and HBAs in place of RAID controllers.
Local ZFS with replication
ZFS gives checksums, snapshots and compression on each node. Scheduled storage replication copies guest volumes to another node, which suits small clusters that accept losing changes since the last run.
SAN over iSCSI or Fibre Channel
Existing arrays can be used through LVM on shared LUNs. Confirm snapshot behavior, multipath configuration and how the array itself is backed up.
NFS and SMB
File shares work for ISO images, templates and some guest disks. Treat the file server as an HA dependency and test guest behavior when it goes offline.
Move from VMware in planned waves
List each VM with its owner, OS, disk sizes, datastores, network segments, snapshots and acceptable downtime. Group VMs into waves that start with low-risk workloads and end with systems that need a maintenance window and rollback plan.
Install VirtIO drivers and load them into the initramfs, and remove VMware Tools while the guest still runs on ESXi. Windows guests need extra steps to boot from VirtIO SCSI. Remove snapshots, which can slow the import considerably.
Proxmox VE 8.2 added an integrated import wizard that reads guests directly from an ESXi host added as a storage source. It cannot import vSAN-backed or encrypted disks and runs much slower through vCenter. OVF import and qm disk import cover other cases.
Boot each guest and check network mapping, application health, backups and monitoring. Power a guest on in only one hypervisor at a time to avoid disk corruption, and keep the source powered off until the owner signs off.
Integrate identity and harden the management plane
Proxmox VE authenticates users through realms: Linux PAM, the built-in Proxmox VE server, LDAP, Active Directory and OpenID Connect. Use OpenID Connect or a directory realm for staff, sync groups, and grant permissions to groups on pools, guests and storage. Enforce TOTP or WebAuthn where the identity provider does not. Keep root@pam as a documented break-glass account, and give automation API tokens with privilege separation so each token can be revoked on its own.
Put the web interface, API and SSH on a management network, enable the Proxmox VE firewall, and use trusted certificates, issued through ACME where possible. Production nodes should take updates from the enterprise repository; the documentation advises against the no-subscription repository for production servers.
Back up guests to Proxmox Backup Server
Proxmox Backup Server is a separate AGPL-3.0 product that integrates with Proxmox VE. It provides incremental backups with deduplication, client-side encryption, checksum verification, sync to a remote site and tape support. Run it on hardware outside the cluster it protects.
Define retention per guest class, schedule verification jobs and sync to a second location. Store encryption keys apart from the backup server, because an encrypted backup without its key cannot be restored. Back up cluster configuration in /etc/pve along with the guests.
Test restores of a VM, a container and a single file on an agreed schedule and record how long each took. Ceph replication and ZFS snapshots help with hardware faults but do not replace backups on separate storage.
Subscriptions, repositories and versions
Every subscription level includes all features. The level decides the update source and support access.
| Topic | What to know | Deployment impact |
|---|---|---|
| License | Proxmox VE is AGPL-3.0 and free to download and run. | No license key gates features. |
| Subscriptions | Priced per occupied CPU socket per year, with every cluster node at the same level. | Count sockets during hardware planning. |
| Repositories | The enterprise repository requires a subscription and is the documented choice for production. The no-subscription repository is meant for non-production use. | Set the repository per environment in the build standard. |
| Version support | Versions are supported at least as long as their Debian base. The Proxmox FAQ lists end of life for Proxmox VE 8 in August 2026; version 9 is based on Debian 13. | Clusters still on version 8 should plan the move to 9. |
| Major upgrades | Update to the latest 8.4, run the pve8to9 checklist, and upgrade hyper-converged Ceph to 19.2 Squid first. Upgrade one node at a time. | Move guests off each node first; migration from newer to older nodes is generally unsupported. |
Proxmox VE operating ownership
Virtualization becomes shared infrastructure quickly. Name owners for the platform, the guests and the backups.
Platform
- Monitors quorum, node health, storage capacity and Ceph status.
- Applies updates and runs major upgrades.
- Documents watchdog, Corosync links and firmware.
Guest owners
- Own OS patching and application health in each guest.
- Confirm restore points and maintenance windows.
- Sign off on migration cutover.
Backup and recovery
- Runs Proxmox Backup Server, verification and remote sync.
- Holds encryption keys under separate control.
- Records restore test results.
Security
- Reviews realms, group permissions and API tokens.
- Checks firewall rules and management network exposure.
- Tracks advisories for Proxmox VE, Debian and Ceph.
Proxmox VE deployment questions
Do we need a subscription?
Proxmox VE runs without one. A subscription gives access to the enterprise repository, which the documentation recommends for production, and higher levels add vendor support tickets.
Can a two-node cluster run HA?
Only with a QDevice that supplies a third vote; otherwise losing one node also loses quorum. For production HA, the documentation recommends at least three nodes.
Should Ceph run on the Proxmox VE nodes?
Hyper-converged Ceph fits when you have at least three similar nodes, enough disks for OSDs and dedicated fast networking. With smaller hardware or an existing SAN, local ZFS with replication or shared LVM may suit better.
How long does a VMware migration take?
It depends on VM count, data volume, guest preparation and downtime windows. A pilot wave gives measured import times on your own hardware to plan the remaining waves.
Scope and handover
Effort depends on node count and hardware, storage design, network segmentation, identity integration, the number of VMware guests, backup targets and any air-gapped constraints. Guest preparation and validation often take longer than the import itself.
DeployOpen plans the cluster, installs and hardens the nodes, configures storage and networking, connects realms to your identity provider, sets up Proxmox Backup Server, runs migration waves and upgrades, and documents the platform. Handover includes the hardware and network map, storage configuration, permission model, restore results, migration records, the upgrade runbook and a support route.
