The Proxmox cluster.
The two compact machines and the rack server form the three-node cluster. Local disks supply VM storage, with ZFS replication configured for selected guests. The hardware is not interchangeable: CPU generations, memory capacity and storage layout differ.
The larger server provides substantially more RAM, while the compact nodes offer a different footprint and operating profile. This makes placement, resource sizing and recovery capacity visible design decisions rather than abstract orchestration features.
The separate operational host.
The Lenovo runs Linux directly and hosts selected operational applications in containers. It is outside the three-node Proxmox cluster. That separates one part of the operational tooling from guest placement, but does not remove its database, network or storage dependencies.
The NAS.
A QNAP NAS provides shared storage. Selected applications use NAS-backed persistent data, while other state remains on local disks or in databases. Backup repositories and live application data are separate uses, even when both depend on the NAS.
This public inventory does not enumerate disks, shares, export paths or private datasets. See the storage model →
Why hardware still matters with virtualisation.
A cluster needs enough eligible spare capacity to recover a workload after a host disappears. VM HA cannot manufacture RAM, an absent disk or a suitable network path. A guest that depends on shared storage also depends on that storage’s availability.
Disks and RAID visibility need care too: an operating system can report a healthy logical volume without establishing the condition of every physical disk behind a controller. Health checks should describe the layer actually observed.
What I do not claim from this inventory.
These specifications do not constitute a performance benchmark, a full N+1 capacity audit or a measurement of power consumption. The snapshot confirms the compute foundation; suitability for a particular service needs workload-specific evidence.