Alle Artikel

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.

Proxmox VE ist eine kostenlose Open-Source-Virtualisierungsplattform, die direkt auf einem physischen Server läuft und eine Maschine zum Host für vollständige virtuelle Maschinen und leichtgewichtige Container macht. Doch es ist nicht der einzige Bare-Metal-Hypervisor: VMware ESXi, XCP-ng und Hyper-V lösen dasselbe Problem jeweils anders, und die richtige Wahl hängt weit mehr von Lizenzierung, Clustering und dem Ökosystem Ihres Teams ab als von reinen Funktionen. Dieser Leitfaden erklärt, was Proxmox VE eigentlich ist, was ein Bare-Metal-Hypervisor bedeutet, und wie die vier wichtigsten Kandidaten bei Kosten, Verwaltung, High Availability, Storage und Backup abschneiden, mit einer Vergleichstabelle, einem klar positionierten Entscheidungsrahmen und Links zum passenden Server für die Bereitstellung.

Beim Netzwerk scheitern die meisten neuen Proxmox-Installationen: Die Installation klappt, die erste VM startet, und dann wird aus "wie gebe ich ihr eine IP?" ein Nachmittag mit halb passenden Forenbeiträgen. Das zugrunde liegende Modell ist eigentlich klein: VMs docken an Linux-Bridges an, und alles andere sind Variationen davon. Dieser Leitfaden baut dieses Modell sauber auf: was vmbr0 wirklich ist, Bridged- versus Routed- versus NAT-Setups bei einem Hosting-Provider, VLAN-aware Bridges, richtig konfiguriertes Bonding, wo die SDN-Schicht ansetzt, und wie Sie all das ändern, ohne sich selbst auszusperren.

Almost every Proxmox-vs-ESXi comparison is written for a homelab or by a backup vendor. This one is written for the person renting a dedicated server or running a small hosting fleet, where the constraints are IPMI-only recovery, single-tenant hardware, no SAN, and network configured at the host. It covers what the Broadcom licensing shift actually changed, what the reintroduced free ESXi can and cannot do, the bare-metal architecture differences that matter, the multi-node failure modes that bite in production (and their fixes), honest per-node cost math, and where ESXi still wins.

Shortlists nach VMware laufen meist auf diese zwei hinaus: Proxmox VE, die Debian/KVM-Plattform mit allem integriert, und XCP-ng, der Xen-basierte Nachfolger von XenServer, den Sie über Xen Orchestra verwalten. Beide sind echt produktionsreif und echt kostenlos; sie verkörpern nur unterschiedliche Philosophien darüber, wie eine Virtualisierungsplattform aufgebaut sein sollte. Dieser Vergleich behandelt die architektonische Trennung (KVM-in-Linux vs Xen-plus-dom0), die sehr unterschiedlichen Management- und Support-Modelle, Storage- und Backup-Konzepte, aktuelle Preise auf beiden Seiten und ein Urteil mit Bedingungen.