Proxmox Hardware und Sizing
Timo Wevelsiep•Aktualisiert: 09.07.2026Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.
Die richtige Proxmox-Hardware folgt einer einfachen Regel: eine 64-Bit-x86-CPU mit Virtualisierungsunterstützung (Intel VT-x oder AMD-V), genug RAM für alle VMs plus Reserve für den Hypervisor, und schnelle SSDs statt drehender Platten. Proxmox VE selbst ist genügsam und kommt mit rund 2 GB RAM aus. Den tatsächlichen Bedarf bestimmen deine virtuellen Maschinen, das gewählte Storage (vor allem ZFS) und die Frage, ob es ein Homelab oder ein Produktivsystem werden soll. Dieser Guide trennt beide Welten klar und nennt konkrete Faustregeln, Stand Juni 2026 mit Proxmox VE 9.
CPU: welcher Prozessor für Proxmox
Pflicht ist eine 64-Bit-CPU von Intel (Intel 64) oder AMD (AMD64) mit aktiviertem Virtualisierungs-Flag, also Intel VT-x beziehungsweise AMD-V (Proxmox-Systemanforderungen). Ohne dieses Flag startet KVM keine vollwertigen VMs. Wer Hardware durchreichen will, etwa eine GPU oder einen HBA an eine VM, braucht zusätzlich VT-d (Intel) beziehungsweise AMD-Vi/IOMMU (AMD). Beides ist heute in praktisch jeder Server- und den meisten Desktop-CPUs vorhanden, muss aber im BIOS/UEFI oft erst eingeschaltet werden.
Bei der Auslegung gilt: Mehr Kerne bedeuten mehr parallele VMs, eine hohe Single-Thread-Leistung hilft latenzkritischen Diensten wie Datenbanken. Proxmox kann CPU-Kerne überbuchen (mehr vCPUs vergeben als physisch vorhanden), weil selten alle VMs gleichzeitig Volllast fahren. Ein realistischer Startwert ist ein physischer Kern pro zwei bis vier durchschnittlich ausgelasteten VMs. Für Produktion empfehlen wir Server-CPUs wie Intel Xeon oder AMD EPYC: Sie bieten hohe Kernzahlen, viele PCIe-Lanes, mehr RAM-Kanäle und vor allem offizielle ECC-Unterstützung. Im Homelab leisten moderne Consumer-CPUs (Intel Core, AMD Ryzen) hervorragende Dienste, oft sparsamer und günstiger.
RAM: Faustregeln und warum ZFS extra Speicher will
Der Hypervisor selbst belegt nur etwa 2 GB. Der Rest des Arbeitsspeichers gehört den Gästen. Plane den RAM-Bedarf deiner VMs und Container realistisch und addiere einen Puffer von 10 bis 20 Prozent für den Host. Anders als CPU lässt sich RAM nicht gefahrlos stark überbuchen; eine erschöpfte Maschine führt zu Swapping oder dem OOM-Killer.
Die wichtigste Stellschraube ist ZFS. ZFS nutzt einen Lese-Cache (ARC), der sich standardmäßig großzügig bedient. Als Faustregel rechnet Proxmox mit etwa 1 GB RAM pro TB genutztem Storage für ZFS (und ebenso für Ceph) (Proxmox-Doku zu ZFS). Der ARC lässt sich begrenzen, kostet dann aber Leseleistung. Deshalb gilt:
- Ohne ZFS, kleine Workloads: 16 GB sind ein brauchbarer Einstieg.
- Mit ZFS oder mehreren VMs: 32 GB sind das untere, 64 GB ein komfortables Maß.
- Produktion mit mehreren Anwendungen und ZFS: 128 GB und mehr sind keine Seltenheit.
Reichen 32 GB? Für ein paar kleine VMs ohne ZFS: ja. Sobald ZFS-ARC und mehrere produktive VMs zusammenkommen, wird es eng. Im Zweifel lieber mehr RAM, es ist die günstigste Versicherung gegen Performance-Probleme. ECC-RAM ist offiziell nicht vorgeschrieben, für Produktion und ZFS aber dringend empfohlen: Ein unerkannter Bit-Fehler im RAM kann sonst stillschweigend auf den Datenträger geschrieben werden, und genau davor schützt ZFS nicht.
Storage: NVMe/SSD, ZFS und kein Hardware-RAID
Storage ist der häufigste Engpass. Drehende Festplatten bremsen jedes virtualisierte System aus; setze auf SSDs oder NVMe. Für Produktion empfehlen wir Enterprise-Laufwerke mit Power-Loss-Protection (PLP). Diese sind bei synchronen Schreibzugriffen, wie ZFS sie nutzt, um ein Vielfaches schneller und unter Dauerlast deutlich haltbarer als Consumer-SSDs.
Der wichtigste Punkt für ZFS-Setups: kein Hardware-RAID. ZFS ist Dateisystem, Volume-Manager und RAID in einem und will direkten Zugriff auf die rohen Datenträger. Ein RAID-Controller, der die Platten als ein einziges Volume präsentiert, nimmt ZFS die Prüfsummen- und Selbstheilungsfähigkeiten und wird offiziell nicht unterstützt. Nutze stattdessen einen HBA im IT-Mode, der die Platten unverändert durchreicht. Hardware-RAID mit batteriegepuffertem Cache (BBU) ist nur dann eine Option, wenn du klassisch mit LVM/ext4 statt ZFS arbeitest.
Praktische Empfehlungen:
- OS-Disk: 32 bis 64 GB reichen für Proxmox VE; ein ZFS-Mirror aus zwei kleinen SSDs schützt vor Ausfall der Systemplatte.
- VM-Storage: mindestens zwei NVMe/SSD im ZFS-Mirror (RAID1) für Redundanz; für mehr Kapazität RAIDZ oder mehrere Mirror-vdevs.
- Wachstum einplanen: Snapshots, Backups und Thin Provisioning fressen über die Zeit Platz.
Welches Dateisystem wann sinnvoll ist, vertiefen wir im Artikel zu Proxmox Storage: ZFS, Ceph oder LVM.
Netzwerk: dedizierte NIC für den Cluster
Für einen einzelnen Node genügt eine Gigabit-Netzwerkkarte. Sobald du einen Cluster baust, ändert sich das Bild deutlich. Proxmox empfiehlt redundante (Multi-)Gigabit-NICs, und je nach Storage-Technologie zusätzliche Karten. Trenne die Verkehrsarten:
- Corosync (Cluster-Kommunikation): braucht niedrige, stabile Latenz und gehört idealerweise auf ein eigenes, dediziertes Netz (Proxmox-Cluster-Doku). Hohe Latenz oder Paketverlust hier führen zu instabilen Clustern.
- Storage-Replikation/Ceph: sehr bandbreitenhungrig; hier sind 10 GbE oder schneller Standard, gern als eigenes Netz.
- VM-/Management-Traffic: separat vom Cluster-Netz führen.
Wie man das auf gemieteten Servern sauber löst, zeigen wir am Beispiel Hetzner im Artikel Proxmox auf Hetzner einrichten und beim HA-Cluster aufbauen.
Homelab vs. Produktion
Die wichtigste Entscheidung ist nicht die einzelne Komponente, sondern der Einsatzzweck. Ein Homelab darf günstig, sparsam und einfach sein. Produktion braucht Redundanz, Fernwartung und Enterprise-Komponenten.
| Kriterium | Homelab / Lab | Produktion |
|---|---|---|
| Plattform | Mini-PC, NUC, gebrauchter Tower | Rack-Server (Xeon/EPYC) |
| CPU | Core/Ryzen, 4 bis 8 Kerne | Xeon/EPYC, 16+ Kerne |
| RAM | 16 bis 32 GB, oft ohne ECC | 64 bis 256+ GB, ECC |
| Storage | 1 bis 2 Consumer-NVMe | Enterprise-NVMe mit PLP, ZFS-Mirror/RAIDZ |
| Netzwerk | 1x 1/2.5 GbE | redundante NICs, 10 GbE für Storage |
| Redundanz | meist keine | Netzteile, Datenträger, Cluster |
| Management | Monitor/Tastatur | IPMI/iDRAC/Out-of-Band |
| Cluster/HA | optional, zum Lernen | mehrere Nodes, geteilter/replizierter Storage |
Server-Auswahl: Mini-PC/NUC oder Dedicated Server
Für ein Homelab sind moderne Mini-PCs ideal: leise, stromsparend, NVMe-fähig und mit 16 bis 32 GB RAM ausreichend für viele Always-on-Dienste, Lernumgebungen und kleine Test-Cluster (drei Mini-PCs ergeben einen brauchbaren HA-Lab-Cluster). Was ihnen fehlt, ist meist ECC-RAM, redundante Netzteile, echtes Out-of-Band-Management und Platz für mehrere Datenträger.
Für Produktion führt kein Weg an Server-Hardware vorbei, ob im eigenen Rack oder gemietet. Achte auf ECC-RAM, mindestens zwei Enterprise-NVMe/SSDs, redundante Netzteile, IPMI/iDRAC für Fernwartung und genug PCIe-Lanes für HBA und schnelle NICs. Gemietete Dedicated Server, etwa bei Hetzner, sind oft der schnellste Weg zu produktionstauglicher Hardware ohne Investitionskosten. Für Hochverfügbarkeit planst du von Anfang an drei Nodes ein (Quorum) statt zwei.
Betrieb und Unterstützung
Hardware-Sizing ist kein einmaliger Einkauf, sondern eine Abwägung aus Workload, Storage-Architektur und Wachstum. Wir dimensionieren, beschaffen und betreiben Proxmox-Umgebungen täglich für Kunden, vom Single-Node bis zum HA-Cluster mit ZFS oder Ceph. Wenn du sichergehen willst, dass deine Hardware zur geplanten Last passt, hilft unser Team auf der Seite zu Proxmox und Private Cloud weiter. Ein unverbindliches Erstgespräch klärt dein konkretes Setup in wenigen Minuten.
Lieber betreiben lassen?
Sie möchten Proxmox nicht selbst betreiben? WZ-IT übernimmt Einrichtung, Betrieb und Wartung - datenschutzorientiert aus Deutschland.
Anfrage
Proxmox aufbauen, migrieren oder betreiben
Wir planen und betreuen Proxmox-Umgebungen vom einzelnen Node bis zum HA-Cluster, einschließlich Migration, Storage, Backup und laufendem Betrieb.