Proxmox VE im Homelab: der vollständige Einstieg

Proxmox VE ist die naheliegende Wahl, wenn im Homelab mehr als eine virtuelle Maschine laufen soll. Der Einstieg ist einfach – und genau das ist das Problem: Vier oder fünf Entscheidungen fallen während der Installation nebenbei, und drei davon lassen sich später nur mit einer Neuinstallation korrigieren.

Dieser Artikel geht sie der Reihe nach durch und sagt bei jeder dazu, wie teuer eine Korrektur später wird.

Was Proxmox VE eigentlich ist

Ein Debian mit vorkonfiguriertem Unterbau und einer Web-Oberfläche darüber. Das klingt abschätzig, ist aber der Schlüssel zum Verständnis: Alles, was du über Debian weißt, gilt weiter. Paketverwaltung, Netzwerkkonfiguration, systemd, Protokolle – nichts davon ist neu.

Darauf sitzen zwei Virtualisierungstechniken, die man auseinanderhalten muss:

• KVM/QEMU für vollwertige virtuelle Maschinen mit eigenem Kernel.
• LXC für Container, die sich den Kernel des Wirts teilen.

Welche der beiden für welchen Dienst die richtige ist, entscheidet über Ressourcenverbrauch, Migrierbarkeit und Sicherheitsabgrenzung. Das ist eine eigene Frage – siehe VM oder LXC-Container.

Hardware: die drei Punkte, die wirklich zählen

Die Empfehlungslisten in Foren sind lang. Kurz gefasst zählen drei Dinge.

Arbeitsspeicher

Der Engpass ist fast immer der Arbeitsspeicher, nicht die CPU. Eine typische Homelab-Auslastung liegt bei wenigen Prozent Rechenlast, während der Speicher voll belegt ist.

Dazu kommt: Wer ZFS einsetzt, gibt zusätzlich Arbeitsspeicher für den Lesecache ab. Wie viel, hängt davon ab, woher die Installation stammt – und genau das wird regelmäßig verwechselt:

Installation	Vorgabe für den ARC
Neuinstallation mit ZFS-Wurzel ab Proxmox VE 8.1	10 % des Arbeitsspeichers, höchstens 16 GiB
Ältere oder hochgezogene Installation	die ZFS-Vorgabe: die Hälfte des Arbeitsspeichers
Pool, der außerhalb des Installers angelegt wurde	ebenfalls die Hälfte

Beim Einkauf ist der Unterschied erheblich: Bei 64 GiB sind es je nach Zeile gut 6 GiB oder 32 GiB, die den Gästen nicht zur Verfügung stehen. Festlegen lässt sich der Wert in beiden Fällen über zfs_arc_max – und die zweite Zeile ist der Grund, warum ein über Jahre hochgezogener Knoten plötzlich als speicherhungrig gilt, obwohl sich an ihm nichts geändert hat.

ECC oder nicht? Für ein Homelab ist ECC-Speicher wünschenswert, aber kein Ausschlusskriterium – außer bei ZFS mit wichtigen Daten. ZFS erkennt Fehler auf dem Datenträger zuverlässig; einen Bitfehler im Arbeitsspeicher erkennt es nicht und schreibt ihn im schlimmsten Fall mit korrekter Prüfsumme fest.

Datenträger

Ein Consumer-SSD als Systemdatenträger unter ZFS ist der häufigste teure Fehler. ZFS schreibt Metadaten synchron und häufig; Laufwerke ohne Notstromkondensator müssen dafür jedes Mal ihren internen Cache leeren. Das kostet Leistung und Lebensdauer gleichermaßen.

Praktische Reihenfolge:

1. System auf ein kleines, ausdauerndes Laufwerk – gebrauchte Rechenzentrums-SSDs sind hier oft günstiger als neue Consumer-Ware und deutlich haltbarer.
2. Gastsysteme auf schnellen Speicher.
3. Massendaten auf drehende Platten, wenn die Kapazität sonst zu teuer wird.

Wie viel nutzbare Kapazität ein bestimmter Verbund ergibt, rechnet der RAID- und ZFS-Kapazitätsrechner aus.

Stromverbrauch

Ein Homelab läuft rund um die Uhr. Bei den in Österreich üblichen Arbeitspreisen kostet jedes dauerhaft gezogene Watt im Jahr spürbar Geld – ein Gerät, das dauerhaft 20 Watt mehr zieht als nötig, summiert sich über die übliche Nutzungsdauer auf einen dreistelligen Betrag.

Rechne es für deinen Fall aus, bevor du kaufst: Stromkostenrechner. Er sagt auch, ab wann sich der Tausch eines vorhandenen Geräts gegen ein sparsameres rechnet.

Installation: die Entscheidungen, die bleiben

Der Installationsassistent ist in wenigen Minuten durch. Drei Angaben darin sind später teuer zu korrigieren.

Dateisystem des Systemdatenträgers

Zur Wahl stehen im Wesentlichen ext4 auf LVM und ZFS.

	ext4 auf LVM	ZFS
Speicherbedarf	gering	hoch (ARC)
Prüfsummen über Nutzdaten	nein	ja
Snapshots des Wirtsystems	eingeschränkt	ja
Replikation zwischen Knoten	nein	ja
Spiegelung ohne RAID-Controller	über mdadm	eingebaut

Die Entscheidung fällt praktisch an einer Stelle: Willst du später mehrere Knoten ohne gemeinsamen Speicher betreiben, brauchst du ZFS – die eingebaute Replikation setzt darauf auf. Details in Proxmox-Cluster ohne Shared Storage.

Nachträglich wechselt man das Wurzeldateisystem nicht. Das ist eine Neuinstallation.

Wie viel Platz das System bekommt

Der Assistent bietet an, die Aufteilung anzupassen. Wer das überspringt, bekommt eine Vorgabe, die auf großen Datenträgern viel Platz im Systembereich bindet.

Wenn Gastsysteme später ohnehin auf einem anderen Datenträger liegen, ist das gleichgültig. Liegt alles auf einer Platte, lohnt der Blick.

Hostname und Netzadresse

Beides ist nachträglich änderbar, aber unangenehm: Der Hostname steckt in der Zertifikatsverwaltung und – sobald ein Verbund existiert – in der Clusterkonfiguration. In einem bestehenden Cluster ist die Umbenennung eines Knotens kein unterstützter Vorgang. Nimm dir die halbe Minute und überlege dir das Namensschema vorher.

Nach der Installation: vier Schritte

1. Paketquellen richtigstellen

Ohne Abonnement zeigt die Oberfläche bei jeder Anmeldung einen Hinweis, und die voreingestellte Unternehmensquelle liefert keine Aktualisierungen. Für ein Homelab stellt man auf die abonnementfreie Quelle um.

Wichtig zum Verständnis: Das ist keine Testversion und kein eingeschränkter Funktionsumfang. Der Unterschied liegt in der Prüftiefe der Pakete und im Anspruch auf Unterstützung, nicht in den Funktionen.

# Danach in jedem Fall einmal vollständig aktualisieren:
apt update && apt full-upgrade

2. Netz verstehen, bevor du es änderst

Nach der Installation existiert eine Linux-Bridge, üblicherweise vmbr0. Sie hängt an der physischen Netzwerkkarte, die Gäste hängen an ihr, und der Wirt selbst hat seine Adresse ebenfalls auf der Bridge.

Daraus folgt die wichtigste Regel für den Anfang: Änderungen am Netz können dich aussperren. Es gibt keinen Weg zurück außer Bildschirm und Tastatur am Gerät.

VLANs sind eine sinnvolle nächste Ausbaustufe, aber nicht am ersten Tag. Wer die Adressbereiche vorher planen will, findet die Aufteilung im Subnetzrechner.

3. Speicher einrichten

Proxmox unterscheidet Datenspeicher nach dem, was sie aufnehmen können – und das ist der Punkt, an dem Einsteiger hängen bleiben.

Art	Nimmt auf	Snapshots
LVM-Thin	Datenträgerabbilder, Container	ja
ZFS	Datenträgerabbilder, Container	ja
Verzeichnis	alles, u. a. Vorlagen, ISO-Abbilder, Sicherungen	nur mit qcow2
NFS / SMB	wie Verzeichnis	nur mit qcow2

Ein Verzeichnis-Datenspeicher kann alles, ist aber langsamer. Blockspeicher wie LVM-Thin und ZFS sind schneller, nehmen aber keine ISO-Abbilder und keine Vorlagen auf. Die meisten Installationen brauchen deshalb beides.

Welche Kombination Snapshots erlaubt, ist keine Nebensächlichkeit – siehe Proxmox-Snapshots richtig nutzen.

4. Zugänge trennen

Der Benutzer root mit Kennwortanmeldung ist der Auslieferungszustand, nicht das Ziel. Sinnvoll ist:

• ein eigener Benutzer in der Proxmox-eigenen Benutzerverwaltung,
• Zwei-Faktor-Anmeldung für alle Zugänge mit Verwaltungsrechten,
• die eingebaute Firewall aktiviert – sie ist im Auslieferungszustand aus.

Das kostet zwanzig Minuten und erspart die unangenehmste Klasse von Vorfällen. Warum das gerade bei der Datensicherung zählt, steht in Ransomware-sichere Backups.

Der erste Gast

Für einen ersten Versuch: ein LXC-Container aus einer fertigen Vorlage. Er ist in unter einer Minute gestartet und zeigt die Oberfläche an etwas Echtem.

# Verfügbare Vorlagen auflisten und eine herunterladen
pveam update
pveam available | grep debian
pveam download local debian-<version>-standard_<stand>_amd64.tar.zst

Danach in der Oberfläche „Create CT“. Die Vorgabewerte sind für einen ersten Test brauchbar; anzupassen ist eigentlich nur die Größe des Wurzeldatenträgers.

Für eine virtuelle Maschine lädst du ein ISO-Abbild in einen Verzeichnis-Datenspeicher und legst über „Create VM“ an. Zwei Angaben lohnen dort die Aufmerksamkeit:

• Maschinentyp q35 und UEFI (OVMF) statt der älteren Vorgabe, sobald Gerätedurchreichung ein Thema werden könnte – siehe GPU-Passthrough unter Proxmox.
• VirtIO für Datenträger und Netzwerkkarte. Emulierte Geräte funktionieren überall, kosten aber deutlich Leistung. Windows braucht dafür die passenden Treiber schon während der Installation.

Was am Anfang schiefgeht

Die Sicherung wird zuletzt eingerichtet. Das ist die Reihenfolge, die im Ernstfall weh tut. Ein Proxmox Backup Server ist an einem Nachmittag aufgesetzt, und ab dann sichert die Umgebung sich selbst: Proxmox Backup Server einrichten.

Snapshots werden für Sicherungen gehalten. Sie liegen auf demselben Speicher wie das Original. Stirbt der, sind beide weg. Der Unterschied ist in der 3-2-1-Backup-Strategie sauber auseinandergelegt.

Zu viel auf einmal. Wer am ersten Tag Cluster, VLANs, Gerätedurchreichung und Hochverfügbarkeit gleichzeitig angeht, sucht am dritten Tag einen Fehler, der aus vier Richtungen kommen kann. Eine Ausbaustufe nach der anderen, und nach jeder eine Sicherung.

Der Speicherplatz läuft still voll. Thin-Provisioning meldet den Gästen mehr Platz, als vorhanden ist. Das ist gewollt und praktisch – bis der Datenspeicher tatsächlich voll ist und alle Gäste gleichzeitig stehen. Eine Überwachung mit Benachrichtigung ist kein Luxus: Backups überwachen beschreibt das Muster, das sich hier genauso anwenden lässt.

Die Reihenfolge, die sich bewährt hat

1. Installieren, Paketquellen richtigstellen, aktualisieren.
2. Speicher einrichten, Zugänge trennen, Firewall an.
3. Sicherung einrichten und einen Restore ausprobieren – erst danach zieht etwas Wichtiges ein. Wie so ein Test aussieht, steht in Restore testen.
4. Die ersten Dienste als Container, alles mit eigenem Kernelbedarf als VM.
5. Erst dann: VLANs, zweiter Knoten, Gerätedurchreichung.

Weiter im Cluster

• VM oder LXC-Container – die Entscheidung pro Dienst
• Proxmox-Snapshots richtig nutzen – und warum sie keine Sicherung sind
• Proxmox-Cluster ohne Shared Storage – der zweite Knoten
• GPU-Passthrough unter Proxmox – die Ausbaustufe mit dem größten Fehlerpotenzial
• Proxmox Backup Server einrichten – der Schritt, der zu früh nach hinten geschoben wird