powermt-kommandoer mislykkes med "FEJL: Device Lam-krav mislykkedes"

Dette særlige problem kan kun opstå, når serveren er tilsluttet både PowerPath-administrerede og ikke-administrerede PowerPath-systemer og efterfølgende konfigurationsændringer på begge systemer. I vores eksempel var nogle Clariion-enheder blevet fjernet, men den tilsvarende pseudo-enhed var ikke blevet ryddet op. Derefter blev IBM-lager tilføjet, og hdisks, der oprindeligt blev brugt som en sti til disse fjernede Clariion-enheder, blev genbrugt til at beskrive de nye IBM-diske. Dette resulterede i disse forkerte poster i ODM

Miljø:
OS: AIX (enhver smag)
DELL SW: PowerPath til AIX (enhver version) Ikke-DELL HW:
diske fra et system, der ikke kan administreres af PowerPath.

I et AIX-miljø mislykkes powermt-kommandoer med "FEJL: Device Lam-krav mislykkedes." Denne fejl er ikke dokumenteret i vores Dell PowerPath-serie CLI og System Messages Reference.

PowerPath rapporterer denne meddelelse, når PowerPath ikke kan afgøre, hvilket LAM-modul (Loadable Array Module) en enhed tilhører. Da PowerPath-kommandoerne ikke virker, kan fejlfinding kun udføres ved at se på ODM. Hvis PowerPath leder efter en LAM og ikke kan finde den relevante LAM, betyder det, at der er en pseudoenhed med poster i ODM, der peger på en enhedstype, som PowerPath ikke forventer.

I det tilfælde, der forårsagede oprettelsen af denne artikel, havde 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

Kontrol af PdAt for denne type enhed finder 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 disk af DELL-typen eller noget, der administreres af PowerPath: Dette er en IBM-disk.

Den unique_id egenskab af pseudoindretningen giver lettere bevis for enhedens art. I vores tilfælde havde vi (den reelle værdi blev ændret for at bevare fortroligheden):

CuAt:
    name = "hdiskpower29"
    attribute = "unique_id"
    value = "33213600507680C80017D3800000000000XXXXXXX4503IBMfcp"
    type = "R"
    generic = ""
    rep = "s"
    nls_index = 0

Når sådanne poster findes i ODM, og når pseudoenheden (her hdiskpower29) refereres til i "powermt_custom.xml", kan "powermt-konfiguration" ikke knytte en LAM til enheden og mislykkes, og den anden "powermt"-kommando mislykkes med den samme fejl.

Da alle "powermt"-kommandoerne mislykkes, er det ikke muligt at opdatere filen "powermt_custom.xml" med et "powermt save". Det ville være en dårlig idé at slette filen "powermt_custom.xml" på grund af risikoen for at miste forholdet mellem de korrekte pseudoenheder og de PowerPath-administrerede systemenheder.

Den eneste måde at rydde problemet på er at fjerne fra ODM alle pseudo-enheder, hvor attributten "unique_id" er XXXXIBMfcp. Og i stedet for at bruge farlige "odmdelete" kommandoer, anbefales det blot at bruge en "rmdev -dl <pseudo_device>" kommando.

Her er et eksempel på de kommandoer, der blev kørt for at fjerne de forkerte poster i vores eksempel (hvert tilfælde er unikt, og nedenstående liste 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

Efter denne oprydning skal du køre en "powermt-konfiguration" efterfulgt af en "powermt save". På dette tidspunkt kan du også opdage nogle "døde" stier (for pseudo-enheder, der også er fjernet fra konfigurationen, men hvor de tilsvarende hdisks ikke er blevet genbrugt til at pege på ikke-PowerPath-administrerede diske, og som ikke blev opdaget i ODM, da du kontrollerede attributten "unique_id") i "powermt-skærm". Disse poster ryddes op med kommandoen "powermt check". I et sådant tilfælde skal du ikke glemme at køre en "powermt save" igen efter denne endelige oprydning.