Sie haben eine Bare-Metal-Maschine und möchten darauf virtuelle Maschinen und Container laufen lassen statt eines einzelnen Betriebssystems. Proxmox VE macht aus dieser nackten Hardware eine vollwertige Virtualisierungsplattform: einen Debian-basierten Host mit Web-UI, vollständiger KVM-Virtualisierung, LXC-Systemcontainern, eingebautem Storage und Networking, und keine Hypervisor-Lizenz pro Socket, die Sie kaufen müssen. Diese Anleitung führt den gesamten Weg von einem leeren Server zu einem funktionierenden Host. Wir installieren Proxmox VE 9.2 von der ISO, korrigieren die APT-Repositories und aktualisieren, verstehen das standardmäßige Bridge-Networking, betrachten den Storage, bauen eine erste VM und einen ersten LXC-Container, und schließen mit grundlegendem Hardening ab. Am Ende haben Sie einen produktionsreifen Single-Node, den Sie später zu einem Cluster ausbauen können.

Eine virtualisierte OPNsense-Firewall auf Ihrem Proxmox-Host bringt Ihnen, wofür Appliance-Hersteller vierstellige Beträge verlangen: eine vollwertige Firewall/Router, die Ihre VMs schützt, mit Snapshots vor jedem Upgrade und ohne zusätzliche Hardware. Der Haken: Die Details der Einrichtung (Bridges, VirtIO, Offloading) entscheiden, ob sie felsenfest läuft oder rätselhaft instabil ist. Dieser Leitfaden behandelt die Netzwerkdesigns, die auf einem Dedicated Server funktionieren, die genaue VM-Konfiguration, auf die sich die Community geeinigt hat, die Installation sowie die ehrlichen Einschränkungen bei Performance und beim Schutz des Proxmox-Hosts selbst.

Proxmox VE bringt alles mit, was Sie brauchen, um nie eine VM zu verlieren, und die Standardeinstellungen nutzen davon fast nichts. Snapshots, die auf derselben Festplatte liegen wie die VM, einmalige vzdump-Archive ohne Retention-Plan, und keine Restore-Tests: So geraten Virtualisierungshosts in der Praxis tatsächlich in Schwierigkeiten. Dieser Leitfaden baut die eigentliche Strategie in drei Stufen auf: wofür Snapshots wirklich da sind, geplante vzdump-Backups, richtig eingerichtet (Modi, Retention, Fleecing), und wann sich Deduplizierung, Verifizierung und Offsite-Sync von Proxmox Backup Server eine zweite Maschine lohnen.

Die ehrlichen Anforderungen an einen Proxmox-Cluster passen in einen Satz: drei Knoten, eine private Verbindung mit niedriger Latenz zwischen ihnen, und Storage, den die überlebenden Knoten erreichen können. Alles andere (Quorum, Fencing, Ceph versus Replikation) ist die Begründung hinter diesen drei Punkten. Dieser Leitfaden erklärt, was Clustering bringt, noch bevor HA überhaupt ins Spiel kommt, warum Quorum drei zur magischen Zahl macht, die Corosync-Netzwerkregeln, gegen die man als Erstes verstößt, die drei Storage-Strategien, und wie ein Failover tatsächlich aussieht, wenn ein Knoten um 3 Uhr nachts ausfällt.

Proxmox VE bietet Ihnen zwei Wege, einen Server aufzuteilen: vollwertige virtuelle Maschinen über KVM und LXC-Systemcontainer, die sich den Kernel des Hosts teilen. Die richtige Wahl pro Workload ist meist klar, sobald Sie die drei Fragen kennen, die darüber entscheiden: Isolation, Kernel und Migration. Dieser Leitfaden erklärt, wie beide tatsächlich funktionieren, vergleicht sie anhand der operativ relevanten Dimensionen, klärt die Docker-Frage mit Proxmox' eigener aktueller Empfehlung und endet mit einer Entscheidungstabelle, die Sie pro Dienst anwenden können.