Grundlagen & Architektur

Was ist Proxmox VE?

• Basis: aktuelles Debian (Long-Term-Support-Kernel, regelmäßige Sicherheitsupdates aus dem Debian- und Proxmox-Repository) – wer schon einmal einen Debian-Server administriert hat, kennt also bereits die Grundlage
• KVM/QEMU für vollwertige virtuelle Maschinen – jedes Gast-Betriebssystem, volle Hardware-Emulation wo nötig, native Geschwindigkeit dank Hardware-Virtualisierung (Intel VT-x/AMD-V)
• LXC für leichtgewichtige Linux-Container – teilen sich den Host-Kernel, starten in Sekunden statt Minuten, ideal für schlanke Linux-Dienste ohne den Overhead einer vollen VM
• Verwaltung wahlweise über Web-GUI, Kommandozeile oder REST-API – alle drei Wege decken denselben Funktionsumfang ab, keine Funktion ist der Oberfläche vorbehalten
• Lizenzmodell: die komplette Software ist quelloffen (AGPLv3) und ohne Abo voll funktionsfähig – ein kostenpflichtiges Support-Abo ist optional und ändert am Funktionsumfang nichts, nur am Zugriff auf das Enterprise-Repository und den Herstellersupport
• Entwickelt von Proxmox Server Solutions GmbH (Wien) – seit 2008 am Markt, damit kein junges Projekt, sondern eine etablierte, kontinuierlich weiterentwickelte Plattform

Architektur: Datacenter → Node → Guest

• Datacenter: die logische Klammer über alle verbundenen Nodes (auch als Einzel-Node nutzbar) – in der Web-GUI die oberste Ansicht, von der aus Storage, Berechtigungen und Cluster-weite Einstellungen verwaltet werden
• Node: ein physischer oder virtueller Proxmox-Host mit eigenem Storage und Netzwerk – jeder Node bringt seine eigene Konfiguration unter /etc/pve mit, die im Cluster-Verbund automatisch zwischen allen Nodes synchronisiert wird
• Guest: die einzelne VM oder der einzelne Container auf einem Node – identifiziert über eine eindeutige VMID, die clusterweit nur einmal vergeben wird
• Diese dreistufige Hierarchie bleibt gleich, egal ob ein einzelner Mini-Server oder ein Cluster mit einem Dutzend Nodes betrieben wird – sie wächst einfach mit

KVM vs. LXC

Faustregel: Windows und alles Gast-OS-Unabhängige → KVM. Schlanke Linux-Dienste, bei denen Performance und schneller Start zählen (z. B. ein einzelner Webserver oder Reverse Proxy) → LXC. Im Zweifel ist KVM die sicherere Wahl, weil die Isolation vollständiger ist – ein Kernel-Exploit im Container kann theoretisch den Host betreffen, bei einer VM nicht.

Denkweise-Umstieg von ESXi/Hyper-V

Der größte Unterschied ist keine Funktion, sondern die Haltung: Proxmox zeigt dir das darunterliegende Linux, statt es hinter einer Appliance zu verstecken. Wer bisher nie eine Kommandozeile auf dem Hypervisor gebraucht hat, wird sie bei Proxmox zumindest gelegentlich sehen – meist aber nur zur Fehlersuche, der Alltag läuft über die Web-GUI.

Web-GUI, CLI & API

Alle drei Zugangswege sprechen intern dieselbe Proxmox-API – nichts, was die Oberfläche kann, bleibt der Kommandozeile verwehrt, und umgekehrt. Das ist ein bewusster Architekturentscheid: Jeder Klick in der Web-GUI löst im Hintergrund denselben API-Aufruf aus, den auch ein eigenes Skript absetzen könnte.

• Web-GUI: beste Wahl für den Alltag – Übersicht, Konsole, Logs und Konfiguration an einem Ort, erreichbar unter https://<IP>:8006
• CLI direkt auf dem Node per SSH – am schnellsten für einzelne, gezielte Befehle oder wenn die Web-GUI mal nicht erreichbar ist
• Für Automatisierung: API-Token statt Passwort verwenden, damit Skripte nicht mit vollen Admin-Zugangsdaten hantieren – Tokens lassen sich pro Anwendungsfall einzeln anlegen und widerrufen, ohne das Hauptpasswort zu ändern
• Die REST-API ist dieselbe Grundlage, auf der auch Terraform-Provider, Ansible-Module und Backup-Tools von Drittanbietern aufsetzen

Cluster-weiter Konsolenzugriff

• noVNC- bzw. SPICE-Konsole funktioniert für jede VM auf jedem Node – die Web-GUI proxyt die Konsolen-Verbindung automatisch zum richtigen Node im Hintergrund
• Nach einer Live-Migration bleibt der Konsolenzugriff erhalten – die VM zieht auf einen anderen Node um, und der Zugriff „folgt" ihr automatisch, ohne dass eine neue Verbindung aufgebaut werden muss
• Voraussetzung: alle beteiligten Nodes müssen im selben Cluster sein, Corosync bzw. das Cluster-Netz muss funktionieren, und der Node, auf dem die VM tatsächlich läuft, muss erreichbar sein
• Rechte/ACLs steuern zusätzlich, wer welche VMs überhaupt sehen und darauf zugreifen darf – wichtig bei Mandantentrennung, etwa im MSP-Betrieb mit mehreren Kunden auf demselben Cluster
• Fällt der Node aus, an dem man gerade eingeloggt ist, meldet man sich einfach an einem anderen Node an – die Web-GUI läuft identisch auf jedem Node im Cluster
• Die Mechanik dahinter (Proxy-Prinzip, Cluster-weite Sichtbarkeit) wird in Modul 7 – Cluster & Quorum vertieft

Nested Virtualization

• Voraussetzung: Intel VT-x/EPT bzw. AMD-V/NPT auf Host und CPU-Typ der äußeren VM (z. B. host oder ein moderner x86-64-v3) – ohne diese Weitergabe verweigert die innere Proxmox-Installation den Start eigener VMs
• Aktivierung über die VM-Optionen: CPU-Flag „vmx" (Intel) bzw. „svm" (AMD) muss in der äußeren VM sichtbar sein, meist per CPU-Typ „host" oder gezieltem Flag automatisch der Fall
• Typischer Einsatz: einen kompletten Proxmox-Cluster testweise in mehreren VMs nachbauen, bevor echte Hardware angefasst wird – genau das nutzen auch die Beispiele in diesem Lernbereich
• Auch nützlich für Schulungen und Vorführungen – ein ganzes Mehr-Node-Setup mit Cluster und HA läuft auf einem einzigen Laptop oder Mini-PC
• Performance-Abzug gegenüber echter Hardware einplanen (grob 10–20 % je nach Workload) – für Produktivbetrieb ungeeignet, aber für Lernen, Tests und Migrationsproben ideal

Das Wichtigste

• Zwei Virtualisierungsarten in einer Oberfläche: KVM für vollwertige VMs, LXC für schlanke Linux-Container
• Klare Hierarchie: Datacenter → Node → Guest, auch als Einzel-Node-Setup nutzbar
• Von ESXi/Hyper-V übersetzt sich fast jedes Konzept eins zu eins – die Umstellung ist mehr Haltung als Funktion
• Gleicher Funktionsumfang über GUI, qm/pct oder die pvesh-API – wichtig für spätere Automatisierung
• Nested Virtualization eignet sich für Labs und Schulungen, nicht für Produktivbetrieb