Eine physische Maschine, mehrere getrennte Systeme.
Ein physischer Server besitzt Prozessoren, RAM, Datenträger und Netzwerkanschlüsse. Virtualisierung stellt diese Ressourcen mehreren Gästen in kontrollierter Form bereit. So kann eine Linux-Testumgebung unabhängig vom Dateiserver neu gestartet werden. Die gemeinsame Hardware bleibt trotzdem eine gemeinsame Ausfallstelle; virtuelle Trennung schafft keine zusätzliche physische Maschine.
Wir betrachten Proxmox Virtual Environment (VE) als Plattform für QEMU/KVM-VMs und Linux-Systemcontainer. Der am geprüfte offizielle Administrationsleitfaden für 9.x ist Version 9.2 (PDF: Release 9.2.4 vom 04.08.2026), auf der Downloadseite aktualisiert am 10.08.2026. Die Konzepte gelten für diesen Dokumentationsstand; konkrete Funktionen hängen auch von Hardware, Storage und Gast ab. Der Artikel beschreibt Architekturentscheidungen und führt keine Installation oder Clusteränderung durch.
Eine VM besitzt ihren eigenen Kernel.
Eine virtuelle Maschine bekommt virtuelle Hardware: vCPUs, RAM, virtuelle Datenträger und Netzwerkkarten. Darauf startet ein vollständiges Gastbetriebssystem mit eigenem Kernel. Das kann etwa ein Linux- oder Windows-Gast sein, sofern Plattform, Lizenz und virtuelle Hardware passen. Der Gast verwaltet seine eigenen Prozesse, Updates und Dateisysteme.
Ein Hypervisor stellt Ausführungsumgebung und Ressourcentrennung bereit. Bei Proxmox arbeitet QEMU mit KVM zusammen: QEMU modelliert die Maschine und Geräte; KVM im Linux-Kernel nutzt Hardwarevirtualisierung zur beschleunigten Ausführung geeigneter Gäste. QEMU kann auch emulieren, doch das ist nicht dasselbe wie die hier gemeinte hardwarebeschleunigte VM. CPU-Unterstützung und deren Freigabe in der Firmware sind deshalb vorab zu prüfen.
Vier vCPUs sind nicht automatisch vier exklusiv reservierte physische Kerne. Mehrere Gäste teilen sich reale Rechenzeit. Auch zu großzügige RAM-Zusagen oder überfüllte Thin-Provisioning-Pools können den Host treffen. Plane Reserven für das Hostsystem und Lastspitzen ein. Virtuelle Datenträger liegen als Dateien oder Blockvolumes im Storage; ihre dargestellte Kapazität und der physisch verfügbare Platz sind verschiedene Größen.
Ein Linux-Container teilt den Hostkernel.
LXC verwendet Linux-Funktionen, um Prozesse in getrennten Umgebungen auszuführen. Namespaces begrenzen unter anderem die Sicht auf Prozesse, Mounts und Netzwerk. cgroups erfassen und begrenzen Ressourcen wie CPU-Zeit und Speicher. Weitere Mechanismen wie Fähigkeiten, seccomp und AppArmor ergänzen die Begrenzung. Ein eigenes Root-Dateisystem und eigene Pakete ergeben einen Systemcontainer; ein eigener Kernel entsteht dadurch nicht.
Ein Linux-Systemcontainer benötigt typischerweise weniger eigene Betriebssystemkomponenten als eine VM. Er kann aber keinen beliebigen anderen Kernel booten. Für einen eigenen Kernel, ein anderes Betriebssystem oder eine stärker getrennte Testumgebung ist eine VM naheliegend. Für einen bekannten Linux-Dienst kann ein unprivilegierter LXC-Container passen. Bei unprivilegierten Containern werden Benutzer-IDs auf andere Host-IDs abgebildet; das reduziert bestimmte Risiken, ersetzt jedoch weder Hostupdates noch Ressourcenlimits und saubere Mountfreigaben.
LXC und Docker sind nicht identisch. Proxmox verwaltet mit LXC üblicherweise ganze Linux-Systemumgebungen. Docker verpackt und betreibt Anwendungen mit Images, Container-Lebenszyklus und eigenen Netzwerk-/Volume-Konzepten. Beide nutzen auf Linux eine gemeinsame Kernelbasis, verfolgen aber unterschiedliche Betriebsmodelle. Für Docker auf Proxmox empfiehlt die Proxmox-Dokumentation eine QEMU-VM als Anwendungshost; Docker verschachtelt in LXC ist kein notwendiger Einsteigerstandard.
Proxmox verbindet Gäste, Netzwerk und Storage.
Die Weboberfläche zeigt links im Ressourcenbaum Datacenter, darunter die Nodes, also Hosts, sowie deren VMs, Container und Storage-Einträge. Auf Datacenter-Ebene liegen übergreifende Einstellungen wie Berechtigungen und Sicherungsjobs; am Node findest du unter anderem Ressourcenübersicht, Netzwerk, Updates und lokale Aufgaben. Bei einer VM oder einem Container untersuchst du dessen Konfiguration, Zustand und Konsole. Das Aufgabenprotokoll zeigt, ob etwa ein Backup tatsächlich erfolgreich beendet wurde.
Ein ISO-Image dient typischerweise als Installationsmedium einer VM. Ein LXC-Template liefert die Benutzerumgebung eines Systemcontainers. Ein VM-Template ist dagegen eine vorbereitete VM-Vorlage für Klone. „Template“ meint also je nach Objekt etwas anderes. Auch ein heruntergeladenes Template braucht eine vertrauenswürdige Quelle und spätere Updates.
Storage ist mehr als eine Festplattenliste.
Proxmox fasst Speicher unter Storage-IDs zusammen. Ein Storage kann etwa Verzeichnis, LVM-thin, ZFS oder Netzwerkspeicher sein; unterstützte Inhaltstypen und Snapshot-Funktionen unterscheiden sich. Ein Ort für ISO-Dateien ist nicht automatisch für VM-Disk-Images geeignet. Auch „shared“ als Konfiguration macht lokal vorhandene Daten nicht plötzlich für andere Nodes erreichbar.
Prüfe vor der Auswahl: Welche Gastdaten liegen wo? Wer kann bei einem Hostausfall darauf zugreifen? Gibt es genug physische Kapazität und Reserve? Eine VM mit mehreren Disks kann mehrere Storage-Abhängigkeiten besitzen. Bei LXC gehören zusätzliche Mounts in den Datenplan; ein durchgereichtes Hostverzeichnis hat andere Sicherungseigenschaften als ein verwaltetes Root-Volume.
Die Bridge ist ein virtueller Switch.
Eine Linux-Bridge wie vmbr0 verbindet virtuelle Netzanschlüsse der Gäste mit einem physischen Port, beispielsweise eno1. Gäste können im selben LAN eigene IP-Adressen verwenden. Die Bridge selbst ist weder automatisch Router noch NAT-Gateway. Auch der Host braucht für seinen Managementzugang eine passende Adresse; in einer üblichen Bridge-Konfiguration liegt sie auf der Bridge.
Ein gemeinsamer physischer Anschluss verhindert logische Segmentierung nicht: VLANs können Netze trennen, wenn Bridge, Gastzuordnung und angeschlossener Switch passend konfiguriert sind. Eine Trunk-Verbindung erfordert abgestimmte Tags auf beiden Seiten. Ein LXC-Namespace allein trennt zwei Gäste im selben LAN nicht durch eine Firewall. Regeln zwischen Netzen und der Schutz der Managementoberfläche bleiben eigene Aufgaben. Lies dazu IPv4, VLANs und Routing.
Ein kleines Homelab bewusst planen.
Angenommen, du möchtest einen Linux-Server zum Administrieren und einen separaten bekannten Labdienst betreiben. Ein Host, eine Linux-VM und ein unprivilegierter LXC-Container reichen als Lernaufbau. „Isoliert“ beschreibt dabei begrenzte Prozess-, Ressourcen- und Dateisystemsichten; erreichbare Netzdienste müssen zusätzlich begrenzt werden.
- Ressourcen und Wiederanlauf: Plane RAM für Host und Gäste, CPU-Reserve und realen Diskbedarf. Entscheide, welche Gäste nach dem Hoststart automatisch anlaufen sollen und welche Abhängigkeiten ihre Dienste haben.
- Netz und Verwaltung: Wähle freie, dokumentierte Adressen oder DHCP-Reservierungen. Beide Gäste hängen am virtuellen Switch; derselbe physische Port verbindet sie mit dem eigenen LAN. Hostverwaltung nur aus dem vorgesehenen Administrationsnetz, keine unnötige öffentliche Erreichbarkeit.
- Gastaufgaben: Die VM übt vollständigen Linux-Serverbetrieb. Der LXC-Container erhält nur die notwendigen Ressourcen und Mounts; unnötige Hostgeräte bleiben unzugänglich.
- Sicherung: Sichere Konfiguration und benötigte Gastvolumes versioniert auf ein anderes lokales Medium oder ein getrenntes NAS. Plane zusätzlich eine Kopie außerhalb der gemeinsamen Ausfallstelle und teste einen Restore in ein abgeschottetes Testnetz, damit keine doppelten IPs oder Dienste entstehen.
Vorher geklärt sein müssen auch Stromausfallverhalten, verfügbare Konsole bei Netzwerkfehlern, Updatefenster und Zugriffsrechte. Für einen KI-Dienst kommen Modellgröße, RAM/VRAM und gegebenenfalls Gerätezuweisung hinzu. GPU-Passthrough kann Isolation und Migrationsfähigkeit beeinflussen; eine virtuelle CPU-Zahl sagt nichts über verfügbare GPU-Kapazität aus. Der Artikel zu lokalen KI-Modellen hilft bei dieser Bedarfsfrage.
Snapshot und Backup lösen verschiedene Probleme.
Ein Snapshot erlaubt je nach Storage und Gast einen schnellen Rücksprung vor eine Änderung. Er hängt häufig von derselben Storage-Struktur ab wie die laufende VM. Der Verlust des Pools kann beide treffen. Snapshot-Unterstützung, möglicher RAM-Zustand und Gastkonsistenz sind keine universellen Eigenschaften aller Storage-Typen.
Ein Proxmox-Backup sichert die Konfiguration und die einbezogenen Gastdaten für einen späteren Restore. Ein anderes Backupmedium schützt vor dem Ausfall der Hostdisks; gegen Brand, Diebstahl oder kompromittierte gemeinsame Zugänge braucht es weitere Trennung. Erfolgsmeldung und Existenz einer Datei ersetzen den Wiederherstellungstest nicht.
Kontrolliere den Umfang: Bei LXC sind zusätzliche Volume-Mountpoints nicht grundsätzlich mitgesichert und müssen gegebenenfalls explizit einbezogen werden. Bind- und Device-Mounts werden nicht über das normale Containerbackup gesichert; deren Daten benötigen einen eigenen Sicherungsweg. Auch ausgenommene VM-Disks oder externe Dienste gehören in den Plan. Für schreibende Datenbanken sind geeignete Konsistenzverfahren entscheidend. Ein Backup im Modus „snapshot“ ist ein Sicherungsvorgang mit diesem Modus und nicht einfach derselbe Gegenstand wie ein gespeicherter VM-Snapshot.
Ein Cluster ist der Anfang einer HA-Planung.
Mehrere Proxmox-Nodes können eine gemeinsame Verwaltungs- und Clusterkonfiguration nutzen. Für verlässliche Entscheidungen braucht der Cluster Quorum, also eine ausreichende Stimmenmehrheit. Ein Netzwerkausfall darf nicht dazu führen, dass zwei getrennte Seiten dieselbe Gastdisk gleichzeitig verändern. Für robuste HA nennt die Dokumentation mindestens drei Cluster-Nodes, geeigneten gemeinsamen Storage und redundante Hardware als grundlegende Anforderungen. Abweichende Quorum- und Replikationskonzepte erfordern eine eigene Planung.
Live-Migration einer VM verschiebt ihren laufenden Zustand auf einen anderen Node. Dafür müssen unter anderem CPU-Funktionen und Softwarestände kompatibel sein, der Zielhost genug Ressourcen besitzen und die Gastnetze am Ziel gleichwertig erreichbar sein. Gemeinsamer Storage vermeidet das Kopieren der Disks; bei unterstützter Migration lokaler Disks sind Datenübertragung, Platz und Bandbreite zusätzlich nötig. Direkt durchgereichte Geräte können Live-Migration verhindern. LXC-Container werden hier nicht als beliebig live migrierbare VMs behandelt; für ihren Transfer ist eine Betriebsunterbrechung einzuplanen.
Hochverfügbarkeit kann konfigurierte Gäste nach einem erkannten Hostausfall auf anderen Nodes neu starten. Dafür braucht es erreichbare Gastdaten, verfügbare Kapazität, funktionierendes Clusternetz, Quorum und Fencing, um einen ausgefallenen oder abgetrennten Node sicher auszuschließen. Ein einzelnes NAS oder ein gemeinsamer Switch kann die ganze Konstruktion wieder zur gemeinsamen Ausfallstelle machen. HA bedeutet zudem Neustart und mögliche Unterbrechung, keine garantierte verlustfreie Fortsetzung jeder Anwendung. Anwendungsreplikation und Backups bleiben eigene Maßnahmen.
Wann brauche ich eine VM, LXC, Docker oder Kubernetes?
Diese Werkzeuge liegen auf unterschiedlichen Ebenen und können zusammenarbeiten: Proxmox kann eine Linux-VM betreiben, in der eine Compose-Anwendung läuft. Kubernetes-Nodes können ebenfalls VMs sein. Wähle zuerst die erforderliche Betriebssystemgrenze, dann das Modell für die Anwendung und zuletzt den Umfang der Orchestrierung.
VM: ein vollständiger eigener Server.
Passend für: eigener Kernel, vollständiges Gastbetriebssystem oder eine eigenständig verwaltete Sicherheitsgrenze. Die virtuelle Netzkarte verhält sich für den Gast wie ein Netzwerkanschluss; IP, DNS und Firewall werden im Gast und an dessen Netzpfad geplant. Du wartest Host und Gastbetriebssystem. Der zusätzliche Kernel und die virtuelle Hardware benötigen Ressourcen; konkrete Kosten hängen von der Last ab. Mehr VMs oder größere Ressourcenzuteilung skalieren nicht automatisch die Anwendung. Ein kompromittierter Hypervisor bleibt ein übergeordnetes Risiko.
LXC: eine begrenzte Linux-Systemumgebung.
Passend für: bekannte Linux-Dienste mit eigenem Benutzerland, aber ohne eigenen Kernelbedarf. Geringerer eigener Betriebssystemumfang kann Ressourcen sparen; Hostkernel und dessen Wartung bleiben gemeinsam. Netzwerknamespaces und virtuelle Interfaces erlauben eigene Adressen, erzwingen aber keine sichere Filterpolitik. Rootfs, Pakete und Anwendungsdaten brauchen Wartung und Sicherung. Unprivilegierter Betrieb, knappe Mountfreigaben und Limits sind wichtig; zusätzliche Instanzen erfordern weiterhin eine sinnvolle Dienstverteilung.
Docker: eine Anwendung als Image betreiben.
Passend für: reproduzierbare Bereitstellung einer einzelnen containerisierten Anwendung. Auf einem Linux-Host bleibt der Kernel geteilt. Container-Netze und veröffentlichte Ports legen fest, wer den Dienst erreicht; Volumes bewahren benötigte Daten außerhalb des austauschbaren Containers. Updates erfolgen über geprüfte Images und kontrolliertes Neuerstellen, nicht allein durch Hostupdates. Docker-Daemon, Socketzugriff und weitreichende Containerrechte sind Teil des Sicherheitsmodells. Mehr Container schaffen ohne Lastverteilung und Datenkonzept noch keine skalierbare Anwendung.
Compose: mehrere Services auf einem Anwendungshost.
Passend für: zusammengehörigen Webdienst, Datenbank und weitere Komponenten in einer überschaubaren Installation. Eine Datei beschreibt Services, Netze und Volumes. Das vereinfacht den gemeinsamen Lebenszyklus; Abhängigkeiten und tatsächliche Bereitschaft müssen trotzdem korrekt modelliert werden. Der Host bleibt eine Ausfallstelle. Du wartest Images, Engine, Host und Sicherungen. Mehrere Instanzen sind möglich, doch hostübergreifendes Scheduling und automatisches Failover sind keine allgemeine Compose-Garantie. Details und Beispiel: Docker und Compose verstehen.
Kubernetes: Anwendungen durch einen Cluster verwalten.
Passend für: einen begründeten Bedarf an deklarativem Betrieb, Scheduling und verteilten Anwendungsinstanzen. Pods, Services, Netzwerkimplementierung und persistenter Storage müssen zusammenpassen. Control Plane, Runtime, Zugriffe, Updates und Wiederherstellung verursachen eigenen Betriebsaufwand und Grundbedarf an Ressourcen. Namespaces allein sind keine starke Mandantengrenze; RBAC, Netzregeln und sichere Laufzeitkonfiguration gehören dazu. Replikas und Neuplanung können Verfügbarkeit verbessern, sofern Nodes, Daten und Anwendung dafür ausgelegt sind. Der nächste Artikel erklärt Kubernetes vom Container zum Cluster.
Es gibt keinen pauschalen Sieger. Ein kleiner interner Dienst rechtfertigt nicht automatisch einen Cluster. Umgekehrt löst eine einzelne große VM keine Anforderung an den Weiterbetrieb nach Hostausfall. Entscheidend sind die notwendige Isolation, Wiederherstellungsziele, Datenhaltung und die Betriebskenntnisse der Verantwortlichen.
Zwei Entscheidungen zur Architektur prüfen.
Eine Testumgebung soll einen anderen Linux-Kernel starten. Reicht ein LXC-Container mit einem eigenen Distributions-Template? Begründe die passende Wahl.
Lösung: Benutzerland und Kernel auseinanderhalten
Nein. Das Template liefert das Benutzerland, während LXC den Hostkernel verwendet. Eine VM kann ihren eigenen Gastkernel starten und passt zu dieser Anforderung. Ihre zusätzlichen Ressourcen und die eigene Betriebssystemwartung müssen eingeplant werden. Eine andere Distribution im Container ist nicht automatisch ein anderer Kernel.
Zwei Nodes besitzen Gastdisks ausschließlich auf ihren eigenen lokalen Laufwerken. Beide hängen am selben Switch. Jemand verspricht nach der Clusterbildung automatisches, unterbrechungsfreies Failover. Welche Voraussetzungen fehlen?
Lösung: Verwaltung schafft keine Datenverfügbarkeit
Der andere Node benötigt bei Ausfall Zugriff auf die Gastdaten, ausreichend Kapazität und passende Gastnetze. Zusätzlich sind eine robuste Quorumlösung, Fencing und HA-Konfiguration nötig; die Standardempfehlung nennt mindestens drei Nodes. Der einzige Switch ist eine gemeinsame Ausfallstelle. Eine geplante Live-Migration mit Datenkopie wäre etwas anderes als ein spontaner Hostausfall. Selbst korrekt geplantes HA startet einen Gast gegebenenfalls neu und verspricht keinen unterbrechungsfreien Anwendungsbetrieb. Ein unabhängiges Backup bleibt erforderlich.
Quellen und fachlicher Stand.
Geprüft am : offizielle Proxmox-Dokumentationsübersicht und Proxmox VE Administration Guide 9.2. Die Kapitelquellen im offiziellen Proxmox-Repository ergänzen die Prüfung; dessen Entwicklungszweig kann über den veröffentlichten Leitfaden hinausgehen. Hier wird keine neue Entwicklungsfunktion vorausgesetzt.
- Proxmox: QEMU/KVM und Migration, QEMU: Systemvirtualisierung.
- Proxmox: Container Toolkit und LXC: Isolation durch Linux-Kernelfunktionen.
- Proxmox: Weboberfläche, Netzwerkkonfiguration und Storage-Modell.
- Proxmox: Backup und Restore, Cluster Manager und HA Manager.
- Docker: Architektur, Compose: Einsatzgebiete und Kubernetes: Aufgaben der Plattform für den Vergleich.