Aller au contenu principal

Lenovo XClarity Integrator pour Proxmox

Lenovo XClarity Integrator pour Proxmox est un outil basé sur Python qui permet d’automatiser les mises à jour du microprogramme pour les environnements Proxmox Cluster fonctionnant sur des serveurs Lenovo ThinkSystem. Il s’intègre à Lenovo XClarity Administrator (LXCA) pour garantir que votre infrastructure reste à jour avec les dernières mises à jour matérielles, minimisant ainsi les interruptions de service et réduisant les interventions manuelles.

Cette solution est conçue pour les administrateurs IT souhaitant simplifier la gestion des mises à jour sur leurs clusters Proxmox.

Fonctionnalités​

  • Intégration transparente avec l’API REST de Lenovo XClarity Administrator.
  • Mise à jour automatique du microprogramme basée sur la politique appliquée via Lenovo XClarity Administrator
  • Opérations de mise à jour tenant compte du cluster pour réduire les interruptions de service.
  • Journalisation et rapport des résultats de mise à jour.
  • Configuration personnalisable via config.ini.

Fonctionnement​

Lorsque vous exécutez le programme, il effectue les étapes suivantes :

  • Charge les paramètres d’exécution depuis le fichier config.ini
  • Demande le mot de passe maître, si les mots de passe sont stockés de manière sécurisée (c’est-à-dire chiffrés)
  • Vérifie que les hôtes sont gérés par LXCA et qu’une politique de conformité du microprogramme leur est associée
  • Vérifie si les hôtes sont conformes à la politique de conformité assignée
    • Si ce n’est pas le cas, évacue séquentiellement les VM et CT de l’hôte, effectue la mise à jour du microprogramme via LXCA, puis replace les VM sur l’hôte mis à jour

Prérequis​

  • Python : 3.x (testé avec Python 3.11 et Python 3.13 (SSL strict))
  • Les bibliothèques Python listées dans requirements.txt
  • Une instance Lenovo XClarity Administrator en fonctionnement avec des identifiants API appropriés
  • Un cluster Proxmox VE ou un nœud Proxmox VE unique fonctionnant sur des serveurs pris en charge par Lenovo XClarity Administrator (testé uniquement sur des serveurs Lenovo ThinkSystem)
  • Une politique de conformité assignée à chaque serveur du cluster
  • Une instance OS pour exécuter cet outil (Linux est recommandé mais cela devrait aussi fonctionner sous Windows). ATTENTION : Il n’est pas supporté/recommandé d’exécuter directement sur les serveurs Proxmox.

Installation​

  1. Décompressez le package sur votre système (de préférence sous Linux)

  2. (Optionnel mais recommandé) Configurez un environnement virtuel Python 2.1. Créez un nouvel environnement virtuel dans le répertoire du projet :

    python -m venv venv

    2.2. Activez l’environnement virtuel :

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

  3. Installez les dépendances :

    pip install -r requirements.txt

  4. Préparez votre fichier de configuration (voir Fichier de configuration ci-dessous).

Fichier de configuration​

  1. Consultez le fichier de configuration exemple config.ini.sample. Ce fichier contient tous les paramètres configurables, notamment :

    • Nom d’hôte ou IP de LXCA
    • Identifiants API LXCA
    • Liste des nœuds du cluster Proxmox

  2. Copiez l’exemple et personnalisez-le :

    cp config.ini.sample config.ini

Modifiez config.ini avec votre éditeur préféré pour déclarer les paramètres spécifiques à votre environnement.

Détail des champs​

Section Proxmox​

  • PROXMOX_USER - Obligatoire - Ce champ contient le nom d’utilisateur autorisé à accéder au cluster Proxmox (chaque nœud du cluster) et à effectuer des actions telles que la migration des VM. Il DOIT s’agir d’un utilisateur Linux car il est également nécessaire pour mettre le nœud en mode maintenance. - Par défaut = root@pam (sans guillemets).

  • PROXMOX_PASS - Obligatoire - Vous devez stocker ici le mot de passe de l’utilisateur déclaré dans le champ PROXMOX_USER. Le mot de passe peut être stocké, sans guillemets, en clair (plus simple, moins sécurisé) ou de manière chiffrée (plus sécurisé). Pour les instructions sur la façon de stocker un mot de passe chiffré dans le fichier de configuration, voir la section "Sécurité" ci-dessous.

  • PROXMOX_VERIFY_SSL - Obligatoire - Si vous souhaitez ignorer la validation du certificat SSL, vous pouvez définir ce champ à False. Généralement, avec des certificats auto-signés, c’est le comportement le plus courant ; si vous utilisez des certificats auto-signés et Python > 3.11, vous DEVEZ définir ce paramètre à False. Vous pouvez définir ce champ à True en suivant les instructions de la section "Validation du certificat CA".

  • CLUSTER_NODES - Obligatoire - Ce champ contient le ou les hôtes pouvant être mis à jour par l’outil. Le champ est un tableau où chaque élément est un objet de type JSON décrivant trois paramètres pour l’hôte : -- xcc = l’adresse IP du XCC de l’hôte (DOIT être une adresse IP et non un nom d’hôte) -- pve_ip = l’adresse IP de l’hôte PVE -- pve_host = le nom d’hôte de l’hôte PVE

le format attendu pour l’hôte est : {"xcc":<IP_xcc_node>, "pve_ip": <IP_node> , "pve_host": <NAME_node>}

  • TIMEOUT_HOST - Optionnel - Spécifiez ici le temps maximum (en secondes) à attendre pour que le processus de mise à niveau se termine. - Par défaut = 3600

  • TIMEOUT_VM - Optionnel - Spécifiez ici le temps maximum (en secondes) à attendre pour que les opérations sur les VM (migration, arrêt) se terminent avant de retourner une erreur. - Par défaut = 300 secondes

  • VM_LOCAL_DISKS - Obligatoire - Les valeurs autorisées sont : POWEROFF pour autoriser l’outil à arrêter les VM avec disques locaux (par exemple cdrom, disques VM sur stockage local), FAIL pour arrêter la procédure et permettre une correction manuelle. - Par défaut = FAIL

  • VM_LOCAL_RESOURCES - Obligatoire - Les valeurs autorisées sont : POWEROFF pour autoriser l’outil à arrêter les VM avec ressources locales (par exemple adaptateur PCIe), FAIL pour arrêter la procédure et permettre une correction manuelle. - Par défaut = FAIL

  • VM_LOCAL_DISKS_EXPERT - Expérimental - Optionnel - À utiliser à vos risques et périls !! - EXPERT UNIQUEMENT - Ne pas utiliser sauf si vous savez ce que vous faites. Ce paramètre permet la migration des VM avec disque local (hors cdrom). Il vous appartient de vérifier que toutes les conditions sont remplies à l’exécution (par exemple, mêmes noms de stockage, espace disque suffisant, etc). Les valeurs autorisées sont : True, le programme tentera de migrer la VM avec disque local (hors cdrom local), ou False, le programme suivra l’instruction dans VM_LOCAL_DISKS. Par défaut = False

Session LXCA​

  • LXCA_HOST - Obligatoire - Ce champ contient l’adresse IP (ou le nom d’hôte si résolu par DNS) de l’instance Lenovo XClarity Administrator (LXCA) qui gère les serveurs Proxmox.

  • LXCA_USER - Obligatoire - Ce champ contient le nom d’utilisateur administratif LXCA autorisé à effectuer des mises à jour sur les serveurs gérés par Proxmox.

  • LXCA_PASS - Obligatoire - Indiquez ici le mot de passe de l’utilisateur LXCA spécifié dans le champ LXCA_USER. Le mot de passe peut être stocké, sans guillemets, en clair (plus simple, moins sécurisé) ou de manière chiffrée (plus sécurisé). Pour les instructions sur la façon de stocker un mot de passe chiffré dans le fichier de configuration, voir la section "Sécurité" ci-dessous.

  • LXCA_VERIFY_SSL - Obligatoire - Si vous souhaitez ignorer la validation du certificat SSL, vous pouvez définir ce champ à False. Généralement, avec des certificats auto-signés, c’est le comportement le plus courant ; si vous utilisez des certificats auto-signés et Python > 3.11, vous DEVEZ définir ce paramètre à False. Vous pouvez définir ce champ à True en suivant les instructions de la section "Validation du certificat CA".

Section Sécurité​

  • SALT - Optionnel - Vous pouvez stocker ici le SEL pour permettre le stockage chiffré des mots de passe.

Remarque : si vous craignez de stocker des mots de passe en clair dans le fichier config.ini, vous pouvez utiliser la procédure suivante pour les stocker de façon chiffrée. Si l’option SALT est déclarée dans le fichier config.ini, alors le programme demandera le mot de passe maître pour déchiffrer les champs de mot de passe dans la configuration.

Comment chiffrer le mot de passe dans le config.ini (optionnel)​

Vous pouvez exécuter le programme create_encrypted_password.py si vous souhaitez stocker un mot de passe chiffré dans le fichier de configuration.

python create_encrypted_password.py

Il vous demandera un mot de passe maître (nécessaire plus tard pour exécuter l’intégrateur) et chiffrera les mots de passe PVE et LXCA, en affichant les lignes à insérer dans le fichier de configuration (exemple) :

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==

Validation du certificat CA​

Si vous utilisez des certificats personnalisés dans votre environnement, vous pouvez choisir de vérifier les certificats des hôtes Proxmox et/ou de l’instance LXCA pour être conforme en matière de sécurité.

Pour cela, vous devez créer, dans le même répertoire que l’outil, un fichier nommé custom_cacert.pem où vous devez stocker manuellement le(s) certificat(s) CA de votre environnement au format pem (voir exemple ci-dessous) :

-----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-----

Remarque : À partir de Python 3.13, certains paramètres stricts sont appliqués à la gestion SSL. Cela fait que l’implémentation OpenSSL sous-jacente se comporte davantage comme une implémentation conforme à la RFC 5280, au prix d’une légère incompatibilité avec les anciens certificats X.509. Le contexte SSL utilise désormais VERIFY_X509_PARTIAL_CHAIN et VERIFY_X509_STRICT dans ses options de vérification par défaut. Cela signifie que le certificat CA doit respecter toutes les règles strictes (par exemple, X509v3 Key Usage, X509v3 Basic Constraints = Critical, etc).

Utilisation​

python lxca_proxmox_integrator.py

Sans paramètre passé, vous obtiendrez cette aide d’utilisation :

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

Vous DEVEZ spécifier soit le paramètre -d | --dry-run soit le paramètre -x | --execute.

Les paramètres dry-run (-d | --dry-run) permettent de simuler le cycle complet sans effectuer aucune action sur le cluster. Lors du dry-run, une simulation sera réalisée, listant toutes les découvertes dans l’environnement (à utiliser de préférence avec l’option -v).

Il est fortement recommandé de toujours effectuer un dry-run (-d | --dry-run) avant de lancer avec le paramètre -x | --execute, car cela exécutera les mises à jour du microprogramme.

Le paramètre -v | --verbose ajoute de la verbosité à la sortie (console et log).

Le paramètre -c | --clearlog créera une sauvegarde du log actuel et initialisera un nouveau fichier de log vide.

Le déroulement principal de l’outil :

  • Demande le mot de passe maître si nécessaire (optionnel)
  • Se connecte à votre instance LXCA.
  • Vérifie les nœuds ThinkSystem pour les mises à jour disponibles.
  • Orchestration de la mise à jour du microprogramme sur le cluster/les nœuds.

Remarque : À ce jour, la migration en ligne des conteneurs CT n’est pas supportée ; la migration sera donc effectuée en arrêtant le conteneur puis en le redémarrant immédiatement sur l’hôte cible.

Journalisation​

Toutes les opérations sont enregistrées à la fois sur la console et dans un fichier log (lxca_proxmox_integrator.log). Consultez les logs pour vérifier le succès des mises à jour et diagnostiquer d’éventuels problèmes.

Avertissements​

  • Par mesure de précaution, nous vous recommandons vivement de toujours tester les mises à jour de microprogramme et de pilotes dans un environnement de préproduction ou hors production avant de les déployer sur l’ensemble du cluster. Vous pouvez également utiliser l’exécution DRY_RUN pour simuler les autres opérations sans appliquer les mises à jour du microprogramme.

  • Toute erreur rencontrée pendant la procédure entraînera l’arrêt de l’outil, permettant à l’administrateur IT de vérifier et corriger le problème. La seule exception concerne le "power on" des VM/CT qui sera affiché dans le log mais la procédure continuera. Une intervention manuelle peut être nécessaire pour rétablir l’état correct.

  • Sauf si la loi l’exige ou si cela a été convenu par écrit, le logiciel distribué sous la Licence l’est sur une base "EN L’ÉTAT", SANS GARANTIE NI CONDITION D’AUCUNE SORTE, expresse ou implicite. Voir la Licence pour les autorisations et limitations régissant l’utilisation du logiciel.

Licence​

Sous licence Apache License, Version 2.0 (la "Licence") : http://www.apache.org/licenses/LICENSE-2.0