Énoncé du problème :
Après le remplacement du contrôleur RAID, l'ID NAA du VD a été modifié lors de l'importation de configuration étrangère, ce qui a provoqué l'échec du montage du data store.
Matériel affecté :
UCSB-MRAID12G
UCSC-MRAID12G
Serveurs avec contrôleurs RAID UCSB-MRAID12G :
UCS B200 M4
UCS B200 M5
UCS B480 M5
UCS B420 M4
UCS C220 M4
UCS C240 M4
Microprogramme affecté :
Microprogramme du contrôleur RAID : 24.5.x.x et 24.6.x.x
Exemple n°
***mrsasctlr.24.5.0-0043_6.19.05.0_NA.bin
Le microprogramme du contrôleur 24.5.x.x est visible dans toutes les versions d'UCSM antérieures à la version 3.2.*
Notes de version de 3.1 #
https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/release/notes/CiscoUCSManager-RB-3-1.htmlhttps://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/release/notes/CiscoUCSManager-RB-3-1.html
Système d'exploitation affecté :
VMware ESXi
Motif:
Avec les versions plus anciennes du micrologiciel, s'il existe une incompatibilité de version de l'espace de travail DDF (Device Data Format), le FW du contrôleur n'est pas en mesure de restaurer l'ID NAA à partir de DDF lors de l'importation étrangère.
MR 6.4 a DDF_WORK_SPACE version 1, tandis que MR 6.10 a DDF_WORK_SPACE version 3. Des versions ultérieures de FW post-MR 6.4, des corrections ont été apportées pour permettre au FW contrôleur de restaurer NAA IDD à partir de DDF même si une non-correspondance d'espace de travail DDF est détectée. L'ID NAA ne peut pas être analysé correctement lorsque le microprogramme du contrôleur de remplacement est ancien(Exemple : 24.5.x et 24.6.x). Cependant, la version 24.12.x peut analyser correctement l'ID NAA.
Avant remplacement :
Serveur 2/2 : Nom du produit équipé : Serveur lame à 2 connecteurs Cisco UCS B200 M5 PID équipé : UCSB-B200-M5 VID équipé : V06 Série équipée (SN) : FCH222973K5 État du logement : Équipé Nom du produit reconnu : Serveur lame à 2 connecteurs Cisco UCS B200 M5 PID reconnu : UCSB-B200-M5 VID reconnu : V06 Série (SN) reconnue : FCH222973K5 Mémoire reconnue (Mo) : 524288 Mémoire effective reconnue (Mo) : 524288 Coeurs reconnus : 28 Adaptateurs reconnus : 1 Lecteur virtuel 0 : type : RAID 1 mis en miroir Taille du bloc : 512 Blocs : 1560545280 Opérabilité : Opérable Présence : Équipé Taille : 761985 Cycle de vie : Alloué État du lecteur : Optimal Taille de bande (Ko) : 64 Stratégie d'accès : Lire Écriture Stratégie de lecture : Normal Stratégie de cache en écriture configurée : Écriture via Stratégie de cache d'écriture réelle : Écriture via Politique d'E/S : Direct Cache de lecteur : Aucune modification Bootable : Vrai Identificateur unique : bcc0dd21-2006-4189-86c1-132017ad0958 Identificateur unique du fournisseur : 618e7283-72eb-6460-240f-d02c0bd9310 ««««««««««««< Après remplacement : Serveur 2/2 : Nom du produit équipé : Serveur lame à 2 connecteurs Cisco UCS B200 M5 PID équipé : UCSB-B200-M5 VID équipé : V06 Série équipée (SN) : FCH222973K5 État du logement : Équipé Nom du produit reconnu : Serveur lame à 2 connecteurs Cisco UCS B200 M5 PID reconnu : UCSB-B200-M5 VID reconnu : V06 Série (SN) reconnue : FCH222973K5 Mémoire reconnue (Mo) : 524288 Mémoire effective reconnue (Mo) : 524288 Coeurs reconnus : 28 Adaptateurs reconnus : 1 Lecteur virtuel 0 : type : RAID 1 mis en miroir Taille du bloc : 512 Blocs : 1560545280 Opérabilité : Opérable Présence : Équipé Taille : 761985 Cycle de vie : Alloué État du lecteur : Optimal Taille de bande (Ko) : 64 Stratégie d'accès : Lire Écriture Stratégie de lecture : Normal Stratégie de cache en écriture configurée : Écriture via Stratégie de cache d'écriture réelle : Écriture via Politique d'E/S : Direct Cache de lecteur : Aucune modification Bootable : Vrai Identificateur unique : 7a894b44-721a-41ae-a3bf-380102b9e64e Identificateur unique du fournisseur : 618e7283-72ea-3f20-ff00-005a0574b04b ««««««««««««««
Dans ce cas, l'ID [Identificateur unique du fournisseur] du serveur 2/2 a été modifié de [618e7283-72eb-6460-240f-d02c0bbd9310] à [618e7283-72ea-3f 20-ff00-005a0574b04b] |
Comment éviter de s'attaquer au problème ?
Ce problème peut être évité en mettant à jour le micrologiciel du contrôleur de remplacement avant d'insérer la VD / le disque.
Étapes détaillées :
- Arrêter le serveur
- Retirez tous les disques un par un et laissez le même logement non complètement inséré pour que leur ordre de placement ne soit pas perturbé(Si vous retirez complètement le logement, veuillez garder une note sur le logement car les lecteurs doivent être replacés dans le même logement)
- Installer un nouveau contrôleur RAID pour le remplacer sans insérer de disque.
- Le serveur reconnaîtra le nouveau contrôleur RAID
- Mettre à jour le micrologiciel du contrôleur Raid.
- Après une mise à niveau réussie du micrologiciel, mettez le serveur hors tension et insérez le disque dans le serveur.
- À présent, mettez le serveur sous tension
Comment récupérer si le serveur est touché par ce problème ?
Étapes détaillées :
==========================================================================================================================================================================================================================================================
Procédure de restauration du data store
==========================================================================================================================================================================================================================================================
1 Connectez-vous au client vSphere et sélectionnez le serveur dans le panneau Inventaire.
2 Cliquez sur l'onglet Configuration, puis sur Stockage dans le panneau Matériel.
3 Cliquez sur Add Storage.
4 Sélectionnez le type de stockage Disk/LUN et cliquez sur Next (Suivant).
5 Dans la liste des LUN, sélectionnez le LUN dont le nom de magasin de données est affiché dans la colonne Étiquette VMFS, puis cliquez sur Suivant.
Remarque:: Le nom présent dans la colonne Étiquette VMFS indique que le LUN est une copie qui contient une copie d'un data store VMFS existant.
6 Sous Options De Montage ces options s'affichent :
Conserver la signature existante:: Monter en permanence le LUN (par exemple, monter le LUN sur les redémarrages)
Attribuer une nouvelle signature:: Déconnexion du LUN
Formater le disque:: Reformater le LUN
Notes:: Formater le disquesupprime toutes les données existantes sur le LUN. Avant d'essayer de resigner, assurez-vous qu'il n'y a pas de machines virtuelles qui s'exécutent sur ce volume VMFS sur un autre hôte, car ces machines virtuelles ne sont plus valides dans l'inventaire du serveur vCenter et doivent être de nouveau enregistrées sur leurs hôtes respectifs.
sélectionnez Attribuer une nouvelle signature, puis cliquez sur Suivant.
7 Sélectionnez l'option souhaitée pour votre volume
8 Dans la page Prêt à terminer, passez en revue les informations de configuration du data store et cliquez sur Terminer.
==========================================================================================================================================================================================================================================================
Que faire ensuite
=========================
Après avoir démissionné, vous devrez peut-être effectuer les opérations suivantes :
1 Se connecter au client vSphere, USous Liste d'inventaire > Cliquez sur Datastore
2 Cliquez avec le bouton droit sur le data store et cliquez sur Browse Datastore
3 Dans le volet de gauche, cliquez sur un dossier VM pour afficher le contenu dans le volet de droite
4 Dans le volet droit, cliquez avec le bouton droit sur le fichier .vmx et sélectionnez Ajouter à l'inventaire
5 Procédure pas à pas de l'assistant « Ajouter à l'inventaire » pour terminer l'ajout de la machine virtuelle à l'hôte ESXi
6 Répétez les étapes pour toutes les machines virtuelles restantes
7 Une fois toutes les machines virtuelles réenregistrées, supprimez toutes les machines virtuelles inaccessibles de l'inventaire en cliquant avec le bouton droit sur chacune d'elles et en sélectionnant Supprimer de l'inventaire.
8 Mise sous tension de chaque machine virtuelle et vérification de son fonctionnement et de son accessibilité
Note: Avant de mettre la machine virtuelle sous tension, redémarrez l'hôte ESXi et, après son retour en ligne et accessible via le client vSphere, vérifiez que les machines virtuelles sont toujours visibles et ne sont pas à l'état « Inaccessible »
CSCvr11972 Identificateur unique du fournisseur modifié après le remplacement de MRAID12G
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr11972