Hardwareauswahl & CPU

Server, Mini-PC oder selbstgebaut?

Wichtig: Proxmox VE läuft auf x86-64-Hardware. Kein Apple Silicon – seit Version 9.2 (August 2026) gibt es ersten Arm64-Support für ausgewählte Serverplattformen, das bleibt aber vorerst die Ausnahme. Für ein erstes Testlabor reicht auch gebrauchte Business-Hardware (z. B. ein ausrangierter Dell/HP/Lenovo-Tower-Server) völlig aus – die Kernanforderungen (VT-x/AMD-V, genug RAM) erfüllen auch mehrere Jahre alte Modelle.

CPU-Voraussetzungen

• Virtualisierungserweiterung zwingend: Intel VT-x oder AMD-V – ohne sie startet Proxmox VE gar nicht erst, die meisten Server- und Desktop-CPUs der letzten 15 Jahre bringen sie aber mit
• Für GPU-/Geräte-Passthrough zusätzlich IOMMU nötig: Intel VT-d bzw. AMD-Vi, im BIOS/UEFI aktivieren (Bezeichnung variiert je Hersteller, z. B. „Intel VT for Directed I/O")
• Ohne IOMMU kein sauberes Durchreichen einzelner PCIe-Geräte an eine VM – das Gerät bliebe entweder dem Host vorbehalten oder müsste per Software emuliert werden, was Performance kostet
• IOMMU-Gruppierung prüfen: Geräte, die in derselben Gruppe stecken, lassen sich nur gemeinsam durchreichen – bei ungünstigem Mainboard-Layout betrifft das mitunter mehr Hardware als gewünscht
• Praxisrelevant vor allem für KI-/ML-Workloads (Inferenz, Training, lokale LLMs): GPU-Passthrough reicht eine physische GPU komplett und exklusiv an eine einzige VM durch – volle native Leistung, aber die Karte steht anderen VMs dann nicht mehr zur Verfügung. vGPU (GPU-Sharing) teilt eine GPU dagegen auf mehrere VMs auf, ist aber herstellerabhängig und meist nur mit Profi-/Datacenter-Karten samt zusätzlicher Lizenz (z. B. NVIDIA vGPU) möglich – Consumer-GPUs unterstützen kein vGPU-Sharing, lassen sich aber weiterhin per klassischem Passthrough an eine VM durchreichen

Intel Xeon vs. AMD EPYC

Beide funktionieren zuverlässig mit Proxmox – die Entscheidung ist meist eine Frage von Budget, Kernzahl-Bedarf und vorhandenem Server-Ökosystem. Für Live-Migration innerhalb eines Clusters gilt: Intel- und AMD-CPUs lassen sich nicht mischen (unterschiedliche Befehlssatz-Familien), innerhalb einer Herstellerlinie ist ein CPU-Typ wie x86-64-v3 aber auch über mehrere Prozessorgenerationen hinweg migrationsfähig.

ECC-RAM, PCIe-Lanes & NUMA

• ECC-RAM korrigiert Bitfehler selbstständig – für Produktivbetrieb dringend empfohlen, gerade bei ZFS, das große Teile des RAM als Cache (ARC) nutzt und Fehler dort sonst ungeprüft in den Pool übernehmen würde
• Genug PCIe-Lanes einplanen, wenn mehrere Karten (NIC, HBA, GPU) gleichzeitig durchgereicht werden sollen – Consumer-Mainboards haben oft nur 20–24 Lanes, Server-Plattformen dagegen 64–128 oder mehr
• NUMA beachten: VM-Speicher und -Kerne möglichst auf einem NUMA-Knoten halten, sonst Leistungseinbußen durch Zugriffe über den Interconnect zwischen den Sockeln (spürbar vor allem bei speicherintensiven Workloads wie Datenbanken)
• Bei Zwei-Sockel-Systemen: VM-Größe nach Möglichkeit an die Kern-/Speichermenge eines einzelnen NUMA-Knotens anpassen – Proxmox zeigt die NUMA-Topologie unter Node → System → Hardware an
• Faustregel für die RAM-Planung: genug Puffer für ZFS-ARC einrechnen (Standard bis zu 50 % des RAM) und nicht den kompletten Host-Speicher an VMs verplanen

CPU-Typ in der VM

• x86-64-v2/x86-64-v3: gemeinsamer Befehlssatz-Kompromiss (kleinster Nenner moderner CPUs) – Live-Migration auch zwischen unterschiedlichen CPU-Generationen und sogar zwischen Intel und AMD möglich
• Faustregel: gemischter Cluster oder unklare zukünftige Hardware → x86-64-v2/v3, homogener Cluster mit Fokus auf Leistung → host
• Der CPU-Typ lässt sich pro VM in den Hardware-Optionen ändern, wirkt aber erst nach einem Neustart der VM – ein nachträglicher Wechsel ist also möglich, sollte aber getestet werden, bevor er produktiv nötig wird

Redundanz einplanen

• Redundante Netzteile gegen Einzelausfälle – idealerweise an getrennte Stromkreise (im Idealfall an getrennte USV-Systeme) angeschlossen
• IPMI/BMC für Fernwartung und Neustart, auch wenn das Betriebssystem nicht mehr reagiert – erspart nächtliche Anfahrten ins Rechenzentrum und ermöglicht Remote-Konsolenzugriff schon vor dem Betriebssystem-Boot
• Redundante NICs, idealerweise über getrennte Switches, für Netzwerk- und Corosync-Ausfallsicherheit – realisiert über einen Bond (siehe Modul 4 und 6)
• Bei Clustern: eine dedizierte, niedrig-latente Netzwerkverbindung nur für Corosync einplanen (mehr dazu in Modul 7) – Corosync reagiert empfindlich auf Netzwerk-Jitter, geteilte Bandbreite mit VM-Traffic ist ein häufiger Grund für ungewollte Fencing-Ereignisse
• Bei Storage: mindestens zwei Netzteile UND, wo Budget erlaubt, redundante Storage-Controller/HBAs einplanen – ein einzelner HBA-Ausfall sollte nicht gleich den ganzen Node lahmlegen

Das Wichtigste

• x86-64 ist Pflicht, VT-x/AMD-V ebenso – IOMMU zusätzlich für Passthrough (Arm64 bleibt vorerst die Ausnahme)
• Intel Xeon und AMD EPYC funktionieren beide zuverlässig, die Wahl ist meist Budget- und Kernzahl-getrieben, ein Mischbetrieb im selben Cluster ist bei Live-Migration aber nicht möglich
• ECC-RAM, ausreichend PCIe-Lanes und NUMA-Bewusstsein zahlen sich im Betrieb aus – besonders bei ZFS und speicherintensiven VMs
• CPU-Typ „host" vs. „x86-64-v2/v3" entscheidet über die Live-Migrations-Flexibilität – nachträglich änderbar, aber vorher planen erspart spätere Neustarts
• Redundanz (Netzteile, IPMI/BMC, NICs, Storage-Controller) gehört von Anfang an in die Planung, nicht in die Nachrüstung