powermt-kommandoer mislykkes med "ERROR: Påstanden om Device Lam mislyktes"

Dette bestemte problemet kan bare oppstå når serveren er koblet til både PowerPath-administrerte og PowerPath ikke-administrerte arrayer og følger konfigurasjonsendringer på begge arrayene. I vårt eksempel hadde noen Clariion-enheter blitt fjernet, men den tilsvarende pseudo-enheten hadde ikke blitt ryddet opp. Deretter ble IBM-lagring lagt til, og hdiskene, som opprinnelig ble brukt som en bane til disse fjernede Clariion-enhetene, ble gjenbrukt til å beskrive de nye IBM-diskene. Dette resulterte i disse feiloppføringene i ODM.   

Miljø :
OS : AIX (enhver smak)
DELL EMC SW: PowerPath for AIX (alle utgivelser)
ikke DELL EMC HW: disker fra en matrise som ikke kan administreres av PowerPath.

I et AIX-miljø mislykkes powermt-kommandoer med "ERROR: Påstanden om Device Lam mislyktes". Denne feilen er ikke dokumentert i CLI- og systemmeldingsreferansen for Dell EMC PowerPath-serien.

Meldingen rapporteres av PowerPath når PowerPath ikke kan fastslå hvilken LAM (Loadable Array Module) en enhet tilhører. Fordi PowerPath-kommandoene ikke fungerer, kan feilsøking bare utføres ved å se på ODM. Hvis PowerPath leter etter en LAM og ikke finner den riktige, betyr det at det finnes en pseudoenhet med oppføringer i ODM som peker til en enhetstype som ikke forventes av PowerPath.

I tilfellet som forårsaket opprettelsen av denne artikkelen, hadde vi følgende i ODM: CuAt:
name = "hdiskpower29"
attribute = "vpd_map"
value = "MF0808C,TM1010C,RL2004C,Z00008X,Z1040780C,SN081083X"
type = "V"
generic = ""
rep = "sl"
nls_index = 0

Ved å sjekke PdAt for denne typen enheter finner vi:

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

Dette er ikke en DELL EMC-type disk eller noe som administreres av PowerPath : dette er en IBM-disk.

Lettere bevis på enhetens natur er gitt av pseudoenhetens unique_id attributt. I vårt tilfelle hadde vi (den virkelige verdien ble endret for å bevare konfidensialitet) :

CuAt:
    name = "hdiskpower29"
attribute = "unique_id"
value = "33213600507680C80017D380000000000000XXXXXXX4503IBMfcp"
type = "R"
generic = ""
rep = "s"
nls_index = 0
 
Når slike oppføringer finnes i ODM, og når pseudoenheten (her hdiskpower29) refereres til i "powermt_custom.xml", vil "powermt config" ikke kunne knytte en LAM til enheten og vil mislykkes.and den andre "powermt" -kommandoen vil mislykkes med samme feil.

Fordi alle "powermt"-kommandoene mislykkes, er det ikke mulig å oppdatere "powermt_custom.xml"-filen med en "powermt save". Det ville være en svært dårlig idé å slette "powermt_custom.xml"-filen på grunn av risikoen for å miste relasjonen mellom de riktige pseudoenhetene og de PowerPath-administrerte arrayenhetene.

Den eneste måten å fjerne problemet på er å fjerne alle pseudoenhetene der "unique_id" -attributtet er XXXXIBMfcp fra ODM. Og i stedet for å bruke farlige "odmdelete" -kommandoer, anbefales det å bare bruke en "rmdev -dl <pseudo_device>" -kommando.

Her er et eksempel på kommandoene som ble kjørt for å fjerne feil oppføringer i vårt eksempel (selvfølgelig er hvert tilfelle unikt, og listen nedenfor er bare et eksempel):

for jeg i 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$Jeg
ferdig

Etter denne oppryddingen kjører du en "powermt config" etterfulgt av en "powermt save". På dette stadiet kan du også oppdage noen "døde" baner (for pseudoenheter som også er fjernet fra konfigurasjonen, men hvor de tilsvarende hdiskene ikke har blitt gjenbrukt til å peke på ikke-PowerPath-administrerte disker, og som ikke ble oppdaget i ODM når de kontrollerte "unique_id"-attributtet) i "powermt display". Det ryddes opp i disse oppføringene med kommandoen "powermt check". I et slikt tilfelle, ikke glem å kjøre en "powermt save" igjen etter denne siste oppryddingen.