Proxmox VE – Installation, Cluster und Verwaltung

Was ist Proxmox VE und warum landet es in immer mehr KMU-Racks?

Proxmox Virtual Environment (PVE) ist eine Open-Source-Virtualisierungsplattform auf Debian-Basis, die zwei Welten unter einer Web-Oberfläche vereint: vollwertige VMs via KVM/QEMU und ressourcenschonende Linux-Container via LXC. Seit der Broadcom-Übernahme von VMware und den daraus resultierenden Lizenzänderungen ist Proxmox für Schweizer KMU zur naheliegenden Alternative geworden – kein Vendor-Lock-in, keine Core-basierte Lizenzierung, eine Subscription ist optional und dient primär dem Enterprise-Repository plus Support.

Proxmox selbst ist kein eigener Hypervisor, sondern eine Management-Schicht über bewährten Linux-Bausteinen: KVM für Hardware-Virtualisierung, LXC für Container, ZFS oder Ceph für Storage, Corosync für Cluster-Kommunikation. Das macht die Plattform transparent – wer die Weboberfläche wegdenkt, findet darunter ein ganz normales Debian mit systemd-Diensten, das du bei Bedarf auch per SSH und CLI vollständig steuern kannst.

Installation: ISO, Netzwerk und erste Schritte

Der Standardweg ist die Installation via offiziellem ISO (proxmox.com/downloads) auf Bare-Metal-Hardware. Der Installer ist ein textbasiertes/grafisches Debian-Derivat und fragt dabei direkt nach dem Ziel-Dateisystem für die Root-Disk.

Ablauf der Grundinstallation

1. ISO auf USB-Stick schreiben (z. B. mit Rufus oder dd unter Linux)
2. Boot vom Stick, “Install Proxmox VE” wählen
3. Ziellaufwerk und Dateisystem festlegen: ext4, xfs oder zfs (RAID0/1/10/Z1/Z2)
4. Land, Zeitzone, Tastaturlayout
5. Root-Passwort und Admin-E-Mail (für Benachrichtigungen)
6. Management-Netzwerk konfigurieren: Hostname (FQDN!), statische IP, Gateway, DNS
7. Installation abschliessen, Neustart, Web-UI aufrufen unter https://<ip>:8006

Nach der Installation ist die erste Amtshandlung meist der Wechsel des Repositories, da Proxmox ohne aktive Subscription standardmässig versucht, das Enterprise-Repo zu nutzen und dabei Fehler beim apt update wirft:

# Enterprise-Repo deaktivieren
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list

# No-Subscription-Repo eintragen (Proxmox VE 8, Debian Bookworm)
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" \
  > /etc/apt/sources.list.d/pve-no-subscription.list

apt update && apt dist-upgrade -y

Die Web-UI selbst gliedert sich in einen Baum links (Rechenzentrum → Node → VMs/Container) und Tabs rechts (Zusammenfassung, Hardware, Optionen, Backup, Firewall, Konsole). Für die Konsole stehen noVNC (Browser) und SPICE zur Auswahl – SPICE bietet bessere Performance und Copy-Paste, braucht aber einen lokalen SPICE-Client.

ZFS und Storage-Pools

ZFS ist unter Proxmox der De-facto-Standard für lokalen Storage, weil es Volume-Management, Software-RAID, Checksumming und Snapshots in einer Schicht vereint. Der Installer kann ZFS direkt für die Root-Disk verwenden, was sich in produktiven Umgebungen fast immer lohnt.

RAID-Level in ZFS-Terminologie

Wichtige ZFS-Praxis-Befehle für den Alltag:

# Pool-Status prüfen (Scrub-Ergebnis, Fehler, Disk-Zustand)
zpool status -v

# Wöchentlichen Scrub einplanen (Datenintegrität prüfen)
systemctl enable --now zfs-scrub-weekly@rpool.timer

# Datasets und deren Belegung anzeigen
zfs list -o name,used,avail,refer,mountpoint

# Snapshot manuell erstellen
zfs snapshot rpool/data/vm-101-disk-0@vor-update

# Compression aktivieren (lz4 ist Standard und praktisch kostenlos)
zfs set compression=lz4 rpool/data

# ARC (Cache) auf max. 8 GB begrenzen – wichtig bei RAM-knappen Hosts
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
update-initramfs -u

Neben ZFS unterstützt Proxmox auch klassisches LVM/LVM-Thin (schneller bei wenig RAM, aber ohne Checksumming), Directory-Storage (einfache Dateisysteme für ISO/Backup) sowie im Cluster-Kontext Ceph (verteilter Storage über alle Nodes) und NFS/iSCSI für externe SAN/NAS-Anbindung. Die Storage-Konfiguration liegt zentral in /etc/pve/storage.cfg und ist über die Web-UI unter Rechenzentrum → Storage verwaltbar.

Cluster-Aufbau: Corosync und Quorum

Ein Proxmox-Cluster verbindet mehrere Nodes zu einer gemeinsam verwalteten Einheit. Die Konfiguration (/etc/pve/) wird über das verteilte Dateisystem pmxcfs (basierend auf Corosync) auf allen Nodes synchron gehalten – änderst du eine VM-Konfiguration auf Node A, ist sie sofort auf Node B sichtbar.

Quorum – das Herzstück der Cluster-Stabilität

Corosync arbeitet nach dem Mehrheitsprinzip: Ein Cluster ist “quorate” (entscheidungsfähig), wenn mehr als die Hälfte der Stimmen (Votes) online und erreichbar sind. Jeder Node bringt standardmässig eine Stimme mit. Verliert ein Cluster das Quorum (z. B. bei einer Netzwerktrennung), werden auf den isolierten Nodes automatisch alle Cluster-relevanten Operationen blockiert – neue VMs starten, HA-Aktionen und Konfigurationsänderungen sind gesperrt, um ein Split-Brain-Szenario zu verhindern.

Quorum erreicht, wenn: aktive Votes > Gesamtvotes / 2

Cluster erstellen und Node hinzufügen

# Auf dem ersten Node (pve01): Cluster initialisieren
pvecm create kmu-cluster

# Status prüfen
pvecm status

# Auf einem weiteren Node (pve02): dem Cluster beitreten
pvecm add 10.10.10.11

QDevice einrichten (auf einem separaten, dritten System, z. B. einem kleinen Debian-VM ausserhalb des Clusters):

# Auf dem QDevice-Host
apt install corosync-qnetd

# Auf einem PVE-Node im Cluster
apt install corosync-qdevice
pvecm qdevice setup 10.10.10.20

Backup mit Proxmox Backup Server (PBS)

Proxmox Backup Server ist die dedizierte Backup-Lösung des Proxmox-Ökosystems – separat installierbar (eigenes ISO) auf einer eigenen Maschine oder VM. Der entscheidende Vorteil gegenüber einfachen vzdump-Dateien auf einem NAS: PBS arbeitet blockbasiert-inkrementell mit clientseitiger Deduplizierung. Nach dem ersten vollen Backup werden nur noch geänderte 4-MiB-Chunks übertragen, was Backup-Fenster und Netzwerklast drastisch reduziert.

Architektur in Kürze

• PBS-Datastore: Verzeichnis (idealerweise auf ZFS) mit Chunk-Store und Index
• Deduplizierung: SHA-256-Hashing pro Chunk, identische Chunks werden nur einmal gespeichert
• Verschlüsselung: optional clientseitig (AES-256), sodass selbst der Backup-Server die Daten nicht lesen kann
• Pruning/GC: Retention-Regeln (z. B. keep-daily 7, keep-weekly 4, keep-monthly 6) plus regelmässiger Garbage Collection zum Freigeben ungenutzter Chunks

# PBS: Datastore anlegen (auf eigenem ZFS-Pool "backup")
proxmox-backup-manager datastore create kmu-backup /backup/pbs-store

# Retention-Regel setzen
proxmox-backup-manager datastore update kmu-backup \
  --prune-options "keep-daily=7,keep-weekly=4,keep-monthly=6,keep-yearly=2"

Auf Proxmox-VE-Seite bindest du den PBS als Storage ein (Rechenzentrum → Storage → Hinzufügen → Proxmox Backup Server) und legst dann einen Backup-Job an:

# CLI-Variante: Backup-Job für alle VMs täglich um 02:30
pvesh create /cluster/backup --schedule "02:30" --all 1 \
  --storage kmu-backup --mode snapshot --compress zstd

Restore läuft granular: einzelne Dateien aus einem VM-Backup lassen sich über den integrierten File-Browser direkt im Web-UI wiederherstellen, ohne die ganze VM zurückspielen zu müssen – ein Feature, das bei “ich brauche nur die eine Excel-Datei von letzter Woche”-Tickets viel Zeit spart.

LXC-Container vs. virtuelle Maschinen

Proxmox bietet zwei fundamental unterschiedliche Virtualisierungsarten nebeneinander an, und die Wahl zwischen ihnen ist eine der wichtigsten Architekturentscheidungen im Alltag.

Sicherheitstechnisch gilt: LXC-Container teilen sich den Host-Kernel, ein Kernel-Exploit im Container kann theoretisch auf den Host durchschlagen. Proxmox unterscheidet deshalb zwischen privilegierten Containern (Root im Container = Root auf dem Host, nur für vertrauenswürdige Workloads) und unprivilegierten Containern (Standard seit PVE 4, User-Namespace-Mapping schottet Root im Container vom Host-Root ab). Für alles, was mit dem Internet spricht oder von Dritten verwaltet wird, gehören unprivilegierte Container zum Minimalstandard.

Live Migration und HA-Gruppen

Live Migration verschiebt eine laufende VM ohne spürbare Downtime von einem Node zum anderen – Speicherinhalt (RAM) wird iterativ über das Netz kopiert, während die VM weiterläuft, bis nur noch eine minimale Differenz übrig bleibt, die im letzten Schritt (Stop-and-Copy) synchronisiert wird.

Voraussetzung für “echte” Live Migration ohne Storage-Kopie ist gemeinsamer Storage (Ceph, NFS, iSCSI) oder – seit neueren PVE-Versionen – Storage-Migration mit lokalem ZFS via Replikation. Ist kein shared Storage vorhanden, migriert Proxmox trotzdem, kopiert dann aber die komplette Disk mit, was deutlich länger dauert und mehr Netzwerklast erzeugt.

# Live-Migration per CLI
qm migrate 101 pve02 --online

# ZFS-Replikation als Basis für Migration ohne Shared Storage einrichten
pvesr create-local-job 101-0 pve02 --schedule "*/15"

High Availability (HA) und HA-Gruppen

HA sorgt dafür, dass eine VM/ein Container bei einem Node-Ausfall automatisch auf einem anderen Node im Cluster neu gestartet wird. Voraussetzung ist ein Cluster mit mindestens drei Nodes (wegen Quorum, siehe oben) und – für echte Live-Migration statt Neustart – shared Storage.

HA-Gruppen definieren, welche Nodes für eine Ressource überhaupt infrage kommen, inklusive Priorität:

# HA-Gruppe mit Node-Prioritäten anlegen
ha-manager groupadd prod-gruppe --nodes "pve01:2,pve02:2,pve03:1"

# VM 101 der HA-Gruppe zuordnen und HA aktivieren
ha-manager add vm:101 --group prod-gruppe --max_restart 3 --max_relocate 2

Der Ablauf bei einem Node-Ausfall in Kurzform:

1. Corosync erkennt den Node als nicht erreichbar (Watchdog-Timeout, Standard ca. 60 Sekunden)
2. Der ausgefallene Node wird über Fencing zuverlässig als “tot” bestätigt (Watchdog-basiert, kein externes Fencing-Gerät nötig wie bei klassischen Linux-Clustern)
3. Der HA-Manager wählt anhand der Gruppen-Priorität und verfügbarer Ressourcen einen neuen Ziel-Node
4. Die VM wird dort aus dem letzten konsistenten Zustand (shared Storage) gestartet
5. max_restart und max_relocate verhindern Neustart-Schleifen bei dauerhaft defekten VMs

Entscheidungsbaum: Wann lohnt sich Proxmox im KMU?

Brauchst du Windows-Lizenzvorteile durch Hyper-V (Windows Server ohnehin vorhanden)?
├── Ja, und Budget für Windows-Server-Lizenzen ist da
│   → Hyper-V prüfen (siehe /wiki/hyper-v-grundlagen)
└── Nein
    ├── Ist bereits VMware-Know-how/Infrastruktur vorhanden und Budget für Broadcom-Lizenzen kein Thema?
    │   → VMware vSphere bleibt eine Option
    └── Sonst: Proxmox VE
        ├── Nur 1 Host, kein Cluster nötig → Proxmox Standalone mit ZFS-Mirror
        ├── 2 Hosts, HA gewünscht → Proxmox-Cluster + QDevice (Pflicht!)
        └── 3+ Hosts, produktiv kritisch → Proxmox-Cluster + Ceph oder shared Storage + HA-Gruppen

Typische Fallstricke im Betrieb

• Zeitsynchronisation im Cluster: Corosync reagiert empfindlich auf Zeitversatz zwischen Nodes. Chrony/NTP auf allen Nodes gegen dieselbe Quelle synchronisieren.
• Volle Root-Disk durch Logs: /var/log/pve und Journal können bei aktivem Cluster-Betrieb wachsen. journalctl --vacuum-time=2weeks regelmässig einplanen oder per Cronjob automatisieren (siehe Cron-Jobs).
• Firewall-Regeln pro Node vs. Cluster-weit: Die Proxmox-Firewall kennt Ebenen (Datacenter, Node, VM) – eine restriktive Datacenter-Regel kann unerwartet auch Cluster-internen Traffic blockieren, wenn Ports nicht sauber freigegeben sind.
• Subscription-Nag-Screen: Ohne Subscription erscheint beim Login ein Hinweisfenster. Rein kosmetisch, aber für manche Kunden-Demos störend – lässt sich per Skript unterdrücken (funktional aber irrelevant für den Betrieb).
• Storage-Migration unterschätzt: Wechsel von LVM-Thin zu ZFS auf einem produktiven Node erfordert vollständiges Neuaufsetzen des Storage – vorher planen, nicht nachträglich “mal eben” migrieren.

Weiterlernen

• Proxmox VE Administration Guide (offizielle Doku)
• Proxmox Cluster Manager – Quorum und Corosync im Detail
• Proxmox Backup Server Dokumentation
• Proxmox VE Firewall-Dokumentation
• OpenZFS Dokumentation
• Proxmox High Availability – offizielles Wiki

Verwandte Themen im Wiki: Virtualisierung Grundlagen, Virtualisierung Hochverfügbarkeit, Hyper-V Grundlagen, VMware ESXi Grundlagen, RAID-Level im Detail, Backup-Strategie 3-2-1-Regel.

Videos

YouTube