Proxmox VE hat sich in den vergangenen Monaten insbesondere im Kontext kleinerer und mittelgroßer Virtualisierungsumgebungen zu einer Alternative für entnervte VMware-Kunden entwickelt. Das ist nachvollziehbar, denn laut Proxmox lässt sich ein Cluster mit bis zu insgesamt 16 Proxmox-Hosts gut und sinnvoll verwalten. Diesen Wert von 16 Compute-Nodes erreichen viele Unternehmen selbst in ihren VMware-Setups bisher nicht. Ein weiterer Vorteil ist, dass Proxmox auf Debian GNU/Linux 12 basiert, also mit einer Standarddistribution unter der Haube daherkommt. Dies ermöglicht entsprechend eine Systemadministration, die dem "Debian Way of Things" sehr ähnelt.

Denn bloß weil ein System vor allem als Hypervisor-Knoten zum Einsatz kommt, bedeutet das schließlich nicht, dass es selbst keiner Administration und keiner regelmäßigen Pflege bedarf. Gerade hier tun sich bei vielen Administratoren allerdings Fragezeichen auf. Proxmox VE kommt mit einem GUI daher, das das Hinterlegen vieler Systemparameter komfortabel ermöglicht. Allerdings gibt es eben auch Aufgaben, die per Proxmox-GUI nicht sinnvoll zu erledigen sind. Dann beginnt das Wälzen der Dokumentation und manchmal auch das Rätselraten.

Um solche Jobs, die bisweilen in Proxmox auf dem Host zu erledigen sind, geht es in diesem Workshop. Wir zeigen, wie das bestmöglich gelingt und worauf Sie bei jedem der involvierten Arbeitsschritte achten müssen. Daher beschäftigen wir uns dabei sowohl mit generischen Features, die Debian GNU/Linux betreffen, als auch mit speziellen Shell-Arbeitsschritten, die sich auf Proxmox-Spezifika beziehen. Ein Hauptaugenmerk liegt dabei auf dem Thema Automation. Gerade weil ein Proxmox-VE-System grundsätzlich ein normales Debian GNU/Linux ist, lassen sich viele der nötigen Arbeiten bequem mit einem Automatisierer wie Ansible erledigen. Das kostet zwar etwas Zeit, um die Automatisierung zu konstruieren, doch danach lässt sie sich auch in größeren Proxmox-Clustern beliebig oft replizieren – oder in neuen Clustern, falls das Schaffen einer neuen Proxmox-Umgebung nötig ist.

Proxmox hat zur Verwaltung der physischen Systeme einer Proxmox-Umgebung eigens eine umfangreiche Dokumentation [1] verfasst. Aber längst nicht alle Punkte dieser Dokumentation treffen auf jede Umgebung zu oder sind auf diese anwendbar. Allerdings fällt in der Dokumentation auf, dass sich ein großer Teil davon vor allem auf die Paketverzeichnisse bezieht, die Proxmox verwenden kann. Hier ist grundsätzlich zwischen Umgebungen zu unterscheiden , die Proxmox mit der integrierten Ceph-Version des Herstellers kombinieren, und anderen Verzeichnissen, die ebenfalls zur Anwendung kommen können.

Behalten Sie zunächst ganz grundsätzlich im Hinterkopf, dass Proxmox ein Debian GNU/Linux 12 (Bookworm) ist, das der Hersteller um verschiedene Pakete aus eigenen Verzeichnissen sinnvoll anreichert. Das bedeutet freilich, dass Ihnen in einer Proxmox-Umgebung zunächst der gesamte Umfang an Paketen zur Verfügung steht, die auch Debian GNU/Linux 12 enthält. Auf eben diese stellt Proxmox selbst sogar explizit ab. Logisch, denn warum sollte der Anbieter sich auch die Mühe machen und eigene Pakete bauen, wenn Debian diese bereits anbietet – und dies in einer kuratierten Form, entwickelt und gewartet entlang aller Debian-Qualitätsmaßstäbe.

Entsprechend finden Sie auf einem Proxmox-System im Regelfall die Datei "/etc/apt/sources.list" vor, in der drei Repositories aktiviert sind: "bookworm", "bookworm-updates" sowie "bookworm-security". Diese entsprechen eins zu eins den Vorgaben des Debian-Projekts. Sie zeigen auch auf Debian-Server, sodass ein für Proxmox genutztes System automatisch alle Updates und Sicherheitsaktualisierungen erhält, die Debian auch für die eigene Distribution zur Verfügung stellt. Es empfiehlt sich, an dieser Datei nichts zu verändern, denn für lokale Änderungen sieht Debian 12 stattdessen vor, eigene Paketquellen in individuellen Dateien in "/etc/ apt/sources.list.d" anzulegen.

Erliegen Sie an dieser Stelle bitte nicht der Versuchung, dort eine Datei mit Paketquellen für das "debian-backports"-Verzeichnis zu hinterlegen, es sei denn, es gibt dafür einen expliziten Grund. Gerade weil Debian GNU/Linux eher altbacken im Hinblick auf seine Software wirkt, hat es sich bei manchem Debian-Administrator eingebürgert, die Backports pauschal einzuschalten. Dann erhält der Admin neuere Versionen bestimmter Pakete, die die Entwickler für die letzte stabile Debian-Version neu kompiliert und wenn nötig angepasst, also "zurückportiert" haben. Hier gibt es beispielsweise einen deutlich neueren Kernel (6.12.9) statt jenen, der Bookworm ab Werk beiliegt. Das Problem dabei ist jedoch, dass manche der Backports-Pakete mit Proxmox-spezifischen Paketen kollidieren. Dann entsteht schlimmstenfalls ein Chaos von Komponenten, die nicht aufeinander abgestimmt sind und eine Neuinstallation des Systems erzwingen. Einen deutlich neueren Kernel liefert Proxmox zudem selbst aus. Und der ist auf Herz und Nieren darauf getestet, die von Proxmox benötigten Funktionen zuverlässig anzubieten.

Welche Repositories Proxmox zu denen von Debian hinzufügt, sehen Sie im Ordner "/etc/apt/sources.list.d". Hier finden sich auf einer normalen Proxmox-Maschine die Dateien "pve-enterprise.list" sowie "ceph.list". Das "pve-enterprise.list"-File enthält dabei auf Systemen mit aktiver Subskription stets die Quellen für Proxmox Enterprise. Die Ceph-Datei ist vorrangig für Proxmox mit aktiviertem Ceph relevant. Sie steht standardmäßig noch auf der veralteten Ceph-Version "Quincy". Ersetzen Sie in dieser Datei "quincy" durch "reef" oder noch besser "squid", um aktuellere Ceph-Versionen beziehungsweise die neueste Ceph-Fassung Squid zu verwenden.

Gerade die Verwaltung von Paketquellen lässt sich mittels Automation übrigens fast schon trivial erreichen. Idealerweise haben Sie für Ihre Proxmox-Umgebung auf einem Linux-System Ansible eingerichtet, eine "hosts"-Datei mit dem Ansible-Inventar für Ihre Umgebung angelegt und "Ansible Playbook" installiert. Das Beispiel aus Listing 1 würde bereits ausreichen, um anstelle des "ceph-quincy"-Repositories jenes für die Ceph-Version Squid zu verwenden. Integrieren Sie den beschriebenen Task wahlweise in ein Playbook oder in eine separate Rolle, die Sie dann per Playbook auf einen Host anwenden.

Dies ist übrigens ein guter Zeitpunkt, um über die Installation von Proxmox per se zu sprechen. Die kann auf zwei Weisen geschehen: Einerseits bietet Proxmox eine eigene ISO-Datei an, mittels derer sich ein bereits modifiziertes Debian samt Proxmox leicht einspielen lässt. Dazu bedient der Hersteller sich einer vorkonfigurierten, leicht modifizierten Version des Debian-Installers, also des offiziellen Installationswerkzeugs für Debian GNU/ Linux. Die Variante B besteht darin, ein reguläres Debian GNU/Linux 12 zu installieren und im Nachgang die Proxmox-Komponenten auf das System zu holen. Dies ist eine offiziell unterstützte Methode, die einen großen Vorteil bietet: Es kann der reguläre Debian-Installer zum Einsatz kommen.

Diesen können Sie in seinem Werken mittels einer Preseeding genannten Technologie nach Belieben beeinflussen. Auch hier ist das Thema Automatisierung wieder von großer Bedeutung. Denn wenn Sie sich für die dem ersten Anschein nach weniger komfortable Variante einer Installation auf Debian-Grundlage entscheiden, haben Sie im nächsten Schritt und noch vor der Installation von Proxmox die Möglichkeit, das Grundsystem nach Belieben einzurichten. Das Gros der Proxmox-Installationen weltweit dürfte im geschäftlichen werkeln, was fast immer irgendeine Art von Complianceregime mit sich bringt. Betreiben Sie beispielsweise ein zentrales Verzeichnis für die Nutzer (LDAP- oder Active-Directory-basiert), sind Sie gewiss bestrebt, auch die Linux-Benutzerverwaltung an diese Verwaltung anzuflanschen. Das ist nicht weiter kompliziert, Komponenten wie SSSD und die LibNSS erledigen den größten Teil der Arbeit dafür voll automatisch.

Das bedingt allerdings, dass diese Werkzeuge richtig aufgesetzt sind. Und hier spielen wieder Ansible und vergleichbare Tools eine Rolle. In den meisten Infrastrukturen ist die Implementierung der zentralen Compliancevorschriften für Linux-Systeme ohnehin automatisiert. Wollen Sie von dieser Automatisierung profitieren, entscheiden Sie sich besser für die standardisierte Debian-Installation mit anschließendem automatischen Setup des Systems. Gut möglich, dass dann auch Funktionen wie eine Installation per Netz und DHCP/PXE/TFTP möglich sind – ein Feature, das der Proxmox-Installer selbst nicht beherrscht. Im Hinblick auf die Unterstützung durch den Hersteller ändert die Installationsmethode übrigens nichts – Proxmox erkennt beide Wege als gleichwertig an. Der riesige Vorteil der Methode mittels Debian und der Nutzung vorhandener Automatisierung besteht aber zweifelsohne darin, dass Sie sich den größten Teil der Arbeit im Hinblick auf die Administration eines Proxmox-Hosts ersparen. Denn ein vorhandenes Automatisierungs-Framework nimmt Ihnen diese Arbeit in dem Szenario ab.

Wer lieber ein Debian installiert und es danach in Proxmox umwandelt, sieht sich freilich mit der Herausforderung konfrontiert, dies technisch bestmöglich abzuwickeln. Auch hier profitiert Proxmox davon, dass es im Netz mittlerweile eine große Nutzergemeinde gibt, die sich mit verschiedenen Aspekten dieses Problems bereits befasst hat. Besonders hervorzuheben ist die "ansible-proxmox"-Rolle [2] von Musee Ullah. Die Rolle leistet alle nötigen Schritte für das Umwandeln eines Debian-12-Systems in einen Proxmox-Knoten mithilfe einer Ansible-Automatisierung.

Dabei bietet sie diverse zusätzliche Features wie die Möglichkeit, mittels einer einfachen Konfigurationsänderung in Ansible PCI Passthrough zu aktivieren – was in Proxmox per Default deaktiviert ist, um Kompatibilitätsproblemen vorzubeugen. Auch lässt sich mittels der Rolle automatisiert eine lokale Storage-Konfiguration für Proxmox hinterlegen und die in Proxmox integrierte RBAC-Verwaltung so einrichten, dass sie den lokalen Anforderungen entspricht.

Schließlich unterstützt die Ansible-Rolle auch den Proxmox-Cluster-Modus. Damit ist sie besonders attraktiv für Umgebungen, in denen noch kein Ansible läuft, weil die grundlegende Struktur für ein Ansible-Setup leicht und schnell zu erstellen ist. Lediglich einen Nachteil hat die Rolle: Sie bietet nur eingeschränkte Unterstützung für Systeme, die mittels Proxmox-ISO installiert worden sind. Stattdessen fokussiert sie sich auf frisch installierte Debian-Systeme und integriert diese in Proxmox.

Das tut sie indes ausgesprochen gut. Möchten Sie ein einzelnes Proxmox-System betreiben, errichten Sie mit einer frischen Debian-12-Installation und dem Playbook aus Listing 2 einen fertigen Proxmox-Knoten mit Weboberfläche und aktiviertem PCIe-Passthrough. Voraussetzung dafür ist allerdings, dass auf dem Debian-System das sudo-Paket vorliegt. Zudem müssen Sie im Vorfeld mittels

die vier benötigten Rollen installieren, die Ansible braucht, um die Dienste entsprechend einzurichten. Bonuspunkte gewinnt das Beispiel-Playbook, weil es die automatisierte Zeitsynchronisation mittels Chrony ebenfalls einrichtet, was für Ceph unumgänglich ist.

Listing 2 rollt zusammen mit Proxmox auch Ceph aus und integriert dieses in die Umgebung. De facto automatisieren Sie mit Ansible also in wenigen Schritten das Proxmox-Setup und damit implizit auch die Verwaltung der Hosts weitgehend komplett. Das geht so leicht von der Hand, dass es eine Überlegung sein kann, einen bestehenden Cluster auf Ansible-Grundlage neu zu konstruieren.

Ein großer Vorteil von Proxmox ist zweifelsohne der Umstand, dass es seine Updates regulär über die Paketverwaltung des Debian-Systems erhält. Das bedeutet, dass die Kommandosapt update  und apt dist-upgrade  alle nötigen Arbeiten erledigen. Wenn Sie den QA-Mechanismen von Debian und Proxmox so weit vertrauen, dass Sie das automatische Einspielen von Paketen erlauben wollen, aktivieren Sie mittels

die nötigen Pakete und setzen in "/etc/apt/ apt.conf.d/20auto-upgrades" die Parameter "APT::Periodic::Update-Package-Lists" und "APT::Periodic::Unattended-Upgrade" auf "1". Fehlt die Datei, legt

diese an. Danach holt Ihr System regelmäßig sowohl aktualisierte Paketlisten als auch die aktuellen Pakete automatisch bei den konfigurierten Spiegeln ab und rollt sie aus. Vorsicht ist allerdings beim Parameter "pve_reboot_on_kernel_update" geboten, falls Sie diesen wie in Listing 2 gezeigt, zusammen mit dem Ansible-Modul einsetzen. Dergestalt würde Ihr System nach dem Einspielen eines neuen Kernels im Rahmen der Unattended-Upgrades neu starten, ein Effekt, den Sie vermutlich nicht wünschen. Hier ist es besser, "pve_reboot_on_kernel_update" auf "false" zu setzen.

Möglicherweise standen auch Sie schon einmal vor dem Problem, dass Sie die Netzwerkvorgaben für Proxmox ändern wollten, dabei aber schnell ins Straucheln geraten sind. Das liegt einerseits an der Komplexität, die Netzwerke in Virtualisierungsumgebungen erreichen können. Hier existiert die physische Netzwerkkarte, eine Bridge für die Verwendung mit Proxmox, möglicherweise eine Konfiguration für LACP oder ein anderes Bonding, VLAN-Interfaces darauf oder darunter und so weiter.

Erschwerend kommt hinzu, dass Proxmox zumindest im Augenblick seine Netzwerke klassisch so konfiguriert, wie es auf Debian-Systemen seit vielen Jahren Usus ist. Zum Einsatz kommt also nicht ein modernes Konstrukt wie NetworkManager oder Networkd sondern ganz klassisch "iproute2" mit "/etc/network/interfaces". Nur dieser Ansatz ist auch mit dem Proxmox-UI integriert, das es bis zu einem bestimmten Grad ermöglicht, händische Anpassungen an der Netzwerkkonfiguration vorzunehmen (Bild 2).

Für Sie bedeutet das, sich mit der altbackenen Art der Netzwerkkonfiguration in Proxmox (zwangsweise) anzufreunden – immerhin funktioniert diese gut und zuverlässig. Für Details sei auf die bereits erwähnte Proxmox-Dokumentation verwiesen. Diese enthält viele konkrete Beispiele für die verschiedensten alltäglichen Szenarien. Wir raten an dieser Stelle explizit davon ab, die Netzwerkkonfiguration umständlich zu automatisieren. Das führt bei einer Fehlkonfiguration dazu, dass Sie den Zugriff auf den Proxmox-Host verlieren und den Gang ins RZ antreten dürfen, um sich per Terminal selbst wieder reinzulassen.

Proxmox wünscht bevorzugt die Verwendung des ZFS-Dateisystems. Das einst von Oracle entwickelte ZFS genießt in der Linux-Community generell hohes Ansehen, allerdings ist es bis heute vor allem aus lizenzrechtlichen Gründen nicht Bestandteil des Linux-Kernels. Die Shell bietet Ihnen umfassende Möglichkeiten, die gegebene Storage-Konfiguration eines Systems zu beeinflussen. Standardmäßig legt Proxmox – sofern per ISO installiert – selbst ZFS-Pools an. Dies erfolgt zumindest für das root-Verzeichnis (also das mit den virtuellen Festplatten für die VMs) sowie das dazu gehörende ISO-Verzeichnis für ISO-Dateien, mittels derer Sie VMs aufsetzen.

Der zpool-Befehl bietet Ihnen auf der Kommandozeile umfassende Möglichkeiten, die ZFS-Konfiguration zu manipulieren. Dies ist aber kein Proxmox-Spezifikum, sondern Teil der ZFS-on-Linux- Werkzeuge. Hilfreich kann die Arbeit mit ZFS auf der Shell etwa sein, wenn Sie Ihre Proxmox-Systeme um neue Laufwerke erweitert haben und diese in den Cluster integrieren wollen, ohne gleich auf ein Werkzeug wie Ceph zu setzen. Haben Sie alternativ das System mittels Debian-Grundinstallation ausgerollt, holt der Proxmox-Installer das Anlegen der ZFS-Pools während des Aufrufes ebenso nach wie das beispielhafte Ansible-Playbook bei Verwendung der Ansible-Rolle.

Die Notwendigkeit, Proxmox in größeren Umgebungen an ein möglicherweise vorhandenes Verzeichnis von Benutzern anzuschließen, haben wir bereits erwähnt. Wie Sie das in der Praxis am besten erledigen, hängt von der Art der Installation ab. Grundsätzlich ist es keine gute Idee, die Systeme automatisiert oder händisch mittels SSSD und NSS zu konfigurieren. Denn dafür bietet Proxmox eigene Mechanismen, die etwa auch dafür sorgen, dass die Anmeldung per Benutzer ans GUI über die definierten Verzeichnisse klappt.

Haben Sie Proxmox per ISO-File installiert, erledigen Sie die Verzeichniskonfiguration am besten per grafischer Oberfläche. Setzen Sie stattdessen auf Debian und Automatisierung mit Ansible, bietet die erwähnte Ansible-Rolle die notwendigen Parameter für eine Proxmox-kompatible Konfiguration. Diese sorgt sowohl dafür, dass die Anmeldung per PAM möglich ist, als auch via LDAP oder Active Directory. Nicht vergessen: Der "Proxmox VE Authentication Server", der die Benutzerverwaltung in einer Proxmox-Umgebung autark übernehmen kann.

Bodenständiger begegnen Ihnen auf dem Proxmox-Host die Themen Monitoring und Trending. Hier kommt es vor allem auf die Monitoringsoftware an, in die Sie Proxmox integrieren. Proxmox unterstützt seinerseits das Monitoring mit Graphite und InfluxDB. Der Standardport für Graphite ist 2003, was Ihnen erlaubt, einer bestehenden Graphite-Instanz Proxmox-Daten über diesen Pfad ohne weitere Konfiguration zukommen zu lassen. Soll InfluxDB zum Einsatz kommen, ist der Zielport 8089 – allerdings per UDP. Dies bedingt in InfluxDB unter Umständen Konfigurationsänderungen, weil InfluxDB normalerweise nur TCP/IP nutzt. Wenn Sie mittelssmartctl -s on /dev/sdc die SMART-Funktion einzelner Laufwerke aktivieren, tauchen diese automatisch in den ausgelesenen Monitoringdaten auf. Auch hier macht Proxmox Ihnen das Leben also sehr leicht.

Etwas komplizierter ist der Einsatz der Zeitreihendatenbank Prometheus, denn in der Standardkonfiguration verfügt Proxmox VE erstmal über keinerlei Integration mit dieser. Die lässt sich allerdings flott nachrüsten, denn einen Exporter für die Arbeit mit Prometheus stellt der Anbieter selbst zur Verfügung, wenn auch nur in Form des fertigen Python-Paketes [3]. Sie Installieren das Modul mittels

Die bessere Variante ist allerdings, dafür zu sorgen, dass die Docker-Laufzeitumgebung in der Community-Edition auf dem System ausgerollt ist. Dann besorgen Sie sich den Container mittels

und starten ihn durch

Damit das funktioniert, muss die Datei "/root/pve.yml" als valide Konfigurationsdatei für den Exporter existieren. Im Anschluss hinterlegen Sie in Prometheus den Proxmox-Host mit Port 9221 als Target und erhalten sodann die PVE-Daten direkt in Ihre Zeitreihendatenbank. Von dort aus verarbeiten Sie diese im Alertmanager weiter oder lassen sie mittels Grafana aufbereiten.

Der große Vorteil von Prometheus ist freilich, dass Sie auf dieselbe Weise auch andere Exporter wie den klassischen "node-exporter" ausrollen können. Dieser enthält eine Vielzahl von Werten betreffend des Systemstatus und seiner Hardware, der Dateisysteme und vieler weiterer grundlegender Vitalwerte. Eine valide Konfigurationsdatei finden Sie im Quelltext des PVE-Exporters. Beispiele dafür, wie Sie einen Docker-Container als Systemd-Dienst betreiben, finden sich im Netz zuhauf. Das ist jedenfalls nötig, soll der PVE-Exporter durchgehend laufen.

Es ist übrigens nicht so, dass sich alle CLI-Befehle in Proxmox ausschließlich auf das Grundsystem beziehen. Vielmehr erledigen Sie auf der Kommandozeile relativ unkompliziert auch Aufgaben mit direktem Proxmox-VE-Bezug, die per GUI gar nicht oder nur sehr kompliziert möglich wären. Ein gutes Beispiel dafür ist die Migration einer Proxmox-VM von einem Server auf einen anderen Server. Gemeint ist dabei der dauerhafte Umzug der VM, nicht die Failover-Migration im Falle eines Fehlers.

Diesen Vorgang vollziehen Sie problemlos, indem Sie zunächst ein Backup der Instanz im ausgeschalteten Zustand an seiner derzeitigen Heimat anlegen. Das geht über den Punkt "Backup" in der Detailansicht der Instanz. Auf dem Host liegt die Backupdatei anschließend in "/var/lib/vz/dump/". Verbinden Sie sich mit dem Server per SSH und kopieren Sie die Datei etwa perscp  an denselben Ort auf dem künftigen Zielsystem. Navigieren Sie per GUI auf diesem Host zum Menüpunkt "local" beim Speicher auf der linken Seite im Hauptmenü. Dort sollte das kopierte Backup nun bereits zu sehen sein (Bild 3). Klicken Sie darauf und dann oben auf "Restore" – den Rest erledigt Proxmox anschließend automatisch.

Die Instanz taucht auf dem neuen Host links in der Leiste ein paar Sekunden später auf und lässt sich nun ebenso starten oder stoppen wie zuvor an ihrer alten Lagerstätte. Je nach Distanz zwischen den Systemen dauert das Kopieren des Backups die meiste Zeit. Die restlichen Schritte sind in wenigen Sekunden erledigt, sodass der Umzug unkompliziert verläuft.

Die einzige echte, wiederkehrende Aufgabe bei der Verwaltung von Proxmox-Hosts ist das regelmäßige Einspielen von Backups. Ist ein Proxmox-System einmal aufgesetzt, ändert sich an seiner Grundkonfiguration im Normalfall nur noch wenig. Hier bietet Proxmox dem Administrator zudem die Möglichkeit, umfassend Automatisierung einzusetzen, wenn die Umgebung auf einer Debian-Grundinstallation basiert.