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 :
Système d’exploitation : AIX (n’importe quelle saveur)
Logiciel DELL : PowerPath for AIX (n’importe quelle version)
Matériel non DELL : 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 Dell PowerPath Family CLI et System Messages Reference.

PowerPath signale ce message lorsqu’il ne parvient pas à déterminer à quel module de baie chargeable (LAM) 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 le LAM approprié, 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 avions 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 de ce type d’appareil, nous trouvons :

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 type de disque DELL ni d’un disque géré par PowerPath : il s’agit d’un disque IBM.

L’attribut unique_id du pseudo-périphérique fournit des preuves plus faciles de la nature du 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 = "33213600507680C80017D3800000000000XXXXXXX4503IBMfcp"
    type = "R"
    generic = ""
    rep = "s"
    nls_index = 0

Lorsque de telles entrées existent dans l’ODM et que le pseudo-périphérique (ici hdiskpower29) est référencé dans « powermt_custom.xml », alors « powermt config » ne peut pas associer un LAM au périphérique et échoue, et l’autre commande « powermt » échoue 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 mauvaise idée, car elle risquerait de perdre la relation entre les pseudo-périphériques appropriés 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 (chaque cas est unique et la liste ci-dessous en est un exemple) :

for i in 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$i
done

Après ce nettoyage, exécutez 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 sont 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.