Proxmox konfigurieren

Im vorherigen Abschnitt haben Sie Proxmox VE installiert und sind zum ersten Mal auf dessen Weboberfläche gelangt, nämlich auf den Anmeldebildschirm hinter einer Warnmeldung wegen eines selbstsignierten Zertifikats. In diesem Abschnitt verwandeln wir diese einfache Installation in eine Plattform, die tatsächlich für VMs bereit ist: echte Paket-Updates, die Netzwerkbrücke, Speicher und die Speicheroptimierung, die erst dann wirklich wichtig wird, wenn mehrere VMs parallel laufen.

Die Paket-Repositories korrigieren

Bei der ersten Anmeldung am Knoten wird zunächst eine Warnung angezeigt: Das Unternehmens-Repository ist zwar aktiviert, es ist jedoch kein aktives Abonnement damit verknüpft, sodass alle Paketvorgänge, die darauf abzielen, fehlschlagen.

Weil dies die sicherere Standardeinstellung ist. Das Unternehmens-Repository ist das am intensivsten getestete Repository, das Proxmox bereitstellt, und der Installer kann im Voraus nicht erkennen, ob für einen bestimmten Server ein Abonnement besteht oder nicht. Daher aktiviert er in beiden Fällen dasselbe Repository und überlässt die Korrektur demjenigen, der den Server einrichtet.

Die Behebung erfolgt eigentlich in zwei Schritten: Das Deaktivieren des Unternehmens-Repositorys allein verschlimmert die Situation sogar noch, da dadurch auf dem Knoten überhaupt kein Proxmox-Repository mehr aktiviert ist.

Die Schaltfläche „Hinzufügen“ auf demselben Bildschirm liefert das fehlende Puzzlestück: das abonnementsfreie Repository, das genau für diesen Fall entwickelt wurde.

Nachdem das Repository ohne Abonnement hinzugefügt wurde, ändert sich der Status des Knotens von einer einzelnen Warnung zu einer Kombination, die man sich merken sollte: Updates funktionieren nun, begleitet von einem Hinweis, dass dieses Repository nicht das von Proxmox für einen Produktionscluster empfohlene ist.

Das System aktualisieren

Wenn ein funktionierendes Repository vorhanden ist, kann der Bereich „Updates“ die Paketliste tatsächlich aktualisieren, anstatt sofort zu scheitern. Das hinter dieser Aktualisierung stehende Aufgabenprotokoll ist es wert, einmal durchgelesen zu werden, da es genau zeigt, welche Repositories geantwortet haben und welche nicht.

Von hier aus führt die Schaltfläche „Upgrade“ auf demselben Bildschirm das eigentliche Paket-Upgrade durch – derselbe Vorgang wie apt full-upgrade in der Befehlszeile. Wenn man den Befehl direkt nach einer Neuinstallation ausführt, bevor noch keine virtuelle Maschine existiert, bedeutet dies, dass ein Neustart im Falle eines Kernel-Upgrades noch keine laufenden Prozesse unterbricht.

Überblick über die Netzwerkbrücke

Das Installationsprogramm hat bereits eine Netzwerkkonfiguration erstellt, die über die physische Netzwerkkarte hinausgeht: vmbr0, eine Linux-Bridge, die auf der physischen Netzwerkkarte nic0 aufsetzt und die während der Installation festgelegte Verwaltungs-IP enthält.

Denn eine physische Netzwerkkarte kann jeweils nur an einem Ort angeschlossen sein. Eine Bridge fungiert stattdessen wie ein kleiner virtueller Switch: Die physische Netzwerkkarte wird an einer Seite angeschlossen, und die virtuellen Netzwerkschnittstellen aller VMs werden an der anderen Seite angeschlossen – jede mit ihrer eigenen MAC-Adresse, sodass jede unabhängig von den anderen Datenverkehr über dieselbe physische Verbindung senden und empfangen kann.

Dies ist auch genau die Brücke, an die der weiter unten in dieser Anleitung beschriebene IPv4-Abschnitt eine zweite Adresse anfügt; daher muss hier vorerst noch nichts geändert werden – man muss sie lediglich erkennen, wenn sie später wieder auftaucht.

Speicher überprüfen

Unmittelbar nach der Installation sind zwei Speichereinträge vorhanden, die sich beide auf derselben Festplatte befinden, die während der Einrichtung ausgewählt wurde, jedoch unterschiedlichen Zwecken dienen.

Speicher und CPU für die VM-Dichte optimieren

Zwei Einstellungen legen fest, wie viele VMs tatsächlich in den Arbeitsspeicher dieses Servers passen, und keine davon wird vom Installationsprogramm speziell für eine Hosting-Anwendung konfiguriert, da es keine Möglichkeit hat zu erkennen, wofür der Rechner eigentlich vorgesehen ist.

Speicherdeduplizierung mit KSM aktivieren

Kernel Samepage Merging (KSM) ermöglicht es mehreren VMs, auf denen dasselbe Gastbetriebssystem läuft, Speicherseiten gemeinsam zu nutzen, anstatt dass jede VM eine eigene, separate Kopie weitgehend identischer Inhalte vorhält. Proxmox setzt hierfür einen Optimierungs-Daemon namens „ksmtuned“ ein, der die Speicherauslastung überwacht und die eigentliche Zusammenführung nur dann aktiviert, wenn sich dies lohnt.

Auf einem frisch installierten Knoten, auf dem noch keine VMs laufen, ist dieser Daemon zwar aktiv, befindet sich jedoch im Leerlauf – das sollte man besser direkt überprüfen, anstatt einfach davon auszugehen.

Diese Nullen sind kein Anzeichen dafür, dass etwas falsch konfiguriert ist, sondern entsprechen dem erwarteten Zustand auf einem Host, der keinem Speicherbedarf ausgesetzt ist. Sobald mehrere VMs mit demselben Betriebssystem laufen, setzt ksmtuned „run“ automatisch auf 1 und „pages_shared“ beginnt zu steigen – ganz ohne manuelle Eingriffe; die Optimierungsschwellenwerte selbst befinden sich in /etc/ksmtuned.conf Falls später einmal Anpassungen erforderlich sein sollten – auch wenn die Standardeinstellungen für eine erste Plattform einen vernünftigen Ausgangspunkt darstellen.

Swappiness senken und CPU-Mikrocode überprüfen

Der Swappiness-Wert bestimmt, wie schnell der Kernel Speicher in den Auslagerungsspeicher verschiebt, anstatt ihn im RAM zu belassen. Der Debian-Standardwert von 60 wurde für einen Allzweck-Desktop festgelegt – lange bevor mehrere virtuelle Maschinen, die jeweils eigenen RAM benötigen, ins Spiel kamen. Um diesen Wert direkt zu überprüfen und gleichzeitig festzustellen, welcher CPU-Mikrocode tatsächlich geladen ist, genügt ein einziger Befehl.

Ein niedrigerer Wert verhindert, dass der Kernel VM-Speicher auslagert, nur weil er in den letzten Sekunden nicht genutzt wurde. Dies ist bei einem Hypervisor wichtiger als fast überall sonst: Eine ausgelagerte VM wirkt für den Nutzer wie eingefroren. Das Speichern der Einstellung in einer Datei unter /etc/sysctl.d/ sorgt dafür, dass er einen Neustart übersteht, anstatt nur ein einmaliger Wert zu sein, der sich selbst zurücksetzt.

Es lohnt sich, beide Extreme zu verstehen, anstatt einfach blind eine Zahl auszuwählen. Bei einem Swappiness-Wert von 60 beginnt der Kernel bereits deutlich bevor der Arbeitsspeicher tatsächlich knapp wird, proaktiv auszulagern, wobei er ein wenig Leistung beim Dateicache gegen Spielraum eintauscht, den ein Desktop-Rechner selten vermisst; auf einem Host, auf dem VMs laufen, kann dasselbe proaktive Auslagern eine VM, die gerade einen Moment lang inaktiv war, unbemerkt auslagern, und das eigene Gastbetriebssystem der VM hat keine Ahnung, dass dies überhaupt geschehen ist – es fühlt sich einfach nur langsam an. Bei einem Swappiness-Wert von 0 vermeidet der Kernel das Auslagern fast vollständig und greift stattdessen auf den „Out-of-Memory-Killer“ zurück, sobald der Arbeitsspeicher tatsächlich knapp wird – was einen schwerwiegenderen Ausfall darstellt, als es ein wenig Auslagern gewesen wäre. Ein niedriger, aber von Null ungleicher Wert – hier 10 – behält den Swap als Sicherheitsnetz für echte Speichererschöpfung bei, ohne ihn als erste Maßnahme zu nutzen.

Auf diesem Server bestätigte die Überprüfung des Intel-Mikrocode-Pakets, dass bereits die neueste verfügbare Version installiert war, da diese bereits in der Debian-Basisinstallation enthalten ist: Es musste also nichts installiert werden, was an sich schon eine nützliche Information ist und kein überflüssiger Schritt. Mikrocode selbst ist Firmware für die CPU, die echte Hardwarefehler behebt, die Intel oder AMD erst nach der Auslieferung eines bestimmten Chips entdeckt haben; manche davon betreffen lediglich die Korrektheit, andere sind sicherheitsrelevant; Ein Server, der – gemäß den Empfehlungen aus Teil 1 – gebraucht gekauft wurde, könnte jahrelang in einem Lager gestanden haben oder zwischen den Besitzern ungenutzt gelaufen sein – lange genug, dass sich mehrere solcher Patches angesammelt haben, die noch nicht angewendet wurden. Die Ausführung dieses einen Befehls kostet in jedem Fall nichts, und es ist die einzige Möglichkeit, Gewissheit zu erlangen, anstatt einfach anzunehmen, dass ein gebrauchtes Gerät auf dem neuesten Stand ist.

Ein Administrator-Konto ohne Root-Rechte erstellen

Auf allen bisherigen Bildschirmansichten in dieser Anleitung wurde das Root-Konto verwendet. Das ist für die erste Stunde der Server-Einrichtung zwar in Ordnung, sollte aber nicht zur täglichen Gewohnheit werden, sobald die Plattform erst einmal läuft.

Es funktioniert zwar, aber wenn auch nur ein einziges Root-Passwort bekannt wird, hat der Angreifer sofort die vollständige Kontrolle über die gesamte Plattform – ohne dass ein separates Konto deaktiviert werden könnte und ohne dass ein separater Anmeldevorgang im Aufgabenprotokoll überprüft werden könnte. Ein eigens dafür vorgesehenes Administratorkonto behebt dieses Problem, ohne dass dabei die Funktionen von „root“ verloren gehen.

Das Hinzufügen eines Kontos beginnt mit einer Entscheidung, die auf den ersten Blick nicht offensichtlich ist: Zu welchem Bereich gehört das Konto? Für ein Linux-PAM-Konto muss bereits ein echter Unix-Benutzer auf dem Server existieren; ein Proxmox VE-Authentifizierungsserver-Konto, kurz „pve“, existiert nur innerhalb von Proxmox selbst, verfügt über ein eigenes Passwort und benötigt nichts auf dem zugrunde liegenden Betriebssystem.

Für ein Administratorkonto, das ausschließlich die Weboberfläche benötigt, ist der „pve“-Bereich die einfachere Wahl – und genau dieser wird direkt nach der Erstellung in der Benutzerliste angezeigt. Der Kompromiss sollte jedoch klar dargelegt und nicht beschönigt werden: Ein PAM-Konto kann, da es einem echten Unix-Benutzer zugeordnet ist, sich auch per SSH in den Server einloggen und eine echte Shell erhalten, genau wie „root“, während ein „pve-realm“-Konto ausschließlich innerhalb des Proxmox-eigenen Authentifizierungssystems existiert und keinerlei Shell-Zugriff hat, unabhängig davon, welche Rolle ihm in der Weboberfläche zugewiesen wurde. Für ein Konto, das ausschließlich dazu gedacht ist, VMs und Speicher über den Browser zu verwalten und sonst nichts, ist das keine Einschränkung, sondern genau die Grenze, die es zu ziehen lohnt: Der Verlust des Passworts dieses Kontos führt niemals dazu, dass eine Login-Shell auf dem zugrunde liegenden Betriebssystem freigegeben wird, wie es bei einem kompromittierten PAM-Konto der Fall wäre.

Weise ihm eine Rolle zu

Ein neu angelegter Benutzer in Proxmox hat zunächst keinerlei Zugriff; die bloße Existenz eines Benutzers ist nicht gleichbedeutend mit der Berechtigung, etwas zu tun – und genau das wird im Abschnitt „Berechtigungen“ unter „Datacenter“ geregelt. Eine Berechtigung verknüpft einen Pfad im Ressourcenbaum mit einem Benutzer und einer Rolle.

Pfad / bezeichnet den gesamten Ressourcenbaum, d. h. alle VMs und alle Speicher zusammen; die Option „Propagate“ (standardmäßig aktiviert) erweitert dieselbe Rolle auch auf alle Elemente unterhalb dieses Pfads – sowohl aktuelle als auch zukünftige. Das Ergebnis ist ein Konto mit derselben Reichweite wie „root“, das unter seinem eigenen Namen angemeldet ist.

„Administrator“ ist die umfassendste Rolle, die es gibt, und sie ist die richtige Wahl für das eigene Konto eines Einzelbetreibers, aber sie ist nicht die einzige Form, die eine Berechtigung annehmen kann, sobald diese Plattform kein Ein-Mann-Projekt mehr ist. Proxmox bietet auch engere integrierte Rollen an: „PVEVMAdmin“ für jemanden, der nur VMs verwalten soll, ohne auf Speicher oder Benutzer zuzugreifen, und „PVEAuditor“ für Lesezugriff ohne jegliche Änderungsbefugnis; im selben Dialogfeld „Benutzerberechtigung hinzufügen“ können alle diese Rollen anstelle von „Administrator“ ausgewählt werden, und der Pfad muss nicht unbedingt das Stammverzeichnis sein / Auch das nicht; wenn man den Geltungsbereich auf den eigenen Pfad einer einzelnen VM beschränkt, gilt diese Berechtigung ausschließlich für genau diese VM und für nichts anderes. Bei einem einzigen Administratorkonto auf einem Knoten ist das alles noch nicht erforderlich, aber der Mechanismus ist derselbe, der später unterscheidet, worauf ein kundenorientierter Operator Zugriff hat und was ausschließlich dem Plattformbesitzer vorbehalten ist.

Zwei-Faktor-Authentifizierung hinzufügen

Proxmox unterstützt vier zweite Authentifizierungsfaktoren: TOTP-Codes aus einer Authentifizierungs-App, WebAuthn-Hardware-Schlüssel, Einmal-Wiederherstellungsschlüssel und Yubico OTP; für TOTP sind keine zusätzlichen Anschaffungen erforderlich, weshalb es sich naheliegend als erste Option für die Einrichtung anbietet.

Das Einscannen dieses Codes in eine Authentifizierungs-App und die Eingabe der sechs Ziffern, die dabei generiert werden, bestätigen die Einrichtung tatsächlich; Proxmox aktiviert die TFA für ein Konto erst, wenn durch einen echten Code nachgewiesen wurde, dass das Passwort funktioniert.

Man sollte sich darüber Gedanken machen, bevor es brenzlig wird: Was passiert, wenn das Smartphone, auf dem die Authentifizierungs-App installiert ist, verloren geht, gelöscht wird oder im falschen Moment einfach der Akku leer ist? Genau dafür gibt es Wiederherstellungsschlüssel, eine der anderen drei Authentifizierungsarten: eine Reihe von Einmalcodes, die im Voraus generiert und an einem anderen Ort als auf dem Smartphone selbst gespeichert werden und von denen jeder genau einmal verwendet werden kann, um sich ganz ohne die TOTP-App anzumelden. Ohne eine im Voraus eingerichtete Wiederherstellungsmethode führt der Verlust des einzigen TOTP-Geräts dazu, dass dieses Konto vollständig gesperrt wird, bis ein anderes Administratorkonto oder der Root-Zugriff selbst den TFA-Eintrag aus dem zuvor gezeigten Zwei-Faktor-Bildschirm entfernt.

Firewall aktivieren

Proxmox verfügt über eine vollwertige Firewall, die standardmäßig auf allen Ebenen – sowohl auf Knoten- als auch auf VM-Ebene – deaktiviert ist. Bevor Sie die Firewall aktivieren, sollten Sie sich die Standardrichtlinien einmal durchlesen, da diese festlegen, was geschieht, sobald die Firewall aktiviert wird.

Zwei weitere Einstellungen auf demselben Bildschirm gewinnen an Bedeutung, sobald virtuelle Maschinen ins Spiel kommen – mehr noch als derzeit. „ebtables“, das standardmäßig aktiviert ist, filtert direkt an der Netzwerkbrücke selbst und nicht nur am Netzwerkstack des Hosts. Dies ermöglicht es später, den Datenverkehr einer virtuellen Maschine zu filtern, obwohl dieser technisch gesehen die Eingangs-Chain des Hosts gar nicht erst erreicht; Aus diesem Grund existiert die „Forward Policy“ auch als eigenständige Einstellung, getrennt von der „Input Policy“: Datenverkehr, der auf dem Weg zu oder von einer virtuellen Maschine durch den Host fließt, gilt als weitergeleitet und nicht als Eingangsverkehr, und beide werden anhand völlig unterschiedlicher Regelsätze ausgewertet. Eine für den Management-Port geschriebene Regel gehört unter „Input“; eine Regel, die filtern soll, was eine VM selbst senden oder empfangen darf, gehört an eine andere Stelle – ein Detail, das erst dann von Bedeutung ist, wenn die erste VM aus Teil 3 tatsächlich existiert.

Um eine Regel für die Weboberfläche hinzuzufügen, sind sowohl ein Protokoll als auch ein Port erforderlich; wenn man das Feld „Protokoll“ leer lässt und gleichzeitig einen Zielport festlegt, schlägt der Vorgang sofort fehl – ein echter Fehler, den man besser im Voraus kennt, anstatt ihn erst im Nachhinein zu beheben.

Eine falsche Regel nach der Aktivierung der Firewall ist kein so dauerhafter Fehler, wie es zunächst klingt, da die physische oder virtuelle Konsole, die in diesem Handbuch im Kapitel zur Installation verwendet wurde, die Netzwerk-Firewall gar nicht erst durchläuft; es handelt sich um eine direkte Konsolensitzung, die den Netzwerkstack vollständig umgeht, sodass sie auch dann erreichbar bleibt, wenn die Eingaberegel jeden Port blockiert. Eine Regeländerung oder eine vollständige pve-firewall stop Es gibt immer einen Weg zurück – das sollte man im Hinterkopf behalten, bevor man eine Firewall-Sperre als Grund für eine komplette Neuinstallation betrachtet.

Zertifikate mit ACME automatisieren

Die Warnung bezüglich des selbstsignierten Zertifikats aus dem vorherigen Abschnitt muss nicht dauerhaft bestehen bleiben. Proxmox verfügt über eine integrierte ACME-Unterstützung – dasselbe Protokoll, das auch Let’s Encrypt verwendet – und kann selbstständig ein echtes Zertifikat anfordern und erneuern, sobald es auf eine echte öffentliche Domain verweist.

Es stehen zwei Verzeichnisse zur Auswahl, und es ist wichtig, den Unterschied zu kennen, bevor man sich für eines davon entscheidet.

• Let's Encrypt V2: stellt echte, vertrauenswürdige Zertifikate aus und zählt jeden Versuch auf die öffentlichen Ratenbegrenzungen von Let's Encrypt an. Sollte nur verwendet werden, wenn davon ausgegangen wird, dass die Einrichtung funktioniert.
• Let's Encrypt V2 Staging: stellt Zertifikate aus, denen Browser nicht vertrauen, die jedoch weitaus höhere Grenzwerte aufweisen und speziell dafür entwickelt wurden, die Konfiguration zu testen, ohne das eigentliche Kontingent aufzubrauchen.

Um diesen Schritt in der Praxis durchzuführen, benötigt man eine Domain, die vom öffentlichen Internet aus tatsächlich auf diesen Server verweist – was in einem Labor oder einer Heimlaborumgebung selten der Fall ist. Die oben beschriebene Kontoanmeldung ist der letzte Schritt, den diese Anleitung behandelt; der Rest ergibt sich von selbst, sobald eine echte Domain auf eine echte Bereitstellung verweist.

Was genau dieser Schritt beinhaltet, ist es wert, verstanden zu werden, auch ohne ihn hier vollständig zu beschreiben. Let’s Encrypt muss nachweisen, dass der Server, der ein Zertifikat anfordert, tatsächlich die Kontrolle über die angefragte Domain hat, und das geschieht mithilfe einer Challenge: Bei der gängigen HTTP-01-Methode stellt Proxmox kurzzeitig eine bestimmte Datei unter einer bestimmten URL dieser Domain auf Port 80 bereit, und die Server von Let’s Encrypt rufen diese ab, um dies zu bestätigen; erst dann wird das Zertifikat ausgestellt. Das hat direkte Auswirkungen auf den obigen Abschnitt zur Firewall, da ein Host, bei dem die Firewall aktiviert ist und nur Port 8006 freigegeben ist, diese Überprüfung sofort nicht bestehen würde; Port 80 muss also ebenfalls erreichbar sein, zumindest während der Anfrage. Nach der Ausstellung überprüft Proxmox selbstständig das Ablaufdatum des Zertifikats und erneuert es automatisch lange vor Ablauf der 90-tägigen Gültigkeitsdauer von Let's Encrypt-Zertifikaten. Dabei wird ein Fehler im Aufgabenprotokoll vermerkt, anstatt ein abgelaufenes Zertifikat stillschweigend bestehen zu lassen, falls etwas schiefgeht.

Echte Benachrichtigungen einrichten

Die bei der Installation eingegebene E-Mail-Adresse hat bereits eine Funktion: Proxmox richtet bereits vorab ein Benachrichtigungsziel namens „mail-to-root“ ein sowie einen Matcher, der jede Benachrichtigung dorthin weiterleitet, noch bevor irgendetwas manuell konfiguriert wird.

Dass Ziele und Matcher getrennt sind und nicht in einer gemeinsamen Einstellung zusammengefasst werden, ist beabsichtigt: Ein Ziel legt lediglich fest, wohin eine Benachrichtigung gesendet werden könnte, während ein Matcher entscheidet, welche Benachrichtigungen tatsächlich dorthin gesendet werden. Der oben gezeigte Standard-Matcher leitet alles an „mail-to-root“ weiter, da er keinerlei Filterbedingungen enthält. Ein Matcher kann jedoch ebenso gut anhand des Schweregrads oder der Art des Ereignisses entscheiden und so nur fehlgeschlagene Backups oder Replikationsaufträge an einen Webhook senden, der jemanden benachrichtigt, während routinemäßige Erfolgsmeldungen per E-Mail versendet werden, auf die niemand in Echtzeit reagieren muss. Diese Aufteilung verhindert, dass eine wachsende Plattform entweder den Posteingang mit Routinemeldungen überflutet oder – schlimmer noch – die eine Benachrichtigung, die tatsächlich eine Reaktion erforderte, unter den vielen anderen begräbt.

Für alles, was über E-Mails hinausgeht, deckt ein Webhook-Ziel die meisten gängigen Benachrichtigungssysteme ab: eine URL, eine Methode, benutzerdefinierte Header und einen Textkörper, wobei geheime Daten wie Authentifizierungstoken in einem eigenen Feld gespeichert werden, anstatt im Klartext im Textkörper zu stehen.

Überprüfen Sie die Optionen für Rechenzentren und Knoten

Eine Handvoll Einstellungen, die an keiner anderen Stelle in der Benutzeroberfläche Platz finden, sind unter „Datacenter“, „Optionen“ zu finden; die meisten davon werden einmalig während der Installation festgelegt und danach kaum noch verändert.

Eine Zeile verdient einen zweiten Blick: Das MAC-Adresspräfix – standardmäßig BC:24:11 – ist das, womit jede automatisch generierte Netzwerk-Schnittstelle einer VM beginnt; auf diese Weise lässt sich bei einer Paketaufzeichnung in einem gemeinsam genutzten Netzwerk der Datenverkehr einer Proxmox-VM von allem anderen im Netzwerk unterscheiden. In einem Netzwerk, in dem mehrere Hypervisoren verschiedener Anbieter denselben Switch nutzen, ist dieses Präfix oft der schnellste Weg, um die Frage „Von welchem Rechner stammt dieser Datenverkehr eigentlich?“ zu beantworten, ohne weitere Abgleiche vornehmen zu müssen, da jeder große Hypervisor-Anbieter sein eigenes, eindeutiges Präfix auf dieselbe Weise registriert und verwendet.

Eine zweite RAM-Optimierung erfolgt auf Knotenebene, zusätzlich zur Standard-Ballooning-Einstellung von 80 Prozent: Dabei handelt es sich um die Zielmenge des einer VM zugewiesenen Arbeitsspeichers, die der Balloon-Treiber tatsächlich reserviert halten möchte, während der Rest bei Speicherengpässen an den Host zurückgegeben wird – dieselbe Art von Engpässen, die auch KSM auslöst.

Ballooning funktioniert allerdings nur, wenn das Gastbetriebssystem mitwirkt – eine Annahme, die zwar naheliegend ist, aber nicht blindlings getroffen werden sollte. Es beruht auf einem Treiber, der innerhalb der VM selbst läuft – dem Balloon-Treiber –, der auf modernen Linux- und Windows-Gästen in der Regel zusammen mit dem QEMU-Gast-Agenten installiert ist und einen „Balloon“ aus Speicherseiten aufbläst, deren Nichtnutzung das Gastbetriebssystem zusagt, wodurch diese wieder für den Host freigegeben werden. Eine VM ohne diesen Treiber – insbesondere ein älteres oder minimales Gastbetriebssystem – macht einfach nicht mit: Der Host kann zwar anfragen, aber es wird nichts von ihr zurückgewonnen. Auf einer Plattform, auf der eine Mischung aus verschiedenen Gastbetriebssystemen läuft, wird die tatsächliche Wirksamkeit des Ballooning letztendlich durch die am wenigsten kooperativen VMs begrenzt, unabhängig von dem hier festgelegten Ziel von 80 Prozent.

API-Token für die Automatisierung erstellen

Um Skripte über die Proxmox-API auszuführen, ohne ein Passwort in ein Skript einzugeben, benötigt man zunächst ein Token, das zwar an einen Benutzer gebunden ist, aber unabhängig von dessen Anmeldedaten verwaltet wird.

Das Geheimnis taucht nur einmal auf, unmittelbar nach der Erstellung, und genau darum geht es: Nichts an diesem Entwurf ermöglicht es, es später wiederherzustellen; es kann lediglich als neuer Wert neu generiert werden.

Genau diese Trennung vom eigenen Passwort des Benutzers macht Tokens für die Automatisierung wirklich sinnvoll – und nicht nur zu einem rein bürokratischen Schritt. Sollte das Geheimnis dieses Tokens an einen Ort gelangen, an den es nicht gehört – etwa versehentlich in ein Skript aufgenommen und in ein Repository hochgeladen –, besteht die Lösung darin, dieses eine Token aus der Liste der API-Tokens zu löschen oder neu zu generieren; Das eigene Passwort des OpsAdmins, seine eigenen Anmeldesitzungen und seine eigene TFA-Konfiguration bleiben davon völlig unberührt, da das Token von vornherein niemals Anmeldedaten mit dem Konto geteilt hat, zu dem es gehört. Ein durchgesickertes Benutzerpasswort bedeutet dagegen, dass dieses Passwort und möglicherweise jede damit verbundene Sitzung zurückgesetzt werden muss. Die Privilegientrennung verstärkt diese Isolation noch um einen Schritt: Selbst ein vollständig offengelegtes Token-Geheimnis ist auf die engen Berechtigungen beschränkt, die dem Token selbst ausdrücklich gewährt wurden – ein deutlich kleinerer Schadensumfang als beim vollständigen Konto von „opsadmin“.

DNS, Hosts und den Zustand der Festplatte überprüfen

Eine Handvoll kleinerer Überprüfungen runden eine Neuinstallation ab – sie sind schnell überflogen und lassen sich leicht überspringen, ohne dass man merkt, wie wichtig sie sind.

Ein Host mit nur einem Knoten, der noch mit keinem anderen Server kommunizieren kann, mag den Eindruck erwecken, dass DNS kaum eine Rolle spielt – doch es leistet bereits echte Arbeit, jedes Mal, wenn dieser Knoten nach etwas anhand eines Namens statt einer reinen IP-Adresse sucht. Das Repository ohne Abonnement, das im Schritt „Update“ in Teil 2 per Hostnamen abgerufen wurde, ein NTP-Pool zur Gewährleistung der Uhrgenauigkeit, ein zukünftiger zweiter Knoten, der als Clustermitglied über seinen eigenen Hostnamen statt über seine IP-Adresse beitritt – all das hängt davon ab, dass der hier eingerichtete DNS-Server tatsächlich funktioniert. Ein falscher oder nicht erreichbarer DNS-Server ist hier eine häufige und verwirrende Ursache für ein apt update Es kommt zu Fehlern, die wie ein Netzwerkproblem aussehen, obwohl das Netzwerk selbst einwandfrei funktioniert und lediglich die Namensauflösung nicht funktioniert.

Die Hosts-Datei des Knotens lässt sich direkt in der Benutzeroberfläche bearbeiten, und die Zeile, die Sie überprüfen sollten, ist der Eintrag für den Server selbst: Seine IP-Adresse ist dem bei der Installation festgelegten vollständigen Domänennamen (FQDN) zugeordnet, wodurch dieser Hostname auf den Knoten selbst aufgelöst wird, ohne dass dabei auf einen externen DNS-Server zurückgegriffen werden muss.

Dieser selbst eingegebene Eintrag ist wichtiger, als es auf den ersten Blick scheint, da auch die internen Tools von Proxmox darauf angewiesen sind, dass dieser Hostname – ebenso wie alle externen – korrekt aufgelöst wird. Sollte diese Zeile jemals bearbeitet oder versehentlich entfernt werden, würden die Symptome nicht unbedingt wie ein Problem mit der „hosts“-Datei aussehen; bestimmte interne API-Aufrufe oder später die Cluster-Kommunikation zwischen den Knoten können auf eine Weise fehlschlagen, die zunächst wie ein Netzwerk- oder Zertifikatsproblem aussieht, wobei ein fehlender oder falscher Eintrag in der „hosts“-Datei die eigentliche, viel einfachere Ursache ist.

Der Status der Festplatten wird unter „Festplatten“ angezeigt, wobei neben jedem aufgeführten Gerät die Schaltfläche „S.M.A.R.T.-Werte anzeigen“ zu finden ist; bei echter Hardware mit echten Laufwerken werden dort neu zugewiesene Sektoren, der Verschleißgrad und die Betriebsstunden angezeigt, lange bevor ein Laufwerk tatsächlich ausfällt.

Auf dieser virtuellen Festplatte liefert dieselbe Schaltfläche überhaupt keine Ergebnisse, was jedoch zu erwarten ist und keinen Fehler darstellt: Eine virtuelle Festplatte weist keinen physischen Verschleiß auf, der gemeldet werden müsste.

Auf echter Hardware lohnt es sich, diese Tabelle genauer zu verstehen, anstatt sie nur flüchtig zu überfliegen, da eine kleine Anzahl ihrer Attribute fast die gesamte nützliche Arbeit leistet. Steigt die Anzahl der neu zugewiesenen Sektoren über Null, bedeutet dies, dass das Laufwerk bereits damit begonnen hat, fehlerhafte Sektoren stillschweigend auszusortieren und sie auf Ersatzsektoren umzuverteilen – ein branchenübliches Frühwarnzeichen, das deutlich vor dem tatsächlichen Totalausfall eines Laufwerks auftritt; die Betriebsstunden geben einen klaren Überblick darüber, wie lange ein gebrauchtes Laufwerk bereits im Einsatz war, bevor es überhaupt auf diesem Server landete. Angesichts der in Teil 1 gegebenen Empfehlung, gebrauchte Enterprise-Hardware zu kaufen, weisen die mit diesem Server übernommenen Laufwerke möglicherweise bereits tatsächliche Betriebsstunden und echte Abnutzungserscheinungen aus ihrem früheren Einsatz auf. Daher lohnt es sich, diese Tabelle direkt nach der Installation einmal zu überprüfen, anstatt davon auszugehen, dass die Bezeichnung „refurbished“ bedeutet, dass auch die Laufwerke ausgetauscht wurden.