Add documentation for Nutanix cluster management, Synology NAS updates, Windows 11 operator setup, decision support system installation, and Totem Manager configuration
- Created guides for adding/removing nodes in Nutanix clusters and installing Nutanix servers. - Documented the process for updating Nutanix infrastructure and Synology NAS. - Added instructions for preparing a Windows 11 operator workstation, including Sysprep and network configuration. - Established steps for setting up the decision support system and configuring Totem Manager.
This commit is contained in:
Maxime BOURIEAU
@@ -0,0 +1,51 @@
|
||||
# Exporter une machine virtuelle depuis un hyperviseur ESXi
|
||||
|
||||
Deux méthodes sont décrites ci-dessous : l'export avec le script `export_vm_esxi.sh` ou l'export manuel depuis l'interface Web ESXi.
|
||||
|
||||
## 1. Exporter avec le script CLI
|
||||
|
||||
Le script se trouve dans le dépôt Git `F5CloudNative/tools/esxi/export_vm_esxi.sh`. Le récupérer sur la machine depuis laquelle l'export sera exécuté.
|
||||
|
||||
### 1.1 Paramètres
|
||||
|
||||
| Option | Description | Obligatoire |
|
||||
| --- | --- | --- |
|
||||
| `-r` ou `--remote_esxi` | Adresse IP de l'hyperviseur ESXi source | Oui |
|
||||
| `-u` ou `--user` | Compte autorisé à accéder à ESXi | Oui |
|
||||
| `-p` ou `--password` | Mot de passe du compte ESXi | Oui |
|
||||
| `-v` ou `--version` | Version matérielle de la VM à exporter, par exemple `1-19-3` | Oui |
|
||||
| `-d` ou `--export_dir` | Répertoire local de destination | Oui |
|
||||
| `-sv` ou `--src_vm` | Nom de la VM source sur ESXi | Oui |
|
||||
| `-dv` ou `--dst_vm` | Nom de la VM à donner aux fichiers exportés | Oui |
|
||||
| `-h` ou `--help` | Affiche l'aide | Non |
|
||||
|
||||
Vérifier les noms d'options disponibles avec `--help` si la version du script diffère.
|
||||
|
||||
### 1.2 Lancer l'export
|
||||
|
||||
Exécuter le script en remplaçant les valeurs d'exemple par celles de l'environnement :
|
||||
|
||||
```bash
|
||||
./export_vm_esxi.sh \
|
||||
-r '<IP_ESXI>' \\
|
||||
-u '<UTILISATEUR_ESXI>' \
|
||||
-p '<MOT_DE_PASSE>' \
|
||||
-v '<VERSION_VM>' \\
|
||||
-d '<REPERTOIRE_DESTINATION>' \\
|
||||
-sv '<NOM_VM_SOURCE>' \
|
||||
-dv '<NOM_VM_EXPORT>'
|
||||
```
|
||||
|
||||
Récupérer les identifiants dans RDM. Ne pas inscrire un mot de passe réel dans cette procédure ni dans un historique de commandes partagé. Si le script ou l'environnement propose un mode de saisie sécurisé, le privilégier.
|
||||
|
||||
Le script crée un répertoire de destination à partir du nom de VM choisi et de sa version, puis exporte le paquet OVF. L'opération peut prendre plusieurs minutes selon la taille de la VM et le débit réseau. Attendre la fin du processus.
|
||||
|
||||
L'export est terminé lorsque le script indique une réussite, par exemple `VM successfully export` et `Finish`. Le script source retire également le fichier NVRAM exporté et son entrée dans le fichier OVF.
|
||||
|
||||
## 2. Exporter manuellement depuis l'interface ESXi
|
||||
|
||||
1. Vérifier que la VM à exporter est arrêtée. L'option d'export n'est pas disponible si elle est en fonctionnement.
|
||||
2. Dans l'interface ESXi, faire un clic droit sur la VM et sélectionner **Exporter**.
|
||||
3. Télécharger un par un les fichiers proposés par l'hyperviseur.
|
||||
4. Enregistrer tous les fichiers de la VM dans le même répertoire local et conserver leurs noms afin que le fichier OVF puisse retrouver les disques associés.
|
||||
5. Attendre la fin de chaque téléchargement et vérifier que tous les fichiers proposés ont été récupérés.
|
||||
@@ -0,0 +1,69 @@
|
||||
# Importer une machine virtuelle sur un hyperviseur ESXi
|
||||
|
||||
Deux méthodes sont décrites ci-dessous : importer la VM avec le script `import_vm_esxi.sh` ou utiliser l'assistant de déploiement OVF dans l'interface ESXi.
|
||||
|
||||
## 1. Préparer les fichiers et la destination
|
||||
|
||||
Récupérer le dossier d'export de la VM depuis le partage Cloud indiqué pour l'intervention. Le paquet doit contenir le fichier OVF et les fichiers de disque associés, notamment les VMDK.
|
||||
|
||||
Avant l'import, confirmer :
|
||||
|
||||
- l'hôte ESXi cible et les identifiants d'accès, disponibles dans RDM;
|
||||
- le nom du datastore cible et l'espace disponible;
|
||||
- le nom du réseau/port group ESXi correspondant à l'environnement cible;
|
||||
- le nom à donner à la VM afin d'éviter un conflit avec une VM existante.
|
||||
|
||||
Le dossier source de la procédure mentionne `VM-K8S-READY` à la racine du script comme exemple de paquet à importer. Remplacer cet exemple par les fichiers de la VM concernée.
|
||||
|
||||
## 2. Importer avec le script CLI
|
||||
|
||||
Le script est indiqué dans le dépôt comme `F5_CloudNative/tools/esxi/import_vm_esxi.sh`. Vérifier le chemin du dépôt et les options reconnues par la version utilisée avec `--help`; la procédure d'export cite un dépôt nommé `F5CloudNative` sans soulignement.
|
||||
|
||||
### 2.1 Paramètres
|
||||
|
||||
| Option | Description | Obligatoire |
|
||||
| --- | --- | --- |
|
||||
| `-r` ou `--remote_esxi` | Adresse IP de l'hyperviseur ESXi cible | Oui |
|
||||
| `-u` ou `--user` | Compte autorisé à accéder à ESXi | Oui |
|
||||
| `-p` ou `--password` | Mot de passe du compte ESXi | Oui |
|
||||
| `-v` ou `--version` | Version matérielle de la VM, par exemple `1-19-3` | Oui |
|
||||
| `-f` ou `--file` | Chemin local du fichier ou paquet OVF à importer | Oui |
|
||||
| `-n` ou `--name` | Nom de la VM sur ESXi | Oui |
|
||||
| `-net` ou `--network` | Nom du réseau/port group ESXi | Oui |
|
||||
| `-d` ou `--datastore` | Nom du datastore ESXi | Oui |
|
||||
| `-h` ou `--help` | Affiche l'aide | Non |
|
||||
|
||||
### 2.2 Lancer l'import
|
||||
|
||||
Adapter les valeurs au paquet et à l'infrastructure cible :
|
||||
|
||||
```bash
|
||||
./import_vm_esxi.sh \\
|
||||
-r '<IP_ESXI>' \\
|
||||
-u '<UTILISATEUR_ESXI>' \\
|
||||
-p '<MOT_DE_PASSE>' \\
|
||||
-v '<VERSION_VM>' \\
|
||||
-f '<CHEMIN_DU_FICHIER_OVF>' \\
|
||||
-n '<NOM_VM_CIBLE>' \\
|
||||
-net '<RESEAU_ESXI>' \\
|
||||
-d '<DATASTORE_ESXI>'
|
||||
```
|
||||
|
||||
Un exemple de réseau fourni dans la procédure source est `Systel PREPROD Network`; utiliser le port group réellement prévu pour l'environnement cible.
|
||||
|
||||
La procédure contient deux formes différentes pour l'option `-f` : un exemple donne le répertoire d'export, tandis que la commande détaillée donne le chemin du fichier `.ovf`. Vérifier l'aide du script ou sa documentation et utiliser le format attendu par cette version. L'exemple détaillé ci-dessus indique le fichier OVF.
|
||||
|
||||
Récupérer les identifiants dans RDM. Ne pas inscrire de mot de passe réel dans la procédure ni dans un historique de commandes partagé. Si le script ou l'environnement permet une saisie sécurisée, la privilégier.
|
||||
|
||||
Attendre la fin de l'import, qui peut prendre plusieurs minutes selon la taille de la VM et le débit réseau. L'opération est terminée lorsque le script signale la réussite de l'import.
|
||||
|
||||
## 3. Importer manuellement depuis l'interface ESXi
|
||||
|
||||
1. Dans l'interface ESXi, cliquer sur **Créer/Enregistrer une machine virtuelle**.
|
||||
2. Sélectionner **Déployer une machine virtuelle à partir d'un fichier OVF**.
|
||||
3. Sélectionner le fichier OVF ainsi que tous les fichiers VMDK associés à la VM.
|
||||
4. Sélectionner le stockage/datastore où la VM sera importée et stockée.
|
||||
5. Configurer le mappage réseau, le type de provisionnement du disque et le démarrage automatique de la VM au terme du déploiement.
|
||||
6. Vérifier le récapitulatif des options, puis valider l'importation.
|
||||
|
||||
Après le déploiement, vérifier que la VM apparaît dans l'inventaire, que son réseau est correctement mappé et qu'elle démarre comme prévu avant sa remise en service.
|
||||
@@ -0,0 +1,180 @@
|
||||
# Mettre à jour un serveur VMware ESXi
|
||||
|
||||
## 1. Prérequis et ordre des opérations
|
||||
|
||||
> **Interruption de service :** cette opération nécessite l'arrêt de toutes les machines virtuelles hébergées sur le serveur ESXi.
|
||||
|
||||
> **Ordre requis :** mettre à jour le firmware avant l'hyperviseur. Si un vCenter est présent, le mettre à jour avant ESXi.
|
||||
|
||||
Cette procédure décrit une mise à jour vers VMware ESXi 8.0 Update 3. La source indique que cette mise à jour est possible depuis les versions 6.7 et 7.0. Vérifier la compatibilité matérielle, le chemin de mise à niveau et la version recommandée auprès des experts Infrastructure avant de commencer.
|
||||
|
||||
Les mises à jour firmware et iLO des serveurs HPE sont fournies dans les paquets **SPP (Service Pack for ProLiant)**. Le paquet ESXi est spécifique aux serveurs HPE ProLiant. Demander aux experts Infrastructure les versions et paquets recommandés pour le serveur concerné.
|
||||
|
||||
Les paquets sont disponibles dans les répertoires suivants :
|
||||
|
||||
```text
|
||||
\\cloud\Produits\Produits_tiers\HPE\Service Pack for Proliant
|
||||
\\cloud\Produits\Produits_tiers\VMWare\VMware_ESXi
|
||||
```
|
||||
|
||||
Avant l'intervention, confirmer le plan d'arrêt et de redémarrage des VM avec les équipes responsables. Prévoir un accès à iLO et à l'interface ESXi ou vCenter.
|
||||
|
||||
## 2. Arrêter les machines virtuelles
|
||||
|
||||
L'ordre et les modalités d'arrêt des services applicatifs doivent être confirmés avec leurs responsables.
|
||||
|
||||
### 2.1 SQL Witness
|
||||
|
||||
Consulter les experts SQL avant d'arrêter la VM SQL Witness.
|
||||
|
||||
### 2.2 Nœud SWARM
|
||||
|
||||
Confirmer le nom exact du nœud avant d'exécuter les commandes : le titre de la procédure source mentionne `SWARM-MANAGER-03`, tandis que sa commande utilise `SWARM-MANAGER-LIVE-03`.
|
||||
|
||||
Sur un manager Swarm, drainer le nœud concerné :
|
||||
|
||||
```bash
|
||||
docker node update --availability drain SWARM-MANAGER-LIVE-03
|
||||
docker node ls
|
||||
docker ps
|
||||
```
|
||||
|
||||
Vérifier avec `docker node ls` que le nœud est drainé et qu'aucune activité ne subsiste avant l'arrêt. Si l'arrêt de la machine est confirmé :
|
||||
|
||||
```bash
|
||||
shutdown -h now
|
||||
```
|
||||
|
||||
Après le redémarrage, réactiver le nœud avec son nom exact :
|
||||
|
||||
```bash
|
||||
docker node update --availability active SWARM-MANAGER-LIVE-03
|
||||
```
|
||||
|
||||
En cas de doute, contacter les DevOps dans Teams, canal `COM-SUPPORTS > DDP - DevOps`.
|
||||
|
||||
### 2.3 Contrôleur HYCU
|
||||
|
||||
1. Se connecter à l'interface HYCU et ouvrir **Jobs**.
|
||||
2. Vérifier qu'aucune sauvegarde n'est en cours.
|
||||
3. Dans les paramètres, ouvrir **Power Options** et cliquer sur **Suspend All** pour empêcher le lancement de nouvelles sauvegardes pendant l'arrêt et le redémarrage.
|
||||
4. Arrêter la VM HYCU depuis ESXi ou vCenter.
|
||||
5. Après le redémarrage, retourner dans **Power Options** et retirer la suspension.
|
||||
|
||||
### 2.4 vCenter
|
||||
|
||||
Si un vCenter est présent, appliquer sa mise à jour avant celle de l'hôte ESXi. Suivre la procédure [Mise à jour VMware vCenter 7 vers 8](https://tfs2k18.systel-sa.com/tfs/Systel/Etudes/_wiki/wikis/Etudes.wiki/2635/MAJ-VMWare-vCenter-7-vers-8).
|
||||
|
||||
Pour l'arrêt du vCenter avant la mise à jour de l'hôte :
|
||||
|
||||
1. Éteindre toutes les autres VM hébergées sur l'hôte.
|
||||
2. Se connecter à **vCenter Server Management** sur `https://IP_vCenter:5480` avec le compte `root`.
|
||||
3. Dans **Actions**, sélectionner **Arrêt** et confirmer si une demande apparaît.
|
||||
|
||||
## 3. Mettre l'hôte ESXi en maintenance
|
||||
|
||||
1. Ouvrir l'interface Web de l'hyperviseur ESXi.
|
||||
2. Vérifier que toutes les VM de l'hôte sont arrêtées.
|
||||
3. Dans le menu de l'hôte, sélectionner **Entrer en mode de maintenance**.
|
||||
4. Confirmer si une fenêtre de confirmation apparaît.
|
||||
5. Vérifier sur la page d'accueil de l'ESXi que l'hôte est bien en mode maintenance.
|
||||
|
||||
## 4. Mettre à jour le firmware HPE avec le SPP
|
||||
|
||||
1. Ouvrir l'interface iLO du serveur et lancer la console distante.
|
||||
2. Depuis la console, monter ou importer le fichier ISO SPP, puis confirmer l'opération.
|
||||
3. Redémarrer le serveur.
|
||||
4. Au démarrage, appuyer sur `F11` pour ouvrir le menu **One-Time Boot Menu**.
|
||||
5. Sélectionner l'entrée correspondant au média SPP monté. Vérifier son libellé dans le menu avant de la choisir.
|
||||
6. Sélectionner **Automatic** pour lancer la mise à jour automatisée.
|
||||
|
||||
La procédure source estime la durée de l'opération à une à deux heures. Ne pas interrompre le serveur. La console iLO peut redémarrer pendant l'installation; se reconnecter si nécessaire pour suivre la suite du processus. Si iLO affiche un message pendant l'installation, ne pas intervenir sans confirmation des experts Infrastructure : les redémarrages peuvent faire partie du processus automatisé.
|
||||
|
||||
Si la console iLO ne se reconnecte pas correctement, vider le cache du navigateur puis réessayer.
|
||||
|
||||
## 5. Mettre à jour ESXi
|
||||
|
||||
Après la mise à jour du firmware, vérifier que l'hôte est démarré et toujours en mode maintenance.
|
||||
|
||||
### 5.1 Déposer le paquet sur un datastore
|
||||
|
||||
1. Dans l'interface ESXi, ouvrir **Stockage > Parcourir les banques de données**.
|
||||
2. Ouvrir le répertoire de mise à jour souhaité ou en créer un.
|
||||
3. Utiliser **Télécharger** pour déposer le paquet ESXi `.zip` sur le datastore.
|
||||
|
||||
### 5.2 Activer SSH et relever le profil
|
||||
|
||||
Activer SSH dans **Hôte > Services > Activer Secure Shell (SSH)**, puis se connecter à l'hôte en SSH.
|
||||
|
||||
Vérifier le mode maintenance :
|
||||
|
||||
```bash
|
||||
esxcli system maintenanceMode get
|
||||
```
|
||||
|
||||
Lister les profils disponibles dans le paquet en remplaçant le chemin par celui du fichier `.zip` :
|
||||
|
||||
```bash
|
||||
esxcli software sources profile list -d <chemin-complet-vers-le-fichier.zip>
|
||||
```
|
||||
|
||||
Exemple :
|
||||
|
||||
```bash
|
||||
esxcli software sources profile list -d /vmfs/volumes/datastore/MAJ/Update.zip
|
||||
```
|
||||
|
||||
Noter le nom exact du profil souhaité pour la commande suivante.
|
||||
|
||||
### 5.3 Installer le profil et redémarrer
|
||||
|
||||
Lancer la mise à jour en remplaçant le chemin et le profil par les valeurs relevées :
|
||||
|
||||
```bash
|
||||
esxcli software profile update -d <chemin-complet-vers-le-fichier.zip> -p <nom-du-profil>
|
||||
```
|
||||
|
||||
Exemple fourni dans la procédure source :
|
||||
|
||||
```bash
|
||||
esxcli software profile update -d /vmfs/volumes/datastore/MAJ/Update.zip -p HPE-Custom-AddOn_803.0.0.12.1.0-11
|
||||
```
|
||||
|
||||
Après la fin de la commande, redémarrer l'hôte :
|
||||
|
||||
```bash
|
||||
esxcli system shutdown reboot --reason "maj vers 8.0U3"
|
||||
```
|
||||
|
||||
Après le redémarrage, vérifier la version ESXi et l'état de l'hôte, puis quitter le mode maintenance si les contrôles sont concluants.
|
||||
|
||||
## 6. Vérifier ou appliquer la licence ESXi
|
||||
|
||||
Ouvrir **Hôte > Gérer > Attribution de licence** et vérifier la licence installée.
|
||||
|
||||
Une mise à jour de version majeure, par exemple de 7.0 à 8.0, nécessite une licence compatible avec la version installée. Si une nouvelle licence est nécessaire :
|
||||
|
||||
1. Se connecter à [Broadcom Support](https://support.broadcom.com/) avec le compte de licence dont les informations sont conservées dans `RDM > COMMUN`.
|
||||
2. Ouvrir **Entitlements** et développer les détails jusqu'à la section **License** pour ESXi.
|
||||
3. Relever la clé au format `XXXXX-XXXXX-XXXXX-XXXXX-XXXXX`.
|
||||
4. Dans ESXi, ouvrir **Hôte > Gérer > Attribution de licence**, choisir **Attribuer une licence**, saisir la clé et cliquer sur **Vérifier la licence**.
|
||||
5. Après validation, cliquer sur **Attribuer une licence** et vérifier que l'attribution est effective.
|
||||
|
||||
Ne pas inscrire la clé de licence dans cette procédure.
|
||||
|
||||
## 7. Mettre à jour VMware Tools
|
||||
|
||||
> La mise à jour de VMware Tools peut nécessiter le redémarrage de la VM. Prévoir l'interruption avec les responsables applicatifs.
|
||||
|
||||
Après la mise à jour de l'hôte, vérifier les VM et mettre à jour VMware Tools lorsqu'une version plus récente est disponible :
|
||||
|
||||
1. Sélectionner la VM dans ESXi ou vCenter.
|
||||
2. Ouvrir **Actions > SE invité > Mettre à niveau VMware Tools**.
|
||||
3. Attendre la fin de l'installation et effectuer le redémarrage requis.
|
||||
4. Vérifier dans la description de la VM que VMware Tools est conforme.
|
||||
|
||||
Répéter pour chaque VM concernée.
|
||||
|
||||
## 8. Remise en service
|
||||
|
||||
Vérifier le bon fonctionnement de l'hôte et des VM, puis confirmer que les services applicatifs sont opérationnels. Réactiver les tâches HYCU suspendues et réactiver le nœud Swarm après validation des équipes concernées.
|
||||
@@ -0,0 +1,22 @@
|
||||
# Ajouter ou retirer des nœuds dans un cluster Nutanix
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
L'ajout et le retrait de nœuds modifient la capacité et la configuration du cluster. Avant toute intervention, confirmer le cluster cible, la compatibilité des nœuds et le plan d'adressage avec les équipes responsables. Vérifier également l'état du cluster et les prérequis de la version de Prism utilisée.
|
||||
|
||||
## 2. Ajouter des nœuds
|
||||
|
||||
Dans Prism Element, ouvrir **Hardware > Expand Cluster**.
|
||||
|
||||
1. Sélectionner les nœuds à ajouter.
|
||||
2. Renseigner les adresses IPv4 prévues pour chaque nœud :
|
||||
- CVM;
|
||||
- hyperviseur (host);
|
||||
- IPMI.
|
||||
3. Définir **Node Type** sur `HCI`.
|
||||
|
||||
**Important :** la procédure source ne décrit pas les écrans suivants ni les validations finales de l'assistant. Avant de lancer l'expansion, suivre la procédure approuvée pour la version de Nutanix/Prism du cluster et vérifier les valeurs saisies. Ne pas confirmer l'opération en se basant uniquement sur les indications de cette page.
|
||||
|
||||
## 3. Retirer des nœuds
|
||||
|
||||
La procédure source ne fournit aucune étape textuelle de retrait. Ne pas lancer le retrait à partir de ce seul document : consulter la procédure Nutanix validée pour la version du cluster et faire confirmer le plan d'intervention par les équipes responsables avant toute action.
|
||||
@@ -0,0 +1,85 @@
|
||||
# Mettre à jour une infrastructure Nutanix
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
Avant l'intervention :
|
||||
|
||||
- Vérifier que les sauvegardes sont saines dans HYCU ou Veeam.
|
||||
- Vérifier que Prism Central et les clusters peuvent joindre les services Nutanix nécessaires. Se référer à la matrice de flux. Si l'environnement n'a pas d'accès, utiliser la méthode **Dark Site Direct Upload** selon la procédure prévue.
|
||||
- Vérifier les versions source et cible ainsi que la matrice de compatibilité Nutanix avec l'équipe Infrastructure.
|
||||
|
||||
Traiter les erreurs de santé avant de commencer. Si un contrôle signale une sévérité `ERROR`, `FAIL` ou `WARNING`, contacter l'équipe Infrastructure et ne poursuivre qu'après résolution ou validation explicite.
|
||||
|
||||
## 2. Mettre à jour Prism Central
|
||||
|
||||
### 2.1 Vérifier l'état de santé
|
||||
|
||||
Se connecter en SSH à Prism Central et lancer :
|
||||
|
||||
```bash
|
||||
ncc health_checks run_all
|
||||
```
|
||||
|
||||
Examiner le résultat et résoudre les alertes bloquantes avec l'équipe Infrastructure avant la mise à jour.
|
||||
|
||||
### 2.2 Lancer la mise à jour
|
||||
|
||||
1. Se connecter à l'interface Prism Central.
|
||||
2. Ouvrir **Admin Center > LCM** (Life Cycle Manager).
|
||||
3. Dans l'onglet **Inventory**, cliquer sur **Perform Inventory** pour actualiser l'inventaire et les mises à jour disponibles.
|
||||
4. Lancer la mise à jour validée pour Prism Central et suivre son avancement dans LCM.
|
||||
|
||||
Prism Central télécharge le paquet depuis Nutanix, effectue les contrôles préalables, puis exécute la mise à jour. La durée estimée par la procédure source est d'une à deux heures. Prism Central redémarre pendant l'opération; une interruption d'accès de cinq à dix minutes est à prévoir.
|
||||
|
||||
Lorsque l'accès revient, retourner dans **Admin Center > LCM** et vérifier l'état de la mise à jour.
|
||||
|
||||
## 3. Préparer chaque cluster (Prism Element)
|
||||
|
||||
Répéter les vérifications et la mise à jour de cette section pour chaque cluster du client.
|
||||
|
||||
### 3.1 Vérifier l'état de santé
|
||||
|
||||
Se connecter en SSH à une CVM du cluster et lancer :
|
||||
|
||||
```bash
|
||||
ncc health_checks run_all
|
||||
```
|
||||
|
||||
Résoudre les alertes `ERROR`, `FAIL` et `WARNING` avec l'équipe Infrastructure avant de poursuivre.
|
||||
|
||||
### 3.2 Vérifier les VM en mode agent
|
||||
|
||||
Une VM en mode agent est liée à l'hôte sur lequel elle s'exécute. Elle ne migre pas automatiquement si cet hôte redémarre pendant la mise à jour.
|
||||
|
||||
Rechercher les VM en mode agent :
|
||||
|
||||
```bash
|
||||
acli vm.get \* | grep -B10 "agent_vm: True" | egrep "agent|\{"
|
||||
```
|
||||
|
||||
Si la commande ne retourne aucun résultat, aucune VM en mode agent n'a été détectée.
|
||||
|
||||
Si une VM apparaît :
|
||||
|
||||
1. Ouvrir Prism Element à l'adresse IP du cluster.
|
||||
2. Dans le menu principal, ouvrir **VM**, puis l'onglet **Table**.
|
||||
3. Sélectionner la VM concernée et ouvrir **Update** (double-clic ou clic droit).
|
||||
4. Désactiver **Use this VM as an agent VM**.
|
||||
5. Cliquer sur **Save** pour enregistrer la modification.
|
||||
|
||||
## 4. Mettre à jour chaque cluster
|
||||
|
||||
1. Ouvrir Prism Element à l'adresse IP du cluster. L'entrée correspondante est enregistrée dans RDM sous `NTNX-CLUSTERXX`.
|
||||
2. Ouvrir **LCM**.
|
||||
3. Dans l'onglet **Inventory**, cliquer sur **Perform Inventory** afin d'actualiser l'inventaire et les mises à jour disponibles.
|
||||
4. Appliquer les mises à jour dans l'ordre suivant :
|
||||
1. **NCC**. Une fois la mise à jour terminée, relancer le contrôle de santé NCC en CLI et traiter les alertes avant de continuer.
|
||||
2. **Foundation / Foundation Platforms**.
|
||||
3. **AOS**.
|
||||
4. **AHV**.
|
||||
5. **Firmware**.
|
||||
5. Suivre l'état de chaque mise à jour dans LCM et attendre la fin de l'étape en cours avant de lancer la suivante.
|
||||
|
||||
La mise à jour du cluster peut durer plusieurs heures. Nutanix télécharge les paquets, effectue les contrôles préalables, déplace les VM hors du nœud en cours de mise à jour, puis redémarre les composants concernés (serveur, hyperviseur et CVM).
|
||||
|
||||
Si plusieurs clusters sont présents, vérifier que les mêmes versions cibles sont appliquées à chacun d'eux.
|
||||
Reference in New Issue
Block a user