Proxmox

Proxmox is more than a hypervisor. It is a set of open-source platforms for running and protecting an independently managed server environment. This category includes subscriptions for Proxmox Virtual Environment, Proxmox Backup Server and Proxmox Mail Gateway. These products address different operational layers: compute virtualization, backup and recovery, and email security. They integrate well, but each should be designed as a distinct service with its own availability, access-control and lifecycle requirements.

A reliable Proxmox deployment is not determined by the subscription alone. CPU topology, memory headroom, storage layout, network separation, backup retention and behavior during a host failure all matter. Hardware Direct can therefore help match the required support level with a suitable server for Proxmox, or with a scalable platform selected from our rack server range.

Proxmox VE – virtual machines, containers and clustering on one platform

Proxmox VE combines hardware virtualization through KVM with operating-system-level containers through LXC. Both are administered from the same web interface, command line and API. A virtual machine provides a clearly separated guest operating system, supports both Windows and Linux, and can use features such as PCIe passthrough when the server platform is configured appropriately. An LXC container has lower overhead but shares the host kernel, so it is best treated as an efficient option for deliberately selected Linux services rather than as a universal substitute for a VM.

The platform can consolidate ERP applications, databases, directory services, file servers, development systems, VDI workloads and internal platform services. Its operational value comes less from maximizing the number of guests per host and more from providing one consistent control plane for roles, permissions, virtual networking, storage, backup, replication, migration, firewall rules and monitoring.

The target architecture should be defined before the first host is purchased. A standalone node, a management cluster and a highly available production platform have different requirements for server count, storage placement, network ports and spare capacity. Those decisions usually have a greater impact on resilience and cost than the current number of virtual machines.

Proxmox VE subscriptions – enterprise updates, support and predictable escalation

Proxmox VE does not use subscription tiers to unlock platform features. Clustering, high availability, live migration, firewalling, backup, replication and Ceph remain available regardless of whether Community, Basic, Standard or Premium is selected. The practical differences concern access to vendor support, the number of support tickets and the stated initial response time for a critical request.

• Community provides access to the Enterprise Repository and community support, but it does not include vendor support tickets. It is appropriate for labs, training, testing and non-critical services where the internal team can diagnose issues without a formal escalation path.
• Basic suits smaller production environments that need occasional assistance. It includes three support tickets per year and an initial response time of one business day.
• Standard is intended for regular production use. It includes ten tickets per year, a four-hour initial response time, remote support through SSH, and facilities for offline subscription activation and updates.
• Premium is designed for business-critical infrastructure. It provides unlimited support tickets, a two-hour initial response time, remote support and support for isolated environments.

The response time is not a guaranteed time to complete a repair. It refers to the first response to a critical ticket within the support hours defined by the vendor. The subscription should therefore be aligned with the organization's own SLA, administrator capability, escalation process and maximum tolerable interruption, rather than selected only by comparing prices.

It is also important to distinguish a paid Community subscription from running without a subscription. Proxmox VE can be used without a paid subscription, but Proxmox does not recommend the no-subscription repository for production use. A paid Community plan provides the more conservative Enterprise Repository even though it does not include direct support tickets.

One, two or four CPUs? Subscriptions are based on occupied physical sockets

Proxmox VE subscriptions are calculated from the number of occupied physical CPU sockets in each server. Core count, thread count, the number of VMs and containers, and the number of assigned vCPUs do not change the subscription quantity. Processor topology is therefore both a technical and a commercial design decision. A modern single-socket AMD EPYC server, for example, may provide more cores and PCIe capacity than an older dual-socket platform while requiring only one CPU subscription.

• A two-socket motherboard with only one processor installed requires a 1 CPU subscription.
• A server with two physically installed processors requires a 2 CPU subscription, regardless of how many cores each CPU contains.
• A four-socket server with all four sockets occupied must cover 4 CPUs.
• Every node in a Proxmox VE cluster must cover all occupied sockets, and all nodes in that cluster must use the same subscription level.

A 4 CPU product should not be treated as a floating pool that can be divided freely across four unrelated single-socket servers. Subscription keys are assigned to specific hosts. Multi-node orders must therefore account for each server individually, including its actual processor population. Empty sockets do not count, but a later CPU upgrade changes the required coverage.

Proxmox Backup Server – backups outside the production failure domain

A VM snapshot is useful as a short-term rollback point, but it is not an independent backup. When snapshots and production data reside on the same storage system, a controller failure, administrative error, compromised credentials or ransomware can affect both. Proxmox Backup Server provides a separate protection layer for virtual machines, LXC containers and physical systems.

PBS transfers backup data incrementally, applies deduplication and ZSTD compression, and supports client-side encryption. Checksums and scheduled verification jobs help identify silent corruption before a restore is required. Remote datastore synchronization, file-level restore and live restore for suitable virtual machines further improve recovery options. These capabilities reduce network traffic and capacity consumption, but they do not replace a documented retention policy or regular recovery testing.

For production use, the backup service should be placed in a different failure domain from the virtualization cluster wherever possible: separate hardware, separate administrative credentials and, for important data, an additional copy at another site. Capacity should be based on the amount of protected data, daily change rate, retention period and headroom for garbage collection and temporary operations. Deduplication must not be treated as a fixed guaranteed ratio because its effectiveness depends on the data set.

A Proxmox Backup Server subscription is purchased per physical backup server rather than by protected capacity or client count. Hardware sizing still needs to account for ingest rate, verification workload, restore objectives, network throughput and the chosen disk-failure protection. The Proxmox Backup Server category provides the available subscription levels, while usable storage and retention should be calculated from measured change rates and verified restore requirements.

Proxmox Mail Gateway – a security layer in front of the mail server

Proxmox Mail Gateway is deployed as an SMTP gateway between the Internet and the actual mail platform. It analyzes inbound and outbound messages, filters spam, malware and phishing attempts, and provides central rules, quarantine, message tracking and reporting. The filtering layer can therefore be managed independently of whether mailboxes are hosted on an on-premises Exchange or Postfix server, or on a service operated elsewhere.

PMG is not a mailbox server and does not store users' mailboxes. It also does not replace correct SPF, DKIM and DMARC configuration, secure user identities, patched systems or an incident-response process. Its role is to add an administrator-controlled security and policy layer before messages reach the core mail service.

Where email availability is important, the design must include redundant gateways, correctly prioritized MX records, independent network paths where practical, and monitoring of mail queues and certificate validity. The PMG subscription is assigned per host and does not depend on the number of users or protected domains, so high availability requires subscription coverage for each gateway node.

Sizing hardware for Proxmox VE

Vendor minimum requirements are sufficient to start a test system, not to define a production bill of materials. A production host should be sized for peak demand, expected growth, maintenance operations and the loss of a node. In a high-availability cluster, the surviving servers must have enough resources to restart or receive workloads from the failed host without turning a hardware incident into a prolonged performance incident.

• CPU. Core count matters for parallel workloads; clock speed and generation matter for latency-sensitive applications and software licensed per core. Hardware-assisted virtualization must be enabled. For dual-socket platforms, NUMA boundaries should be considered when assigning large VMs. The server processor range can be filtered according to core density, frequency and platform generation.
• Memory. The calculation must include guest allocations, host overhead, filesystem or Ceph services, page cache and operational reserve. Dynamic memory mechanisms can improve utilization but should not be used to justify chronic overcommitment. Select compatible ECC modules from the server RAM category and keep channel population balanced.
• Boot devices. The Proxmox system volume should use mirrored enterprise-class SSDs rather than a single consumer device or USB media. The boot pool is not expected to carry the main VM workload, but its failure still affects host availability.
• Workload storage. Databases and latency-sensitive VMs benefit from low-latency media, sufficient queue depth and power-loss protection. NVMe drives can provide substantial performance, but only when the PCIe topology, drive endurance, cooling and failure-replacement process are appropriate.
• Network. Management, Corosync, migration, storage and backup traffic have different latency and throughput characteristics. They can be separated physically or through a carefully designed VLAN architecture, but critical paths should have redundancy. Appropriate network cards and switches are as important as the nominal link speed.
• Power and management. Redundant power supplies should connect to independent power paths where the facility permits it. An uninterruptible power supply, tested shutdown procedures and out-of-band management such as iDRAC or iLO make maintenance and incident handling much more predictable.

Capacity planning should start from measured workload behavior: sustained and burst CPU use, working-set memory, read/write ratio, latency, IOPS, sequential throughput and change rate. A specification based only on total vCPU, allocated RAM and nominal terabytes hides the constraints that most often determine whether a virtualization platform performs consistently.

ZFS, Ceph or hardware RAID – assign data redundancy to one layer

ZFS, Ceph and hardware RAID can all provide resilient storage, but they solve the problem at different layers. A sound design makes one layer responsible for disk visibility, data placement and recovery. Combining independent redundancy mechanisms without understanding their interaction can hide drive health, complicate failure handling and create behavior that is difficult to test.

• ZFS is well suited to local storage and replication between selected nodes. It provides checksums, snapshots, compression and software-managed redundancy. ZFS should see the physical disks directly through a dependable HBA, IT or JBOD mode rather than through virtual volumes created by a RAID controller.
• Ceph distributes data across several nodes and can remove the need for a separate shared array. It is powerful, but it consumes CPU, RAM and network resources and is sensitive to latency. A practical production design normally starts with at least three storage-capable nodes, dedicated fast networking and enough free capacity to rebalance data during a failure.
• Hardware RAID remains valid when the controller is intended to manage redundancy, exposes useful health information, has protected write cache and is covered by a clear replacement procedure. In this model, the operating system consumes logical volumes rather than attempting to manage the same disks independently.
• External SAN or NAS can centralise storage and simplify some migration scenarios, but it introduces its own controllers, paths, switches and support boundaries. The array and network must be redundant end to end; shared storage is not automatically highly available.

The correct option follows the workload and operational model rather than a universal ranking. Local ZFS may be the clearest design for one or two hosts, Ceph may suit a genuinely distributed cluster, and a supported Dell storage array may be appropriate where centralized block storage and established SAN operations already exist. The comparisons RAID levels for servers and SAN vs NAS vs DAS help frame these decisions.

A Proxmox cluster is not automatically a high-availability design

Joining nodes into a cluster centralizes management and enables coordinated operations, but it does not by itself guarantee that a service will continue after a failure. High availability also requires quorum, adequate spare compute capacity, recoverable storage, redundant networking and correctly defined HA resources. Each of these elements must be tested under realistic failure conditions.

Reliable quorum normally requires at least three votes. A two-node arrangement can use a QDevice to provide a third vote, but the QDevice does not supply CPU, memory or storage capacity. If one compute node fails, the remaining node still has to run the affected workloads. Corosync also values low and stable latency more than raw bandwidth, so its traffic should not be allowed to compete unpredictably with Ceph recovery, live migration or large backup transfers.

Storage selection changes the recovery model. Shared storage can make restart on another node straightforward, local ZFS can support controlled replication, and Ceph can distribute data across cluster members. None of these choices replaces an independent backup. HA reduces downtime caused by selected infrastructure failures; backup protects data and supports recovery from deletion, corruption, ransomware and operator error.

A useful acceptance test covers a host power loss, loss of a network path, loss of a storage device, failed migration, loss of quorum and restoration from backup. The result should document not only whether services return, but also how long they take to return, which alerts are generated and what manual actions remain necessary.

Choosing the right Proxmox subscription

Start with the product role. Proxmox VE subscriptions apply to virtualization nodes, Proxmox Backup Server subscriptions apply to physical backup servers, and Proxmox Mail Gateway subscriptions apply to mail gateway hosts. Then count the relevant units correctly: occupied CPU sockets for each VE node, physical servers for PBS, and hosts for PMG.

Next, assess operational impact. A small internal lab can reasonably depend on internal knowledge and community resources. A production system supporting ERP, authentication, databases or customer services needs a documented escalation route. The appropriate level depends on how quickly the team must be able to involve the vendor, not simply on the number of guests.

Finally, examine the whole architecture. A Premium subscription cannot compensate for a single unprotected storage path, insufficient failover capacity or backups kept in the same failure domain. Conversely, technically competent teams operating a carefully tested, non-critical environment may not need the highest support tier. Support, hardware design and operating procedures should reinforce one another.

Hardware Direct is an official Proxmox partner and can help align the subscription with server topology and the intended operating model. A preliminary hardware specification can also be prepared through the server configurator. For a broader architectural perspective, see the guide explaining why an open-source virtualization platform can be a practical infrastructure choice.

Frequently asked questions

Does Proxmox VE require a paid license?

No. Proxmox VE is open-source software and can be operated without a paid subscription. A subscription provides access to the Enterprise Repository and, with Basic, Standard or Premium, vendor support. It does not unlock a separate set of platform functions.

Does Community provide fewer features than Basic, Standard or Premium?

No. The technical feature set does not depend on the support level. Community does not include vendor support tickets, so its suitability for production depends on business risk, internal expertise and the required SLA.

How is the required number of CPU subscriptions calculated?

Count the physically installed processors, or occupied sockets, in each server. Cores, threads, VMs and vCPUs do not affect the quantity. A dual-socket motherboard with one installed CPU requires 1 CPU; after a second processor is installed, it requires coverage for 2 CPUs.

Must every node in a cluster use the same subscription level?

Yes. Every node must cover all of its occupied CPU sockets, and a Proxmox VE cluster must use one consistent subscription level. This also provides a consistent basis for repositories, updates and support procedures.

Does a VM snapshot replace a backup?

No. A snapshot normally depends on the same storage as the VM and is intended mainly as a short-lived rollback point. A backup should reside on a separate system, follow its own retention policy and be validated through regular restore tests.

Can Proxmox Backup Server run as a VM in the same cluster?

It can, but it should not be the cluster's only backup. A failure affecting hosts, storage or administrative accounts may otherwise make production and backups unavailable at the same time. A separate PBS host, or at least an additional copy synchronized to an independent location, is more robust for business data.

Can ZFS be placed on top of hardware RAID?

This is not the recommended architecture. ZFS should see the physical disks directly so that it can control device health, write ordering and redundancy. The controller should provide a reliable HBA, IT or JBOD mode. The same principle applies to disks used as Ceph OSDs.

How many nodes are required for a Proxmox HA cluster?

At least three votes are advisable for reliable quorum. A two-compute-node cluster can use a QDevice as the third vote, but that device does not provide failover capacity. The surviving compute node must still have enough CPU, memory and access to data to run the affected services.

Is 10GbE mandatory for Proxmox?

No. A standalone host with light workloads may operate acceptably on 1GbE. Links of 10GbE or 25GbE become important for fast shared storage, Ceph, frequent migrations, large backups and many concurrent guests. Redundancy and traffic separation remain important regardless of nominal speed.

Does Proxmox Mail Gateway replace the mail server?

No. PMG is a security gateway for SMTP traffic and does not manage user mailboxes. It is placed in front of Microsoft Exchange, Postfix or an externally hosted mail platform to filter unwanted and dangerous messages.

When should I choose a single-socket rather than a dual-socket server?

A single-socket platform is attractive when one CPU provides enough cores, memory channels and PCIe lanes while limiting subscription cost per socket. A dual-socket server is justified by higher memory, I/O or compute requirements, but it also requires deliberate NUMA planning and subscription coverage for the second processor.