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 for å beskrive de nye IBM-diskene. Dette resulterte i disse feiloppføringene i ODM

Miljø:
OS: AIX (enhver smak)
DELL SW: PowerPath for AIX (alle versjoner)
Ikke-DELL 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 referansen for CLI og systemmeldinger i Dell PowerPath-serien.

PowerPath rapporterer denne meldingen 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 riktig LAM, 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

Når vi sjekker 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-type disk eller noe som administreres av PowerPath: dette er en IBM-disk.

Den unique_id attributtet til pseudoenheten gir lettere bevis på enhetens natur. I vårt tilfelle hadde vi (den reelle verdien ble endret for å bevare konfidensialitet):

CuAt:
    name = "hdiskpower29"
    attribute = "unique_id"
    value = "33213600507680C80017D3800000000000XXXXXXX4503IBMfcp"
    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", kan "powermt config" ikke knytte en LAM til enheten og mislykkes, og den andre "powermt"-kommandoen mislykkes med samme feil.

Fordi alle "powermt"-kommandoene mislykkes, er det ikke mulig å oppdatere "powermt_custom.xml"-filen med powermt save. Det ville være en 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 (hvert tilfelle er unikt og listen nedenfor er et eksempel):

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

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 du sjekket "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.