10 Proxmox-Fehler, die Sie vermeiden sollten (und was Sie stattdessen tun sollten)

Wenn Sie sich jemals in das Kaninchenloch der Homelabs begeben haben, kennen Sie wahrscheinlich Proxmox, die beliebte Open-Source-Virtualisierungsplattform. Sie ist leistungsstark, flexibel und komplett kostenlos. Doch diese Freiheit bringt auch eine Lernkurve mit sich, die zurückbeißt, wenn Sie nicht aufpassen.

Ein Nutzer beschloss, anderen diesen Schmerz zu ersparen, und veröffentlichte eine Mini-Anleitung mit hart erarbeiteten Lektionen aus eigener Erfahrung. Sein frei zugänglicher PDF-Guide umreißt 10 verbreitete Proxmox-Fehler, und die Reaktion der Community war eine Mischung aus "danke" und "kenne ich auch." Es stellt sich heraus, dass das keine reinen Anfängerfehler sind, denn selbst erfahrene Nutzer haben sich bei einigen davon an die Stirn geschlagen. Hier sind diese 10 Proxmox-Fallstricke im Detail, ergänzt um Kommentare und Kontext aus der breiteren Proxmox-Community.

1. ZFS ohne richtige RAM-Planung

ZFS ist unglaublich, bis es Ihr System bei lebendigem Leib auffrisst. Die alte Faustregel lautet ein Gigabyte RAM pro Terabyte Rohspeicher. Ignorieren Sie das, kann ZFS Ihre Performance in den Keller ziehen oder Ihr System gleich komplett zum Absturz bringen.

Ein Nutzer wies auf Verwirrung rund um diese Regel hin und zeigte Unstimmigkeiten in der eigenen Rechnung des Autors auf. Die Kernaussage bleibt aber: Wenn Sie ZFS nutzen, müssen Sie bei Ihrer Speicherzuweisung bewusst vorgehen. Und wenn Ihr System unter 16 GB RAM hat, ist ZFS vielleicht nicht die beste Wahl. Berechnen Sie also Ihr Verhältnis von Speicher zu RAM und überlegen Sie, ob L2ARC oder SLOG sinnvoller ist, als einfach mehr Arbeitsspeicher nachzurüsten.

2. Der Mythos "ECC ist Pflicht"

Ah, die ewige ECC-Debatte. Manche behaupten, ZFS ohne ECC-RAM sei die Einladung zur Datenkorruption. Andere nennen das Panikmache.

Ein Beitragender hat es am besten auf den Punkt gebracht: ECC verhindert keine Bitflips, es protokolliert und korrigiert sie. Ohne ECC kann es zu stiller Datenkorruption kommen, garantiert ist sie aber nicht. Am Ende hängt es davon ab, wie wichtig Ihnen Ihre Daten sind und wie kugelsicher Sie Ihr System haben wollen. Sind die Daten wirklich wichtig, investieren Sie in ECC. Experimentieren Sie nur, zählen Backups und ein kluges Design mehr, als sich am RAM-Typ festzubeißen.

3. RAIDZ für VM-Speicher verwenden

RAIDZ ist für große, sequenzielle Dateien gebaut, also für Medienbibliotheken oder Backups. Für VMs eignet es sich weniger, weil RAIDZ Stripes über mehrere Disks schreibt und zufälliges I/O damit zum Flaschenhals wird.

Proxmox-Veteranen sagen, das sei ein verbreiteter Anfängerfehler. Für VM-lastige Setups bieten gestripte Mirrors (ZFS-Mirrors) weit bessere Performance und Ausfallsicherheit. Verwenden Sie also Mirrors oder sogar gestripte ZFS-Mirrors (ein RAID10-ähnliches Setup) für Ihre VMs und heben Sie sich RAIDZ für Cold Storage auf.

4. Local-LVM als unflexibel abtun

Viele Nutzer gehen davon aus, dass Local-LVM zu starr ist, um nützlich zu sein. Dabei ist es oft die schnellste Speichermethode ab Werk, und für kleine Deployments funktioniert es einwandfrei.

Ja, es fehlen Snapshots und die fortgeschrittenen Funktionen, die ZFS bietet, aber es ist stabil und einfach. Beginnen Sie ruhig mit Local-LVM, wenn Sie keinen Schnickschnack brauchen. Sie können später immer noch migrieren, wenn Ihre Anforderungen wachsen.

5. Die Falle des CPU-Typs "Host"

Auf dem Papier klingt es großartig, für Ihre VM genau die CPU-Funktionen des Hosts zu nutzen, weil das maximale Performance versprechen soll. Der Haken: Sie können diese VM nicht auf eine andere Maschine migrieren, wenn die CPU nicht identisch ist.

Ein Nutzer wies auf noch größere Probleme hin. Bei Verwendung der CPU "Host" fehlen die Gegenmaßnahmen für Spectre und Meltdown möglicherweise, sofern sie nicht manuell konfiguriert werden. Wählen Sie deshalb ein generisches CPU-Modell wie x86-64-v2-AES, um Performance und Kompatibilität auszubalancieren, und verwenden Sie "host" nur, wenn Sie absolut sicher sind, dass die VM nicht migrieren muss.

6. HA einrichten, ohne die Voraussetzungen zu erfüllen

Proxmox HA (High Availability) ist kein Plug-and-Play. Viele Nutzer richten es mit zwei Nodes und ohne Quorum-Device ein, was ein Rezept für Split-Brain-Situationen ist.

Sie brauchen drei Stimmen für ein Quorum. Das bedeutet in der Regel drei physische Nodes oder zwei Nodes plus ein QDevice. Sparen Sie hier, landen Sie am Ende mit VMs, die im Nichts hängen, oder mit zwei Nodes, die versuchen, dieselbe VM auszuführen. Nehmen Sie also drei Nodes oder zwei Nodes plus ein QDevice, und stellen Sie sicher, dass Fencing richtig konfiguriert ist.

7. Unvollständige Backup-Strategie

Backups sind nicht verhandelbar. Ein einziger Fehltritt, und Ihre gesamte VM könnte verschwinden.

Der Guide betont, dass Sie neben dem Wo und Wann eines Backups auch planen sollten, wie Sie es wiederherstellen. Ein Nutzer ergänzte einen entscheidenden Punkt: Testen Sie Ihre Backups immer. Ein Backup, das sich nicht wiederherstellen lässt, ist nur ein Briefbeschwerer. Automatisieren Sie deshalb tägliche oder wöchentliche Backups, speichern Sie sie remote oder zumindest off-disk, und führen Sie hin und wieder Test-Restores durch.

8. Docker direkt auf Proxmox betreiben

Dieser Punkt löste einen Chor aus "warum würde jemand…" aus, und trotzdem kommt es überraschend häufig vor. Docker auf dem Proxmox-Host laufen zu lassen vermischt Container und Hypervisor, was ein Albtraum für Stabilität und Sicherheit ist.

Die Empfehlung ist einfach: isolieren. Führen Sie Docker entweder in einem LXC-Container aus, oder starten Sie eine schlanke VM nur für das Container-Management (Hallo an alle Portainer- oder Rancher-Fans). Hauptsache, Docker läuft in einer VM oder einem LXC statt direkt auf dem nackten Proxmox-Node, damit Ihr Hypervisor sauber bleibt.

9. Kein Monitoring, bis etwas kaputtgeht

Das ist der "stille Killer." Die meisten Nutzer verzichten auf Monitoring, bis etwas explodiert, und bis dahin sind die Logs vielleicht schon nutzlos.

Der ursprüngliche Guide streift grundlegendes Monitoring, aber manche Community-Mitglieder plädieren für fortgeschrittenere Setups: SNMP-Traps, E-Mail-Alerts, Prometheus und Grafana, oder zumindest eine agentenbasierte Lösung. Richten Sie Monitoring von Tag eins an ein, denn selbst einfache E-Mail-Alerts sind besser als nichts.

10. Dienste direkt auf dem Hypervisor bereitstellen

Sie würden Ihre Apps ja auch nicht auf dem Motorblock Ihres Autos installieren, warum also Dienste auf Ihrem Hypervisor bereitstellen?

Proxmox ist keine allgemeine Linux-Distro, es ist als schlank und fokussiert gedacht. Zusätzliche Dienste vergrößern Ihre Angriffsfläche und machen Updates riskanter. Packen Sie Ihre Dienste also in VMs oder Container und lassen Sie den Hypervisor in Ruhe.

Ehrenvolle Erwähnungen aus der Community

• Windows-VMs klonen, ohne Sysprep auszuführen.
• LXC-Storage-Pools löschen, die noch referenziert werden.
• Auf Zeitsynchronisation verzichten, was besonders kritisch für die TOTP-Authentifizierung ist.
• Den externen Netzteilen von Minisforum-Servern vertrauen (tauschen Sie diese frühzeitig aus!).

Fazit

Proxmox ist wie eine leere Leinwand: Sie können etwas Großartiges erschaffen, oder Sie können sich selbst in eine Ecke malen. Der Trick besteht darin, die richtigen Lektionen schnell zu lernen, statt darauf zu hoffen, Fehler komplett zu vermeiden. Und dank der Offenheit eines Nutzers und der leidenschaftlichen Tiefenrecherche einer Community müssen Sie nicht alles auf die harte Tour lernen.

Also halten Sie kurz inne, bevor Sie das nächste Mal qm create oder zfs pool create ausführen, lesen Sie das hier noch einmal und ersparen Sie sich das Drama. Das Einzige, was schlimmer ist als eine beschädigte VM, ist die Erkenntnis, dass Sie sie selbst verursacht haben.