Als Testsysteme kamen zwei Dell-Server vom Typ PE T640 zum Einsatz, von denen jeder über zwei Daten-SSDs für den ZFS-Mirror-Pool verfügte. Das von Proxmox für die Virtualisierungsplattform verwendete Debian-Linux-OS installierten wir auf einer eigenen Disk. Für das Basis-Setup hatten wir nur die OS-Disk in den Server eingesteckt, die zwei SSDs für den ZFS-Speicherpool fügten wir erst später hinzu. Die Installation der zwei Server war nach wenigen Minuten erfolgreich abgeschlossen und wir konnten uns anschließend per Webbrowser an der Proxmox-Konsole anmelden.
Die Zugriffsberechtigungen für die Systemadministratoren lassen sich zum einen über die in Proxmox integrierte Benutzerverwaltung zuweisen. Zum anderen ist es möglich, hierfür einen vorhandenen LDAP-Verzeichnisdienst wie zum Beispiel das Active Directory von Microsoft zu nutzen.
Nachdem das Basis-Setup abgeschlossen war, fügten wir bei beiden Nodes die zwei SATA-SSDs als Speicherort für die VMs hinzu. Dann erstellten wir mit diesen Disks auf jedem Host ein neues ZFS-Filesystem im Mirror-Modus. Wir vergaben auf beiden Hosts denselben Namen ZFSPOOL, damit der Proxmox-Cluster die replizierten VMs bei einer VM-Live-Migration oder einem Host-Ausfall auf dem zweiten Node direkt von der Replica-Kopie starten kann. Damit waren alle Vorarbeiten erledigt und wir erzeugten den Proxmox-Cluster, indem wir auf dem ersten Host den Create-Cluster-Befehl ausführten. Dann fügten wir den zweiten Host hinzu. In der Webkonsole erschien daraufhin ein neuer Datacenter-Eintrag mit dem Namen des neuen Clusters.
Um die Server-Virtualisierung mit Proxmox zu testen, erstellten wir eine neue VM mit Windows 2025 und eine weitere Linux-VM mit Ubuntu 24.04. In beiden Fällen legten wir über das Create-VM-Menü eine virtuelle Hülle mit der gewünschten Hardware-Ausstattung an.
In den VM-Einstellungen wählten wir die passende ISO-Datei aus. Die zwei VMs ließen sich erfolgreich installieren und erhielten vom DHCP-Server des Testnetzes automatisch eine IP-Adresse. Neben VMs unterstützt Proxmox auch den Betrieb von Linux-Containern (LXC), für die ein eigenes Container-Toolkit zur Verfügung steht. Für die Migration von VMware-VMs bietet Proxmox eine recht einfache Möglichkeit, indem der Systemverwalter die Datastores von ESXi-Hosts auf dem Proxmox-Server als Storage-Device hinzufügt und die VMware-VMs dann auf die Proxmox-Speicherpools migriert.
Hochverfügbarkeit konfigurieren
Um die Hochverfügbarkeitsfunktionen eines Proxmox-Clusters nutzen zu können, muss der Systemverwalter zunächst auf der Datacenter-Ebene mit den Hosts eine HA-Gruppe erstellen. Das HA-Setup richtet automatisch ein lokales Quorum-Device ein, das beim Ausfall eines Hosts entscheidet, welcher Node die Cluster-Ressourcen übernehmen darf. Für 2-Node-Cluster empfiehlt Proxmox, für das Quroum ein externes Speichergerät zu verwenden, da es in der Standardkonfiguration mit einem lokalen Quorum beim Ausfall eines Nodes zu einer Split-Brain-Situation kommen kann und sich die Cluster-Ressourcen dann nicht mehr starten lassen. Für dieses Szenario gibt es einen Workaround, den wir bei unseren Ausfalltests verwenden mussten, um die VMs mit nur einem aktiven Host wieder hochfahren zu können.
Damit eine VM beim Ausfall eines Hosts automatisch auf einem anderen Cluster-Knoten neu gestartet werden kann, muss der Systemverwalter die HA-Funktion auch in den VM-Einstellungen aktivieren. Eine manuelle Live-Migration von VMs lässt sich auch ohne HA-Konfiguration durchführen. Am schnellsten erfolgt das Verschieben, wenn für eine VM die Replikation auf den anderen Host aktiviert wurde. In diesem Fall muss der Storage nicht vollständig übertragen werden, sondern nur das Delta der seit der letzten Synchronisierung veränderten Daten.
Wir richteten für beide VMs eine Replikation mit dem standardmäßig eingestellten Intervall von 15 Minuten ein. Über die Kommandozeile der Proxmox-Hosts lässt sich mit dem Befehl
pvesr create-local-job
auch ein kürzerer Abstand von zum Beispiel einer oder fünf Minuten konfigurieren. Die initiale Replikation der W2025-VM mit 32 GByte Daten hat ungefähr fünf Minuten gedauert. Das Verschieben der VM auf den anderen Proxmox-Knoten hat dann nur noch knapp eine Minute benötigt, weil die Daten auf der anderen Seite bereits vorhanden waren und nur das Delta und der RAM-Inhalt übertragen werden mussten.
Snapshots, Clones, Templates
Der für den Test genutzte ZFS-Storage-Pool unterstützt VM-Snapshots, um Server zum Beispiel nach einem fehlgeschlagenen Software-Update schnell wieder auf den ursprünglichen Ausgangszustand zurücksetzen zu können. Wir testeten das Feature, indem wir von der W2025-VM einen Snaphot erstellten und anschließend auf dem Server das Tool WinSCP installierten. Nachdem wir das Setup abgeschlossen hatten, setzten wir die VM über die Proxmox-Webkonsole wieder auf den Stand des zuvor erstellten Snapshots zurück. Das WinSCP-Tool war anschließend vom Server wieder verschwunden.
Die Proxmox-Konsole enthält auch eine Backup-Funktion für die Sicherung von VMs auf den lokalen Storage des Host-Systems.
Backup-Daten sollten jedoch nicht auf demselben System gespeichert werden, auf dem auch die Primärdaten liegen. Deshalb empfiehlt es sich, für die Sicherung von VMs eine Backup-Lösung auf einer dedizierten Hardware-Plattform einzusetzen. Proxmox bietet hierfür eine eigene Backup-Software an, die sich auch für größere Umgebungen eignet.
Mit den Clone- und Template-Funktionen von Proxmox lassen sich neue VMs schnell bereitstellen. Wir erzeugten mit der W2025-VM per Clone-Funktion in wenigen Minuten einen zweiten identischen Server, bei dem wir im Nachgang noch den Host-Namen und die IP-Konfiguration anpassten. Anschließend ließ sich die neue VM erfolgreich hochfahren. Die Template-Funktion wandelt eine vorhandene VM in eine Vorlage für die schnelle Erzeugung von Full Clones oder Linked Clones um. Wir konvertierten die Linux-VM in ein Template, aus dem wir anschließend mit dem Full-Clone-Befehl eine neue VM erstellten, die sich erfolgreich starten ließ.