powermt-kommandon misslyckas med "ERROR: Enhetens Lam-anspråk misslyckades"

Det här problemet kan bara uppstå när servern är ansluten till både PowerPath-hanterade och icke-hanterade PowerPath-disksystem och efter konfigurationsändringar på båda disksystemen. I vårt exempel hade vissa Clariion-enheter tagits bort, men motsvarande pseudoenhet hade inte rensats. Sedan lades IBM-lagring till och hårddiskarna, som ursprungligen användes som en väg till dessa borttagna Clariion-enheter, återanvändes för att beskriva de nya IBM-diskarna. Detta resulterade i dessa felaktiga poster i ODM

Miljö: OS:
AIX (alla smaker)
DELL SW: PowerPath för AIX (alla versioner)
Icke-DELL HW: diskar från ett disksystem som inte kan hanteras av PowerPath.

I en AIX-miljö misslyckas powermt-kommandon med "ERROR: Begäran om enhet Lam misslyckades." Det här felet finns inte dokumenterat i vår referens för CLI och systemmeddelanden i Dell PowerPath-serien.

PowerPath rapporterar det här meddelandet när PowerPath inte kan avgöra vilken LAM-modul (Loadable Array Module) en enhet tillhör. Eftersom PowerPath-kommandona inte fungerar kan felsökning bara utföras genom att titta på ODM. Om PowerPath söker efter en LAM och inte kan hitta lämplig LAM innebär det att det finns en pseudoenhet, med poster i ODM, som pekar på en typ av enhet som inte förväntas av PowerPath.

I det fall som orsakade skapandet av den här artikeln hade vi följande 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 kontrollerar PdAt för den här typen av enhet hittar 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

Det här är inte en DELL-typ av disk eller något som hanteras av PowerPath: det här är en IBM-disk.

Pseudoenhetens unique_id attribut ger lättare bevis på enhetens natur. I vårt fall hade vi (det verkliga värdet ändrades för att bevara konfidentialiteten):

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

När sådana poster finns i ODM, och när pseudoenheten (här hdiskpower29) refereras till i "powermt_custom.xml", kan "powermt config" inte associera en LAM till enheten och misslyckas, och det andra "powermt"-kommandot misslyckas med samma fel.

Eftersom alla powermt-kommandon misslyckas går det inte att uppdatera powermt_custom.xml-filen med en powermt-lagring. Det skulle vara en dålig idé att ta bort powermt_custom.xml-filen eftersom det finns risk för att förlora relationen mellan rätt pseudoenheter och PowerPath-hanterade disksystemenheter.

Det enda sättet att rensa problemet är att ta bort alla pseudoenheter där attributet "unique_id" är XXXXIBMfcp från ODM. Och istället för att använda farliga "odmdelete"-kommandon, rekommenderas det att helt enkelt använda ett "rmdev -dl <pseudo_device>"-kommando.

Här är ett exempel på de kommandon som kördes för att ta bort de felaktiga posterna i vårt exempel (varje fall är unikt och listan nedan är ett exempel):

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 den här rensningen kör du en "powermt config" följt av en "powermt save". I det här skedet kan du också upptäcka några "döda" sökvägar (för pseudoenheter som också tagits bort från konfigurationen men där motsvarande hdisks inte har återanvänts för att peka på icke-PowerPath-hanterade diskar och som inte upptäcktes i ODM när attributet "unique_id" kontrollerades) i "powermt-skärm". Dessa poster rensas med kommandot "powermt check". Glöm i så fall inte att köra en "powermt save" igen efter den här sista rensningen.