Proxmox hardware requirements, checked against a dedicated server

Minimum against recommended, from the admin guide

The Proxmox VE 9.2 admin guide lists two sets of requirements. The minimum set is labelled for evaluation and not for production; the recommended set is what a host carrying real guests should meet.

The ZFS chapter sets its own floor: 8 GB of RAM as the starting point, ECC memory recommended, and no ZFS on top of a hardware RAID controller. Ceph carries the same restriction.

arm64 hosts are supported on NVIDIA Grace Hopper and Vera and best-effort on other UEFI ARMv9-A hardware, but that does not help here: our Proxmox image is an x86 build, and no ARM line runs it.

Sizing memory

Memory is the figure to settle first, because guests are given fixed amounts. Take the documented 2 GB for the host, add the memory of every guest, then add roughly 1 GB per TB of used space if the pool is ZFS. Example, and this arithmetic is ours rather than Proxmox's: eight guests at 4 GB each on a ZFS mirror holding 2 TB of data come to 2 + 32 + 2 = 36 GB, so a 64 GB machine leaves room for growth and for the ZFS cache to do useful work.

Proxmox publishes no figure for cores per guest. Count the vCPUs your guests will actually keep busy, not the ones they are allocated. Run the bundled pveperf after install for a quick CPU and disk reading; the guide calls it a very quick, general benchmark and recommends more detailed I/O tests.

What the delivered host has

Proxmox VE 9 (installer image 9.2-1, on Debian 13) is installed unattended at build time on 15 of our dedicated lines, with no OS charge and no licence to buy. The root password arrives by email and the web interface is on port 8006. A racked machine is handed over about 30 minutes after the order is approved; a build to order takes 4 to 24 hours. The dedicated server range lists every line, and the Proxmox hosts page narrows it to the ones that take the image.

The storage rows follow the guide: ZFS goes where the disks are raw, the RAID card keeps its own volume, and ZFS is never stacked on the card. The network row is where a single machine falls short of the recommended list, covered at the end. For two sockets and up to 1 TB of memory, the enterprise blades are the usual base.

First hour: closing port 8006

The web interface on 8006 exposes the whole Proxmox API. pveproxy listens on the wildcard address and accepts IPv4 and IPv6 clients alike, so a hand-written iptables rule for IPv4 leaves the same port open over IPv6. The built-in Proxmox firewall filters both protocols from one rule set, and it ships disabled.

1. SSH in as root with the emailed password, change it with passwd, and add your SSH public key to root's authorized keys.
2. Keep that SSH session open: the guide advises it before the firewall is switched on, so a mistake does not cut you off.
3. Write the cluster-wide firewall file below. The guide recommends setting local_network to the single address for one host on a public network; otherwise the detected range covers the whole subnet around your address, and the automatic rules that admit API and SSH traffic are built from that range.
4. Run pve-firewall status to check the rules compile, then open a second SSH session to confirm you still get in.
5. Once key login works from that second session, set PermitRootLogin prohibit-password in /etc/ssh/sshd_config and run systemctl reload ssh. Port 22 stays open to the internet, so it should stop accepting passwords.
6. Reach the web interface through an SSH tunnel over your own root login, not across the internet.

# /etc/pve/firewall/cluster.fw  (one host on a public address)
[OPTIONS]
enable: 1
policy_in: DROP

[ALIASES]
local_network 203.0.113.10

[RULES]
IN SSH(ACCEPT)

# on your own computer; leave it running while you work
ssh -N -L 8006:127.0.0.1:8006 root@203.0.113.10
# then open https://127.0.0.1:8006 in a browser

With the input policy at DROP, 8006 stays closed to the internet over both IPv4 and IPv6, while loopback traffic, which is what the tunnel delivers, is still allowed. If a rule does lock you out, the out-of-band console on the blades and the m510 and m710x gets you back to a shell; the m700, m710, m710p and m750 offer only power control, so keep the second SSH session open on those until the new rules are proven.

Root with a second factor

In the web interface, open Datacenter, Permissions, Two Factor (or the TFA button in the user list) and add a TOTP factor for root@pam, scanning the QR code into an authenticator app. Generate recovery keys in the same panel and store them off the server. After 8 failed TOTP attempts Proxmox disables that user's TOTP factors; a recovery key unlocks them. With no recovery key left, open a root shell over SSH and run pveum user tfa unlock root@pam. The second factor guards logins to the web interface; SSH stays on keys.

Repositories and updates

According to the guide the pve-enterprise repository is enabled by default, and it needs a subscription key. A subscription is optional and bought from Proxmox, not from us. Without one, disable the enterprise entry and add pve-no-subscription, which Proxmox describes as fit for testing and non-production use and not recommended for production servers. Do the same with the Ceph enterprise entry in ceph.sources if apt update complains about it.

# add this line to the entry in /etc/apt/sources.list.d/pve-enterprise.sources
Enabled: no

# /etc/apt/sources.list.d/proxmox.sources
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

# then, as root
apt update
apt full-upgrade

Always apt full-upgrade, never apt upgrade: the guide warns that a plain upgrade can leave Proxmox's rolling packages half-upgraded.

Backups that leave the host

vzdump takes full backups of a guest's configuration and data, from the GUI or a scheduled backup job. For VMs, snapshot mode copies blocks while the guest runs and, with the QEMU guest agent enabled, freezes the filesystem for consistency; stop mode gives the highest consistency at the cost of a short shutdown. The guide recommends a Proxmox Backup Server on a separate host as the target, with NFS as the alternative. A second, smaller dedicated server running Proxmox Backup Server fits that advice; a dump on the same disks as the guests does not.

Where one machine falls short

• One NIC. The guide recommends redundant NICs and a dedicated one for cluster traffic. Every machine here has one connected port, and no private VLAN is sold, so corosync, migration and guest traffic share the public port.
• Clusters. For high availability Proxmox wants at least three nodes (or two plus a QDevice), with latencies under 5 ms; in practice, nodes in one city. The single-host firewall file above does not fit a cluster: before joining nodes, admit every node's address and the corosync ports, UDP 5405-5412.
• Unmanaged. We keep the hardware, the network and the console running; the hypervisor and the guests are yours to run.
• Guest addresses. One IPv4 and IPv6 come with the server. Extra IPv4 come from the same /24, bridged or routed, with no MAC registration.