Proxmox VE Grundlagen

Zu Beginn ordnen Sie die Bausteine von Proxmox VE fachlich ein: Host, QEMU/KVM, LXC, Storage, Linux Bridges und Managementzugang. Anschließend übertragen Sie diese Zusammenhänge auf die vorbereitete Laborumgebung und entwickeln einen begründeten Single-Host-Plan. Dabei wird sichtbar, welche Entscheidungen vor der Installation zusammengehören und welche Abhängigkeiten später den Betrieb beeinflussen.

Eine Proxmox-Installation legt Managementzugang, Hostidentität und lokalen Storage fest. Sie besprechen, welche Angaben der Installer benötigt und wie Datenträger- und Adressplan zusammenwirken. In der vorbereiteten Laborumgebung installieren Sie den Host, melden sich über Weboberfläche und Shell an und gleichen das Ergebnis mit Ihrem Hostplan ab.

Nach der ersten Anmeldung entscheidet der Basiszustand darüber, ob VMs und Container zuverlässig betrieben werden können. Sie ordnen DNS, Zeitsynchronisation, Paketquellen, Update-Stand, KVM-Unterstützung, Proxmox-Dienste und Storage-Ziele ihren jeweiligen Aufgaben zu. In einer geführten Übung vergleichen Sie Oberfläche und Shell, untersuchen Abweichungen und leiten daraus notwendige Korrekturen ab.

Eine QEMU/KVM-VM kapselt ein vollständiges Gastbetriebssystem. Firmware, virtuelle Geräte und Guest Agent bestimmen, wie gut sie zum geplanten Betrieb passt. Sie vergleichen die verfügbaren Optionen, erstellen daraus einen kleinen Linux-Gast und richten den Guest Agent ein. Beim Funktionstest beobachten Sie die Auswirkungen auf Netzwerk, Ressourcenanzeige und kontrolliertes Herunterfahren.

LXC-Systemcontainer teilen den Kernel des Hosts und folgen deshalb anderen Isolations- und Betriebsgrenzen als virtuelle Maschinen. Sie ordnen typische Einsatzfälle sowie die Bedeutung unprivilegierter Container ein und erstellen anschließend einen Container mit definierten CPU- und Speichergrenzen. An einem vorbereiteten Dienst vergleichen Sie Start, Ressourcenbedarf und Sicherheitsgrenze mit der zuvor erstellten VM.

Ein Proxmox-Storage-Ziel eignet sich je nach Inhaltstyp und unterstützten Operationen für unterschiedliche Aufgaben; freier Platz ist dabei nur ein Kriterium. Sie unterscheiden Datei- und Thin-Block-Storage sowie deren Auswirkungen auf Images, VM-Disks, Container und Backups. An den vorhandenen Zielen wenden Sie diese Einordnung mit Oberfläche und pvesm an und begründen eine passende Platzierung.

Beim Offline-Import müssen Quellabbild und Zielkonfiguration zusammenpassen: Firmware, Storage, Bootreihenfolge und virtuelle Hardware beeinflussen, ob der Gast am Ziel startet. Sie ordnen diese Abhängigkeiten zunächst einem vorbereiteten Linux-Gast zu. Auf dieser Grundlage importieren Sie das abgeschaltete Abbild, starten die VM und untersuchen, wie Zielkonfiguration und erreichbarer Dienst zusammenhängen, ohne unbekannte Quellsysteme zu reparieren.

Eine Linux Bridge arbeitet als virtueller Switch zwischen Host, physischen Uplinks und Gästen. Sie verfolgen zunächst an vmbr0 den Weg eines Pakets und unterscheiden Managementnetz und isoliertes Gastsegment. Das Modell setzen Sie praktisch um, indem Sie eine Labor-Bridge erstellen, VM und LXC-Container verbinden und die beobachtete Erreichbarkeit erklären.

VLANs trennen Broadcast-Domänen nur dann zuverlässig, wenn VLAN-Awareness der Bridge, Tag-Zuweisung am virtuellen Gast-Interface und gegebenenfalls der Uplink zusammenpassen. Sie ordnen ein, an welcher Stelle ein VLAN-Tag gesetzt, weitergereicht oder entfernt wird. In der Übung verbinden Sie VM und Container mit vorbereiteten Segmenten, erzeugen bewusst eine falsche Zuordnung und nutzen Erreichbarkeit sowie Konfiguration, um Ursache und Korrektur herzuleiten.

Das Proxmox-Berechtigungsmodell verbindet Realm, Benutzer, Gruppen, Rollen, ACL-Pfade und Vererbung. Sie ordnen diese Ebenen ein und leiten daraus minimale Rechte für eine klar begrenzte VM-Aufgabe ab. Für die praktische Delegation legen Sie Benutzer und Gruppe im lokalen PVE-Realm an und vergleichen eine erlaubte VM-Aktion mit einer verweigerten Storage-Aktion.

Die Proxmox-Firewall wirkt auf mehreren Ebenen. Geltungsbereich, Aktivierungsschalter und Regelreihenfolge bestimmen gemeinsam das Ergebnis. Bevor Sie Regeln ändern, ordnen Sie Host-, Gast- und Interface-Schutz sowie den notwendigen Recovery-Weg ein. An einem vorbereiteten Dienst wenden Sie das Modell an, erlauben eine Verbindung, verwerfen einen zweiten Zugriff und erklären die Beobachtung anhand von Konfiguration und Logeintrag.

Bei verlorener Erreichbarkeit muss zwischen Netzwerkpfad, Dienst und Firewall-Wirkung unterschieden werden. Sie entwickeln dafür einen geordneten Diagnoseweg und wenden ihn anschließend auf eine vorbereitete Fehlkonfiguration an. Über die Konsole verfolgen Sie die Ursache, stellen den gewünschten Zustand wieder her und halten fest, welche Beobachtung zur richtigen Hypothese geführt hat.

Für ein Backup müssen Konsistenz, Sicherungsmodus und Ziel zum Workload passen. Sie vergleichen die verfügbaren Modi für VMs und Container und wählen für einen vorbereiteten Gast eine begründete Variante. Die gewählte Variante setzen Sie auf getrenntem Storage um und lesen aus Jobprotokoll und Artefakt ab, welche Daten und Konfigurationen tatsächlich enthalten sind.

Erst ein Restore zeigt, ob Sicherungsdaten für den Wiederanlauf geeignet sind. Sie ordnen ein, warum eine neue Gast-ID, ein bekannter Prüfwert und die Trennung vom Quellgast eine aussagekräftige Wiederherstellungsprobe ermöglichen. Für die Übung verändern Sie den Originalgast, restaurieren das Backup und vergleichen Konfiguration, Startverhalten und Dienstinhalt beider Instanzen.

Systematische Fehlerdiagnose verbindet Beobachtung, Hypothese und gezielten Eingriff, statt mehrere Einstellungen gleichzeitig zu verändern. An einem vorbereiteten Storage- oder Netzwerkfehler verfolgen Sie Tasks und Status in der Oberfläche, korrelieren pvesm, qm oder pct mit Dienst- und Systemlogs und testen eine begründete Korrektur. Der erarbeitete Diagnoseweg dient anschließend als Methode für weitere Gastfehler.