Zum Hauptinhalt springen

Lenovo XClarity Integrator für Proxmox

Lenovo XClarity Integrator für Proxmox ist ein Python-basiertes Tool, das automatisierte Firmware-Updates für Proxmox Cluster-Umgebungen auf Lenovo ThinkSystem-Servern ermöglicht. Es integriert sich mit dem Lenovo XClarity Administrator (LXCA), um sicherzustellen, dass Ihre Infrastruktur stets mit den neuesten Hardware-Updates versorgt wird, Ausfallzeiten minimiert und manueller Aufwand reduziert wird.

Diese Lösung richtet sich an IT-Administratoren, die das Update-Management ihrer Proxmox-Cluster vereinfachen möchten.

Funktionen​

  • Nahtlose Integration mit der Lenovo XClarity Administrator REST API.
  • Automatische Firmware-Updates basierend auf Richtlinien, die über den Lenovo XClarity Administrator angewendet werden.
  • Cluster-bewusste Update-Operationen zur Reduzierung von Serviceunterbrechungen.
  • Protokollierung und Berichterstattung der Update-Ergebnisse.
  • Anpassbare Konfiguration über config.ini.

Funktionsweise​

Beim Ausführen des Programms werden folgende Schritte durchgeführt:

  • Lädt Laufzeitparameter aus der Datei config.ini
  • Fragt nach dem Master-Passwort, falls Passwörter sicher (verschlüsselt) gespeichert sind
  • Prüft, ob die Hosts von LXCA verwaltet werden und eine Firmware-Compliance-Richtlinie zugeordnet ist
  • Prüft, ob die Hosts mit der zugewiesenen Compliance-Richtlinie konform sind
    • Falls nicht, werden VMs und CTs nacheinander vom Host evakuiert, das Firmware-Update durch LXCA durchgeführt und die VMs anschließend auf den aktualisierten Host zurückverschoben

Voraussetzungen​

  • Python: 3.x (getestet mit Python 3.11 und Python 3.13 (striktes SSL))
  • Die in requirements.txt aufgeführten Python-Bibliotheken
  • Eine laufende Lenovo XClarity Administrator-Instanz mit passenden API-Zugangsdaten
  • Ein Proxmox VE Cluster oder ein Proxmox VE Einzelknoten auf von Lenovo XClarity Administrator unterstützten Servern (getestet nur auf Lenovo ThinkSystem Servern)
  • Eine Compliance Policy, die jedem Server im Cluster zugewiesen ist
  • Ein Betriebssystem, auf dem das Tool ausgeführt wird (Linux wird bevorzugt, sollte aber auch unter Windows funktionieren). ACHTUNG: Die Ausführung direkt auf Proxmox-Servern wird nicht unterstützt/empfohlen.

Installation​

  1. Entpacken Sie das Paket auf Ihrem System (am besten auf Linux-Basis)

  2. (Optional, aber empfohlen) Einrichten einer Python Virtual Environment 2.1. Erstellen Sie ein neues virtuelles Environment im Projektverzeichnis:

    python -m venv venv

    2.2. Aktivieren Sie das virtuelle Environment:

    • Unter Linux/Mac:
    source venv/bin/activate
    • Unter Windows:
    venv\Scripts\activate

  3. Installieren Sie die Abhängigkeiten:

    pip install -r requirements.txt

  4. Bereiten Sie Ihre Konfigurationsdatei vor (siehe Config File unten).

Konfigurationsdatei​

  1. Überprüfen Sie die Beispiel-Konfigurationsdatei config.ini.sample. Diese Datei enthält alle konfigurierbaren Parameter, darunter:

    • LXCA Hostname oder IP
    • LXCA API-Zugangsdaten
    • Proxmox Cluster-Knotenliste

  2. Kopieren Sie das Beispiel und passen Sie es an:

    cp config.ini.sample config.ini

Bearbeiten Sie config.ini mit Ihrem bevorzugten Editor, um umgebungsspezifische Einstellungen zu deklarieren.

Feld-Details​

Proxmox Abschnitt​

  • PROXMOX_USER - Pflichtfeld - Dieses Feld enthält den Benutzernamen, der berechtigt ist, auf den Proxmox-Cluster (jeden Knoten im Cluster) zuzugreifen und Aktionen wie das Migrieren von VMs durchzuführen. Es MUSS ein Linux-Benutzer sein, da dieser auch benötigt wird, um den Knoten in den Wartungsmodus zu versetzen. - Standard = root@pam (ohne Anführungszeichen).

  • PROXMOX_PASS - Pflichtfeld - Hier muss das Passwort für den im Feld PROXMOX_USER angegebenen Benutzer gespeichert werden. Das Passwort kann unverschlüsselt (am einfachsten, weniger sicher) oder verschlüsselt (sicherer) gespeichert werden, jeweils ohne Anführungszeichen. Hinweise zum Speichern eines verschlüsselten Passworts in der Konfigurationsdatei finden Sie im Abschnitt "Sicherheit" unten.

  • PROXMOX_VERIFY_SSL - Pflichtfeld - Wenn Sie die Validierung des SSL-Zertifikats überspringen möchten, können Sie dieses Feld auf False setzen. Bei selbstsignierten Zertifikaten ist dies meist üblich. Wenn Sie selbstsignierte Zertifikate und Python > 3.11 verwenden, MÜSSEN Sie diesen Parameter auf False setzen. Sie können dieses Feld auf True setzen, indem Sie die Hinweise im Abschnitt "CA-Zertifikatsvalidierung" befolgen.

  • CLUSTER_NODES - Pflichtfeld - Dieses Feld enthält die Hosts, die vom Tool aktualisiert werden können. Das Feld ist ein Array, in dem jedes Element ein JSON-ähnliches Objekt ist, das drei Parameter für den Host beschreibt: -- xcc = die IP-Adresse des Host-XCC (MUSS die IP-Adresse sein, nicht der Hostname) -- pve_ip = die IP-Adresse des PVE-Hosts -- pve_host = der Hostname des PVE-Hosts

Das erwartete Format für den Host ist: {"xcc":<IP_xcc_node>, "pve_ip": <IP_node> , "pve_host": <NAME_node>}

  • TIMEOUT_HOST - Optional - Hier kann die maximale Zeit (in Sekunden) angegeben werden, die auf den Abschluss des Upgrade-Prozesses gewartet werden soll. - Standard = 3600

  • TIMEOUT_VM - Optional - Hier kann die maximale Zeit (in Sekunden) angegeben werden, die auf VM-Operationen (Migration, Herunterfahren) gewartet werden soll, bevor ein Fehler zurückgegeben wird. - Standard = 300 Sekunden

  • VM_LOCAL_DISKS - Pflichtfeld - Erlaubte Werte sind: POWEROFF, um dem Tool das Herunterfahren von VMs mit lokalen Disks (z.B. CD-ROM, VM-Disks auf lokalem Storage) zu erlauben, FAIL, um die Prozedur zu stoppen und manuelle Nachbesserung zu ermöglichen. - Standard = FAIL

  • VM_LOCAL_RESOURCES - Pflichtfeld - Erlaubte Werte sind: POWEROFF, um dem Tool das Herunterfahren von VMs mit lokalen Ressourcen (z.B. PCIe-Adapter) zu erlauben, FAIL, um die Prozedur zu stoppen und manuelle Nachbesserung zu ermöglichen. - Standard = FAIL

  • VM_LOCAL_DISKS_EXPERT - Experimentell - Optional - Nutzung auf eigene Gefahr!! - NUR FÜR EXPERTEN - Nicht verwenden, wenn Sie nicht genau wissen, was Sie tun. Dieser Parameter erlaubt die Migration von VMs mit lokalen Disks (ohne CD-ROM). Sie müssen selbst sicherstellen, dass alle Anforderungen zur Laufzeit erfüllt sind (z.B. gleiche Storage-Namen, genügend Speicherplatz, etc). Erlaubte Werte sind: True, das Programm versucht, die VM mit lokaler Disk (ohne lokale CD-ROM) zu migrieren, oder False, das Programm folgt der Einstellung in VM_LOCAL_DISKS. Standard = False

LXCA Sitzung​

  • LXCA_HOST - Pflichtfeld - Dieses Feld enthält die IP-Adresse (oder den Hostnamen, falls per DNS auflösbar) der Lenovo XClarity Administrator (LXCA)-Instanz, die die Proxmox-Server verwaltet.

  • LXCA_USER - Pflichtfeld - Dieses Feld enthält den LXCA-Administrationsbenutzernamen, der berechtigt ist, Updates auf den von Proxmox verwalteten Servern durchzuführen.

  • LXCA_PASS - Pflichtfeld - Hier das Passwort für den im Feld LXCA_USER angegebenen LXCA-Benutzer eintragen. Das Passwort kann unverschlüsselt (am einfachsten, weniger sicher) oder verschlüsselt (sicherer) gespeichert werden, jeweils ohne Anführungszeichen. Hinweise zum Speichern eines verschlüsselten Passworts in der Konfigurationsdatei finden Sie im Abschnitt "Sicherheit" unten.

  • LXCA_VERIFY_SSL - Pflichtfeld - Wenn Sie die Validierung des SSL-Zertifikats überspringen möchten, können Sie dieses Feld auf False setzen. Bei selbstsignierten Zertifikaten ist dies meist üblich. Wenn Sie selbstsignierte Zertifikate und Python > 3.11 verwenden, MÜSSEN Sie diesen Parameter auf False setzen. Sie können dieses Feld auf True setzen, indem Sie die Hinweise im Abschnitt "CA-Zertifikatsvalidierung" befolgen.

Sicherheitsabschnitt​

  • SALT - Optional - Hier kann der SALT gespeichert werden, um die Speicherung verschlüsselter Passwörter zu ermöglichen.

Hinweis: Wenn Sie Bedenken haben, Passwörter im Klartext in der Datei config.ini zu speichern, können Sie die folgende Prozedur nutzen, um sie verschlüsselt zu speichern. Wenn die Option SALT in der Datei config.ini deklariert ist, fragt das Programm beim Start nach dem Master-Passwort, um die Passwortfelder in der Konfiguration zu entschlüsseln.

So verschlüsseln Sie das Passwort in der config.ini (optional)​

Sie können das Programm create_encrypted_password.py ausführen, wenn Sie das Passwort verschlüsselt in der Konfigurationsdatei speichern möchten.

python create_encrypted_password.py

Es wird nach einem Master-Passwort gefragt (wird später für den Integrator benötigt) und verschlüsselt die PVE- und LXCA-Passwörter. Anschließend werden die Zeilen ausgegeben, die in die Konfigurationsdatei eingefügt werden müssen (Beispiel):

Add the following three lines to your config.ini:

LXCA_PASS = gAAAAABonuj0JNenRko_DS-HTcZkFfoho_ZID6RcwLTFPNn7A2QYsNgtE3-wjzCE8R0_bpVquZLDGpe9ARpJdZ7tSEWoNXTOQg==
PROXMOX_PASS = gAAAAABonuj0aXh5IYUhClWjBaOBh9HgcvtmwyB9rYzlvnSO-NAS51rNQXaBH0CjlgvF4lkwpPsXSIi2SLpozKmueTtpV_uQJQ==
SALT = E3T1B/Ty6nk3RJq7dQq8Pg==

CA-Zertifikatsvalidierung​

Wenn Sie in Ihrer Umgebung eigene Zertifikate verwenden, können Sie wählen, ob die Zertifikate der Proxmox-Hosts und/oder der LXCA-Instanz zur Einhaltung der Sicherheitsrichtlinien überprüft werden sollen.

Dazu müssen Sie im gleichen Verzeichnis wie das Tool eine Datei namens custom_cacert.pem anlegen, in der Sie die CA-Zertifikate Ihrer Umgebung im pem-Format manuell speichern (siehe Beispiel unten):

-----BEGIN CERTIFICATE-----
MIIFzTCCA7WgAwIBAgIUdmBnkIBixu29Fv7wAI4de2sxPQ0wDQYJKoZIhvcNAQEL
BQAwdjEkMCIGA1UEAwwbUHJveG1veCBWaXJ0dWFsIEVudmlyb25tZW50MS0wKwYD
VQQLDCQzNzI4MzdlNS1jMjvkLTQwZjgtODA2NC02YWY2OTFlNWMxODMxHzAdBgNV
BAoMFlBWRSBDbHVzdGVyIE1hbmFnZXIgQ0EwHhcNMjUwMzE0MTE0NDE5WhcNMzUw
MzEyMTE0NDE5WjB2MSQwIgYDVQQDDbtQcm94bW94IFZpcnR1YWwgRW52aXJvbm1l
bnQxLTArBgNVBAsMJDM3MjgzN2U1LWMyNWQtNDBmOC04MDY0LTZhZjY5MWU1YzE4
MzEfMB0GA1UECgwWUFZFIENsdXN0ZXIgTWFuYWdlciBDQTCCAiIwDQYJKoZIhvcN
aQEBBQADggIPADCCAgoCggIBANR+cPxIkIEBNx9YCAaaL2+fOUWy/fBaeBMCdD+D
7F/Bi+Mcpn2p3+gVuhyCaTcYZnP0aewHUI4xCL8YHFwqWv6J7ryMV++i/0Rbkzny
EZvKISNxTuZ/9ZioP1S9K3Se3ZVZI23xyLQ/Wu2mqPo5d3QLttR5/ndBLVmUtMZe
pz3Jlj2kQxvQrbG4SdHBs4GpqLbDoqktkFK+nJjGuibNVovZFKufv+7ySoKhbF9l
I21A4Ta+QqlhG+TD6r4c61yGKgX/IozrsvIOaOBwLHX81gEOwh5BZ6G++OKblQu+
nb7ZEyZYUQ4sT6I+HykcyA9amil4Six5qnOohNJwtd9QCZZiFWQhOS+cI627L0EU
uQ7DJ60McDyrMqgNWZOnBKLqoDSi2M1ZkXI1ACa/IoUeutITlMnZucLIdTM1VPhV
qQIJDqb2TaKQnjxnuqSXaA0DVwcSnX+VZgTUbzbV/+tlPENnQ3KcarqwvkUXlQB0
uagYmCURylUJXOT4r+8oUJDak4zwPjOQLH+PF3OdGScj4FIByNL+1G08UmhHzixi
a76J8eF0NOx65tBJDjie3McU7vrDJ8DrIbcM/LOvFa9PCrGe9wNmHqqOtoUuxdaR
b6co1YE34OF2cdyeaEVRVYtKFFp/Oa0ZA10eBEOFxzv4KTFi4/Y+nuMjKMYY0Kmo
XUxJAgMBAAGjUzBRMB0GA1UdDgQWBBQxTKcz/j1/m505HaGyrZtGqiDaFDAfBgNV
HSMEGDAWgBQxTKcz/j1/m505HaGyrZtGqiDaFDAPBgNVHRMBAf8EBTADAQH/MA0G
CSqGSIb3DQEBCwUAA4ICAQCcsA4imt0cpgYNbBvufvBpObGKkiSoimd6p1fpJhjX
PMDdtn6dVw2zbAmqDmBqdRTenK9J30OWVoYmpnh5H+p8wM1uT5js248DmhtXTeUd
xHHVyz9c2ooZT/7EGqWAa/VRpKAeN99uzEmLZzxxb0Sg7wvN8Q7KbIiJdtckqo09
sZqDXIKFnqRL0Gyys9ZvsGZFpZoUipA+IbJVQlArKjWFNZkPhT14xMPdoZAMX4Zi
45srzk4Z9sJjKkYaA5eFsirbPOi9N5KmrqmD2c1Jb4p3ScdzJO7ay5PmkYdeIq3K
vN9MPAuMSDWmQasqB/oO1gRmdcWNU2ABbsrEeALMPhe/J82meUQd7MorVC87OUJ6
mp2b97TTBDqsqsqrygKmWb2YFXFS/uR5ZaYEXDjxe9LXCRODRJAlGF882PS20YoV
iUBGWd361+nkLkJ3GaT8l/PkpHLg5mXU6UmiPEw9O+mzYFNAhYzvzfIP4G4afYYo
T+/8KBbqWVuW6ecv/vqLQIyc0ucOgnH9vhwliGTyMug/GhaTjXFtRdjdu0W7irmM
CgkLeEpvWN1xgNTBILIqva6dc31V36hOVgSjRcIr4r0sCe2I3J6ixw7ShHXxMYAi
od9Lz4mJrL4k1SovZEonEr6HmXYlsdV2R6/ZaoCKYN2F1zZ4IzGuSRU1iUiz5iCN
WQ==
-----END CERTIFICATE-----

Hinweis: Ab Python 3.13 werden einige strikte Standards in der SSL-Verwaltung umgesetzt. Dadurch verhält sich die zugrundeliegende OpenSSL-Implementierung konformer zu RFC 5280, was zu einer kleinen Inkompatibilität mit älteren X.509-Zertifikaten führen kann. Der SSL-Kontext verwendet jetzt VERIFY_X509_PARTIAL_CHAIN und VERIFY_X509_STRICT als Standard-Verify-Flags. Das bedeutet, dass das CA-Zertifikat alle strikten Regeln erfüllen muss (z.B. X509v3 Key Usage, X509v3 Basic Constraints = Critical, etc).

Verwendung​

python lxca_proxmox_integrator.py

Ohne übergebene Parameter erhalten Sie diese Hilfe zur Verwendung:

usage: lxca_proxmox_integrator.py [-h] (-d | -x) [-v] [-c] [-V]

LXCA Proxmox integrator command line parameters

options:
  -h, --help      show this help message and exit
  -d, --dry-run   Simulate the upgrade
  -x, --execute   Perform the upgrade
  -v, --verbose   Add verbosity to the ouput
  -c, --clearlog  Move current log to backup and start a clean log file
  -V, --version   Show program version

Sie MÜSSEN entweder den Parameter -d | --dry-run oder -x | --execute angeben.

Die Dry-Run-Parameter (-d | --dry-run) ermöglichen es, den vollständigen Ablauf zu simulieren, ohne Aktionen am Cluster durchzuführen. Während des Dry-Runs wird eine Simulation durchgeführt, die alle Erkenntnisse in der Umgebung auflistet (am besten mit der Option -v verwenden).

Es wird dringend empfohlen, immer zuerst einen Dry-Run (-d | --dry-run) durchzuführen, bevor Sie mit dem Parameter -x | --execute die Firmware-Updates tatsächlich ausführen.

Der Parameter -v | --verbose erhöht die Ausführlichkeit der Ausgabe (sowohl Konsole als auch Log).

Der Parameter -c | --clearlog erstellt ein Backup des aktuellen Logs und initialisiert eine neue, leere Logdatei.

Das Tool führt (Hauptablauf):

  • Fragt nach dem Master-Passwort, falls erforderlich (optional)
  • Verbindet sich mit Ihrer LXCA-Instanz.
  • Prüft Ihre ThinkSystem-Knoten auf verfügbare Updates.
  • Orchestriert Firmware-Updates im Cluster/auf den Knoten.

Hinweis: Aktuell wird die Online-Migration von CT-Containern nicht unterstützt; daher erfolgt die Migration durch Herunterfahren des Containers und sofortiges Neustarten auf dem Zielhost.

Protokollierung​

Alle Vorgänge werden sowohl auf der Konsole als auch in einer Logdatei (lxca_proxmox_integrator.log) protokolliert. Überprüfen Sie die Logs, um den Erfolg der Updates zu verifizieren und eventuelle Probleme zu beheben.

Haftungsausschlüsse​

  • Als Best Practice empfehlen wir dringend, Firmware- und Treiber-Updates immer zuerst in einer Staging- oder Nicht-Produktivumgebung zu testen, bevor sie im gesamten Cluster ausgerollt werden. Sie können auch die DRY_RUN-Ausführung nutzen, um eine Simulation der anderen Vorgänge durchzuführen, ohne Firmware-Updates anzuwenden.

  • Bei Fehlern während der Prozedur wird das Tool gestoppt, sodass der IT-Administrator das Problem prüfen und beheben kann. Die einzige Ausnahme betrifft das "Einschalten" der VMs/CTs, das im Log angezeigt wird, aber die Prozedur wird fortgesetzt. Eine manuelle Wiederherstellung kann erforderlich sein, um den korrekten Zustand wiederherzustellen.

  • Sofern nicht gesetzlich vorgeschrieben oder schriftlich vereinbart, wird die unter der Lizenz bereitgestellte Software "AS IS" bereitgestellt, ohne jegliche Gewährleistung oder Bedingungen, weder ausdrücklich noch stillschweigend. Siehe die Lizenz für die spezifischen Regelungen zu Rechten und Einschränkungen unter der Lizenz.

Lizenz​

Lizenziert unter der Apache License, Version 2.0 (die "Lizenz"): http://www.apache.org/licenses/LICENSE-2.0