Les commandes powermt échouent avec le message « ERROR : La demande de remboursement Device Lam a échoué »

Ce problème particulier ne peut se produire que lorsque le serveur est rattaché à des baies gérées par PowerPath et non gérées par PowerPath et après des modifications de configuration sur les deux baies. Dans notre exemple, certains appareils Clariion avaient été supprimés, mais le pseudo-appareil correspondant n’avait pas été nettoyé. Ensuite, le stockage IBM a été ajouté et les hdisks, initialement utilisés comme chemin d’accès à ces périphériques Clariion supprimés, ont été réutilisés pour décrire les nouveaux disques IBM. Cela a entraîné ces entrées incorrectes dans l’ODM.   

Environnement :
OS : AIX (n’importe quelle version)
LOGICIEL DELL EMC : PowerPath for AIX (toute version)
autre que DELL EMC HW : disques d’une baie ne pouvant pas être gérés par PowerPath.

Dans un environnement AIX, les commandes powermt échouent avec le message « ERROR : La demande Device Lam a échoué ». Cette erreur n’est pas documentée dans notre Référence des messages système et de l’interface de ligne de commande de la famille Dell EMC PowerPath.

Le message est signalé par PowerPath lorsque PowerPath ne parvient pas à déterminer à quel LAM (Loadable Array Module) appartient un appareil. Étant donné que les commandes PowerPath ne fonctionnent pas, le dépannage ne peut être effectué qu’en regardant l’ODM. Si Powerpath recherche un LAM et ne trouve pas celui qui convient, cela signifie qu’il existe un pseudo-périphérique, avec des entrées dans l’ODM, pointant vers un type de périphérique non attendu par PowerPath.

Dans le cas qui a provoqué la création de cet article, nous avons eu ce qui suit dans l’ODM :CuAt :
name = « hdiskpower29"
attribute = « vpd_map"
value = « MF0808C,TM1010C,RL2004C,Z00008X,Z1040780C,SN081083X"
type = « V"
generic = « "rep
= « sl"
nls_index = 0

En vérifiant le PdAt pour ce type de périphérique, on trouve :

PdAt :uniquetype = « disk/fcp/2145"attribute = « vpd_map »




deflt = « MF0808C,TM1010C,RL2004C,Z00008X,Z1040780C,SN081083X"values
= « "
width = « "
type = « V"
generic = « "
rep = « sl"
nls_index = 0

Il ne s’agit pas d’un disque de type DELL EMC ni d’un disque géré par PowerPath : il s’agit d’un disque IBM.

Une preuve plus facile de la nature du périphérique est donnée par l’attribut unique_id du pseudo-périphérique. Dans notre cas, nous avions (la valeur réelle a été modifiée pour préserver la confidentialité) :

CuAt :
    name = « hdiskpower29 »
attribute = « unique_id »
value = « 33213600507680C80017D38000000000000XXXXXXX4503IBMfcp »
type = « R »
generic = «  »
rep = « s »
nls_index = 0
 
Lorsque de telles entrées existent dans l’ODM, et lorsque le pseudo-périphérique (ici hdiskpower29) est référencé dans « powermt_custom.xml », alors « powermt config » ne pourra pas associer un LAM au périphérique et échouera.et l’autre commande « powermt » échouera avec la même erreur.

Étant donné que toutes les commandes « powermt » échouent, il n’est pas possible de mettre à jour le fichier « powermt_custom.xml » avec une commande « powermt save ». La suppression du fichier « powermt_custom.xml » serait une très mauvaise idée, car elle risquerait de perdre la relation entre les pseudo-périphériques corrects et les appareils de baie gérés par PowerPath.

La seule façon de résoudre le problème consiste à supprimer de l’ODM tous les pseudo-périphériques dont l’attribut « unique_id » est XXXXIBMfcp. Et plutôt que d’utiliser des commandes « odmdelete » dangereuses, il est conseillé d’utiliser simplement une commande « rmdev -dl <pseudo_device> ».

Voici un exemple des commandes qui ont été exécutées pour supprimer les entrées incorrectes dans notre exemple (bien sûr, chaque cas est unique et la liste ci-dessous n’est qu’un exemple) :

pour i dans 29 30 31 32 33 34 39 40 41 42 43 44 45 46 47 48 125 136 137 138 167 168 169 170 171 172 173 216 217 267 522 523 524 525 526 527
do
rmdev -dl hdiskpower$Après
cenettoyage, lancez une « powermt config » suivie d’une « powermt save ».

À ce stade, vous pouvez également découvrir des chemins « morts » (pour des pseudo-périphériques également supprimés de la configuration mais dont les hdisks correspondants n’ont pas été réutilisés pour pointer vers des disques non gérés par PowerPath et qui n’ont pas été repérés dans l’ODM lors de la vérification de l’attribut « unique_id ») dans « powermt display ». Ces entrées seront nettoyées à l’aide de la commande « powermt check ». Dans ce cas, n’oubliez pas d’exécuter à nouveau une « powermt save » après ce nettoyage final.