Proxmox Virtual Environment (Proxmox VE) is an open-source server virtualization and management platform developed by Proxmox Server Solutions GmbH. It brings together KVM/QEMU virtual machines, LXC containers, storage, networking, clustering, high availability, backup, and automation in one platform.
That distinction matters. Proxmox VE is not simply an application that creates virtual machines. When installed on a server, it becomes a complete Debian-based virtualization environment that can be managed through a web interface, command-line tools, and a REST API.
It can serve a one-node home lab, a small business server, or a multi-node production cluster with distributed storage and high availability. The same management model covers Windows and Linux VMs, Linux containers, backups, virtual networking, shared storage, and cluster resources.
What exactly is Proxmox VE?
Proxmox VE is based on Debian GNU/Linux and uses a Linux kernel maintained by Proxmox. The platform is released under the GNU AGPLv3, so the complete feature set can be downloaded and used without purchasing a functional license.
It integrates two major forms of virtualization:
- KVM/QEMU: full virtualization for guests with their own kernel and virtual hardware. This is the normal choice for Windows, GNU/Linux, BSD, and other operating systems.
- LXC: operating-system-level virtualization. Containers share the host Linux kernel and therefore usually consume less memory and storage than full VMs.
Proxmox describes the platform as an integrated solution for compute, network, and storage. The web UI is not merely a front end: most management functionality is also available through CLI tools and the REST API.
Official overview: Proxmox Virtual Environment.
Virtual machines versus LXC containers
A VM presents a complete virtual machine with virtual CPU, RAM, disks, network adapters, firmware, and an independent kernel. This provides stronger isolation and allows the guest to run a different operating system from the host.
An LXC container shares the host Linux kernel. It is lighter, starts quickly, and is particularly efficient for Linux services.
| Requirement | KVM/QEMU VM | LXC container |
|---|---|---|
| Run Windows | Yes | No |
| Independent kernel | Yes | No |
| Resource overhead | Higher | Lower |
| Isolation | Stronger | Shares host kernel |
| Lightweight Linux services | Possible | Very well suited |
| Complex hardware passthrough | Very flexible | More constrained |
The decision should not be based only on RAM savings. Workloads that need their own kernel, Windows, stronger isolation, advanced security boundaries, or complex PCIe/GPU passthrough are often better placed in a VM.
LXC is not Docker
Proxmox VE uses LXC as its container technology. Traditionally, Proxmox containers have been system containers: isolated Linux environments that behave much like small servers.
Starting with Proxmox VE 9.1, Proxmox can also create LXC containers from OCI images. Depending on the source image, these can be provisioned as full system containers or leaner application containers.
This does not turn Proxmox LXC into Docker. OCI defines interoperable image formats; the runtime and isolation model are still those used by Proxmox and LXC.
Proxmox documented the change in the Proxmox VE 9.1 release.
Central management from a browser
Most day-to-day administration happens through the HTTPS web interface. Administrators can create and operate guests, allocate CPU and memory, attach storage, manage virtual networks, review tasks and logs, configure backup jobs, manage users and roles, and build clusters without installing a separate management application.
In a cluster, management is multi-master: you can connect to any node and manage the cluster from there. There is no dedicated management node that must remain online for the UI itself to exist.
Command line and REST API
Proxmox VE also exposes extensive command-line tooling. Common utilities include qm for VMs, pct for containers, pvesh for API access, pvecm for cluster management, and vzdump for integrated backups.
The REST API makes it possible to integrate provisioning systems, configuration management, inventory tools, and custom automation. Once an environment grows, repeatable API-driven operations are often safer than performing the same GUI sequence manually across many guests.
Proxmox VE 9.2 in October 2026
As of this review, Proxmox VE 9.2 is the current stable release. It was published on May 21, 2026.
Version 9.2 is based on:
- Debian 13.5 “Trixie”;
- Linux 7.0 as the stable default kernel;
- QEMU 11.0;
- LXC 7.0;
- ZFS 2.4;
- Ceph Tentacle 20.2 as the current integrated stable Ceph branch.
Major 9.2 additions include the Dynamic Load Balancer, expanded SDN support with WireGuard and BGP Fabrics, route maps and prefix lists for BGP/EVPN, web-based management of custom CPU models, and a new Disarm/Arm maintenance workflow for HA resources.
Official release information: Proxmox Virtual Environment 9.2.
What Proxmox VE 9.0 changed
The 9.x family began in August 2025 with the transition to Debian 13. Proxmox VE 9.0 also introduced several major storage and networking changes:
- VM snapshots on supported thick-provisioned shared LVM storage;
- volume-chain snapshot support for Directory, NFS, and CIFS storage;
- SDN Fabrics for advanced routed topologies;
- node and resource affinity rules for HA;
- RAIDZ expansion through the newer ZFS stack;
- a redesigned mobile web interface.
The thick-LVM snapshot feature is particularly useful in enterprise SAN environments using iSCSI or Fibre Channel, where snapshots had historically been more difficult to integrate consistently.
Networking: bridges, VLANs, bonding, and SDN
In a basic installation, virtual guests usually connect to a Linux bridge such as vmbr0. Conceptually, the bridge behaves like a virtual Ethernet switch inside the node.
From there, administrators can build VLAN-aware bridges, bonds, multiple networks, routed designs, and Software-Defined Networking (SDN).
Proxmox VE 9.0 introduced SDN Fabrics for more complex routed topologies. Version 9.2 expanded Fabrics with WireGuard and BGP and added finer control of route advertisement through route maps and prefix lists.
Large environments often separate management, Corosync, migration, storage, and Ceph traffic. That does not necessarily require one physical NIC per function, but bandwidth and redundancy should be designed so that a storage or migration burst cannot starve cluster communication.
Storage: local, shared, and distributed
Proxmox VE provides a common storage layer over many back ends, including:
- Directory;
- LVM and LVM-Thin;
- ZFS;
- NFS;
- SMB/CIFS;
- iSCSI;
- Ceph RBD and CephFS;
- additional back ends through plugins and integrations.
The best design depends on the environment. A single-node lab with one SSD has very different requirements from an HA cluster using shared SAN storage or a hyperconverged Ceph deployment.
ZFS
ZFS is attractive for local storage because it combines checksums, snapshots, compression, redundancy, and strong data-integrity features.
Proxmox specifically warns against placing ZFS behind a traditional hardware RAID controller that hides the physical disks. ZFS needs direct disk visibility to manage redundancy and integrity correctly.
Ceph
Ceph provides distributed storage across multiple nodes and is deeply integrated into the Proxmox UI and CLI. It can expose RBD block devices for VM disks and CephFS for file storage.
Ceph needs adequate networking, memory, disk count, and failure-domain planning. It should not be added to a small cluster simply because the GUI makes installation easy.
Clustering, Corosync, and quorum
Multiple Proxmox nodes can be joined into a cluster. Datacenter configuration is replicated through pmxcfs, while membership and quorum depend on Corosync.
It is inaccurate to say that Proxmox requires exactly three nodes to form a cluster. Two-node clusters are possible, but quorum requires careful design. Proxmox recommends using a QDevice to provide a third vote in small two-node clusters.
For production HA, three or more nodes are usually a more natural design. Corosync requires consistently low latency, and Proxmox recommends dedicated or carefully isolated network paths for cluster communication.
High availability is not the same as clustering
Clustering provides coordinated management and shared configuration. High Availability (HA) adds the ability to recover selected workloads on another node after a failure.
A sound HA design must consider:
- quorum;
- spare compute capacity;
- guest storage availability;
- redundant networking;
- affinity and anti-affinity rules;
- maintenance and fencing behavior;
- independent backups.
Proxmox VE 9.2 adds a Dynamic Load Balancer that can use real workload data to improve guest placement, along with the Disarm/Arm workflow for planned HA maintenance.
Live migration and CPU compatibility
Proxmox can move running VMs between nodes when CPU, networking, and storage requirements are met.
An important detail in the official cluster documentation is that online migration is supported when source and destination CPUs come from the same vendor. Mixing Intel and AMD may work in some configurations with carefully selected virtual CPU models, but it should not be treated as a supported baseline for live migration.
Cluster CPU strategy should therefore be planned before large-scale deployment, not after the first migration problem appears.
Snapshots, replication, and backups are different tools
A snapshot can help roll a guest back within the same storage system. Replication places another operational copy on another node. Neither automatically replaces an independent backup.
Proxmox VE includes vzdump for full VM and container backups, including scheduled jobs.
Proxmox Backup Server (PBS) adds incremental transfer, deduplication, verification, client-side encryption, retention management, synchronization, live restore, and granular file recovery.
An HA platform without independent backups can still lose data through operator error, ransomware, logical corruption, or accidental deletion.
Security and access control
Proxmox VE uses role-based access control and supports multiple authentication realms. Permissions can be delegated to nodes, guests, resource pools, storage, and other objects in the resource tree.
The platform also supports multi-factor authentication, API tokens, TLS certificates, an integrated firewall, and external identity sources including LDAP, Active Directory, and OpenID Connect.
In larger environments, daily administration should not depend on sharing root@pam. Dedicated users, groups, roles, and API tokens provide better separation of duties and auditability.
Integrated firewall
The Proxmox VE firewall can apply rules at datacenter, node, VM, and container scope. It supports security groups, IP sets, aliases, and IPv4/IPv6 filtering.
This does not necessarily replace a dedicated perimeter firewall. Its strongest role is enforcing policy close to workloads and protecting traffic to and between virtualized systems.
Official ARM64 support in Proxmox VE 9.2
On August 5, 2026, Proxmox released an official ARM64/AArch64 build of Proxmox VE 9.2, the first officially supported Proxmox VE release on a CPU architecture other than x86-64.
The ARM64 build shares the same source base, repositories, and release lifecycle as the x86-64 release. Proxmox provides full support on NVIDIA Grace Hopper and NVIDIA Vera platforms and best-effort support for other UEFI-based ARMv9-A or newer server hardware.
This should not be interpreted as official Raspberry Pi support. Supported ARM hosts must boot through UEFI and describe hardware through ACPI; device-tree-only systems such as Raspberry Pi are not supported.
Mixed x86-64/ARM64 clusters are not officially supported, and live migration cannot move a running guest across CPU architectures.
Hardware requirements
Real hardware requirements depend mostly on the workloads you plan to run.
Current Proxmox guidance recommends:
- x86-64 with Intel VT-x/AMD-V, or supported ARM64 server hardware;
- at least 2 GB of RAM for Proxmox VE and its services, plus memory assigned to guests;
- fast and preferably redundant storage for production;
- network interfaces sized for management, storage, migration, and cluster needs.
ZFS and Ceph need additional memory. Proxmox uses approximately 1 GB of additional RAM per TB of used storage as a planning guideline, although final sizing depends on cache behavior and workload.
For production, ECC memory, enterprise storage devices, redundant networking, and power protection are often more important than simply meeting minimum requirements.
ZFS and Ceph versus hardware RAID
One recommendation is worth repeating: neither ZFS nor Ceph should be placed behind a conventional hardware RAID layer that hides individual drives.
Both technologies need direct access to disks so they can detect failures and manage redundancy correctly. If a storage controller is used, HBA/JBOD-style direct-disk access is generally the appropriate model.
Is Proxmox VE free?
Yes. The full platform is open source and virtualization features are not locked behind a commercial license.
The main distinction is between package repositories and support:
- Enterprise Repository: requires an active subscription and contains the most heavily tested and validated package versions; Proxmox recommends it for production.
- No-Subscription Repository: freely accessible and intended by Proxmox for testing and non-production use.
- Test Repository: contains newer packages intended primarily for developers and testing.
A subscription also provides commercial support according to the selected service level.
Download Proxmox VE 9.2
Use the official download page:
As of October 5, 2026, the current x86-64 installer is Proxmox VE 9.2-1, approximately 1.71 GB. Proxmox publishes both SHA-256 checksums and OpenPGP signatures so administrators can verify the image before installing it.
SHA-256 for the x86-64 9.2-1 ISO:
4e88fe416df9b527624a175f24c9aa07c714d3332afb1ee3dbf3879573ef2c6cThe ARM64 9.2-1 ISO has its own image and checksum on the same official download site.
Install from ISO or on top of Debian
For a new deployment, the official ISO is usually the simplest and most predictable method. It configures the Debian base, Proxmox kernel, repositories, initial storage, and required services as one installation flow.
Proxmox VE can also be installed on a compatible Debian 13 “Trixie” system. That route offers more control over partitioning and base-system preparation, but requires careful attention to hostname, DNS resolution, networking, and repositories.
Proxmox VE, Backup Server, and Datacenter Manager
Several Proxmox products complement each other but serve different roles:
- Proxmox VE: runs and manages VMs, containers, storage, networking, and clusters.
- Proxmox Backup Server: dedicated backup, deduplication, verification, retention, and restore platform.
- Proxmox Datacenter Manager: higher-level management and visibility across multiple Proxmox clusters and sites.
- Proxmox Mail Gateway: email security gateway, separate from the virtualization platform.
Understanding those boundaries helps avoid putting every infrastructure role onto one virtualization node simply because the products come from the same vendor.
Where does Proxmox VE fit well?
Common use cases include:
- home labs and technical labs;
- small and medium business virtualization;
- enterprise clusters;
- hyperconverged Ceph deployments;
- Windows and Linux server virtualization;
- lightweight Linux services in LXC;
- development and test environments;
- GPU and PCIe passthrough workloads;
- migration away from other hypervisors;
- API-driven infrastructure automation.
Its main strength is the way it combines mature Linux technologies into one coherent management platform while still leaving the underlying system accessible to administrators who need lower-level control.
Universo Digital Proxmox VE series
This introduction is the entry point to our Proxmox VE series. Dedicated articles cover installation, upgrades, storage, ZFS, Ceph, clustering, HA, SDN, security, passthrough, API automation, performance, troubleshooting, backups, and the newer Proxmox VE 9.x capabilities.
