Proxmox VE Hardware Requirements for a Home Lab Build

Proxmox VE will install on almost anything with a 64-bit processor, which is exactly why so many first builds end up wrong. The published minimum specification is an evaluation floor, not a shopping list, and the gap between “it boots” and “it runs guests you care about” is mostly memory, disk choice and network ports. This is a reading of what Proxmox Server Solutions publishes as its own requirements, and what those figures add up to once you put real guests on the box.

The published numbers, and what they are for

Proxmox splits its hardware guidance into two lists. The distinction matters more than either list.

Component	Documented minimum	Documented recommendation
CPU	64-bit x86 (Intel 64 or AMD64), or 64-bit Arm (Armv9-A or newer)	Intel 64 or AMD64 with the Intel VT or AMD-V flag, or 64-bit Arm (Armv9-A or newer)
Memory	1 GB, plus RAM for guests	2 GB for the OS and Proxmox VE services, plus guest memory
Storage	One hard drive	Fast and redundant storage; best results with SSDs
Network	One network card	Redundant gigabit NICs, with 10 Gbit and above supported

The installation chapter of the administration guide is explicit that the minimum column is “for evaluation purposes only and should not be used in production”. Treat it as the specification for a throwaway nested test, and size against the right-hand column for anything you intend to keep.

CPU: the flags decide what you can run

Core count is the least interesting property of a Proxmox host. The virtualization extension is the one that gates functionality: the Intel VT or AMD-V flag appears only in the recommended list, and KVM full virtualization depends on it. A host without it is not useless, but it is a container host, because LXC shares the running kernel and does not need hardware virtualization at all.

A second flag decides whether the build can ever do passthrough. The requirements page states that “for PCI(e) passthrough a CPU with VT-d or AMD-Vi CPU flag is required”. Passthrough also depends on IOMMU grouping, which is a property of the board and chipset rather than the CPU, so a machine can satisfy the flag requirement and still put your GPU in a group with half the southbridge. Confirm group layout for the specific board before buying for a passthrough build.

Proxmox lists 64-bit Arm (Armv9-A or newer) in both the minimum and the recommended columns. That is worth knowing if you are evaluating Arm hardware, but the x86 path remains the one with the deepest documentation and the widest guest-image availability.

CPU is the resource you can safely overcommit. Assigning more total vCPUs across guests than the host has threads is normal practice, because most guests idle. Memory does not behave that way, which is why sizing starts there instead.

Memory is the binding constraint

Budget in three layers.

The base layer is the 2 GB the recommended list reserves for the operating system and Proxmox VE services. The second layer is whatever the guests are configured to use, and the honest number is the configured maximum rather than the idle working set, because a guest that balloons up during a backup window will take it.

The third layer is storage overhead, and it is the one people forget. The requirements page allocates “approximately 1 GB memory for every TB used storage” when running Ceph or ZFS. That is a per-host figure against used capacity, not raw capacity, but it grows with the pool rather than with the guests. A node holding 20 TB of ZFS data is carrying roughly 20 GB of memory overhead before a single VM starts.

Ceph is heavier still. The hyper-converged Ceph chapter puts the baseline around 4 GiB per OSD daemon and recommends planning for about 8 GiB per OSD, because recovery and rebalancing are far more memory-hungry than steady-state I/O. A node with six OSDs is therefore looking at roughly 48 GiB reserved for storage alone. Sizing Ceph nodes to their idle memory use is how a single disk failure turns into a cluster-wide out-of-memory event, exactly when you need the cluster most.

Error-correcting memory is not a documented requirement, and Proxmox does not list it. It is worth understanding why people insist on it anyway: ZFS and Ceph both checksum data on disk and can repair what they find wrong there, but neither can detect corruption that happened in RAM before the checksum was computed. ECC closes that specific hole. Whether it is worth the platform premium is a judgement call about how much you care about the data, not a compatibility question.

Storage: what the installer wants and what ZFS wants are different

Put the operating system somewhere separate from guest storage. Proxmox VE writes continuously to the cluster filesystem, and on a cluster corosync and pmxcfs generate small synchronous writes all the time; sharing that device with a busy guest pool makes both slower and complicates recovery.

The single most consequential line on the requirements page is about controllers: “Neither ZFS nor Ceph are compatible with a hardware RAID controller.” A RAID card that hides the physical disks removes the very thing ZFS and Ceph depend on, which is direct access to each device and its error reporting. If the build is going to use ZFS or Ceph, the controller needs to present disks directly, in HBA or IT mode. The hardware-RAID path in the requirements table applies to the traditional LVM layout, where a battery-backed write cache genuinely helps, and Proxmox pairs it with a warning about the battery for a reason.

Disk class matters most under Ceph. The Ceph chapter recommends enterprise SSDs over spinning disks in smaller clusters, and the reasoning is recovery time: a small cluster rebuilding onto slow media spends longer in a degraded state where a second failure is fatal. The same logic argues for power-loss protection on any device handling synchronous writes, because the alternative is a device that either loses acknowledged writes or turns every sync into a full flush.

Network: count roles, not ports

A Proxmox cluster has up to four distinct traffic classes, and the port count follows from how many of them you intend to separate.

Cluster communication comes first, and its needs are unusual. The cluster manager chapter states that corosync “needs consistent low latency but not a lot of bandwidth”, and that a dedicated 1 Gbit NIC is normally enough. What it will not tolerate is contention: sharing the link with backups, migrations or Ceph replication produces latency spikes that look identical to a dead node. The stack requires “latencies under 5 milliseconds (LAN performance) between all nodes to operate stably”, and since Proxmox VE 6.0 corosync has used Kronosnet with UDP unicast rather than multicast, so the old multicast-capable-switch requirement no longer applies. Kronosnet supports up to eight links, and configuring a second one on different physical infrastructure is cheaper than any other redundancy you can buy.

Ceph is the opposite profile: high bandwidth, and it should not share with anything. The Ceph chapter asks for “a network bandwidth of at least 10 Gbps, or more, to be used exclusively for Ceph traffic”, with 25 Gbps and above suggested once NVMe devices are involved.

Guest traffic and management can share a link on a small build. Make the Linux bridge VLAN-aware from the start if you expect to segment later, because retrofitting that setting means touching every guest.

What the requirements add up to

Three builds, sized straight from the documented figures rather than from any measurement made here.

A single node with no cluster needs one machine with VT-x or AMD-V, 2 GB reserved for the platform plus the sum of configured guest memory, an SSD for the OS, separate storage for guests, and one NIC. Nothing in the cluster or Ceph guidance applies. This is the correct starting point for most people, and it is not a lesser build.

A three-node cluster without hyper-converged storage adds a second NIC per node for corosync, a shared or replicated storage backend so that migration and HA have something to work with, and a third vote so the cluster stays quorate when one node is down. Three nodes gives you that vote by construction, which is why the HA manager chapter asks for “at least three cluster nodes (to get reliable quorum)”.

A three-node hyper-converged Ceph cluster is the expensive one. The Ceph chapter asks for “at least three (preferably) identical servers”, a dedicated 10 Gbps or faster storage network on top of the corosync link, HBAs rather than RAID controllers, enterprise SSDs, and roughly 8 GiB of RAM per OSD on top of guest and ZFS overhead. Default pool settings of size 3 and min_size 2 mean three copies of every object and I/O suspended if fewer than two survive, so usable capacity is about a third of raw.

The Proxmox VE HA cluster and Ceph sizer applies the same per-node RAM, quorum and OSD-overhead arithmetic if you would rather adjust node counts and see the numbers move.

Where the money is wasted

Hardware RAID controllers are the most common wasted purchase, because the ZFS or Ceph build you are probably heading toward cannot use them. Extra cores are the second, since memory runs out long before threads do on a general-purpose lab host. The third is a two-node cluster, which buys the complexity of clustering without the quorum to survive a failure; the reasoning behind that is in planning a Proxmox VE cluster, and the failure mode it produces is covered in Proxmox no quorum errors.

If the build is replacing an existing VMware host rather than starting fresh, the licensing and feature differences are set out in Proxmox VE vs VMware ESXi, including the import path for existing virtual machines.