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 varianter)
DELL EMC SW: PowerPath för AIX (alla versioner)
utan DELL EMC HW: diskar från ett disksystem som inte kan hanteras av PowerPath.

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

Meddelandet rapporteras av PowerPath när PowerPath inte kan avgöra vilken LAM (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 rätt 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 fallet 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 EMC-typ av disk eller något som hanteras av PowerPath: det här är en IBM-disk.

Lättare bevis på enhetens natur ges av pseudoenhetens unique_id-attribut. I vårt fall hade vi (det verkliga värdet ändrades för att bevara konfidentialiteten):


    name = "hdiskpower29"
attribute = "unique_id"
value = "33213600507680C80017D380000000000000XXXXXXX4503IBMfcp"
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", kommer "powermt config" inte att kunna associera en LAM till enheten och kommer att misslyckas.och det andra "powermt"-kommandot kommer att misslyckas med samma fel.

Eftersom alla powermt-kommandon misslyckas går det inte att uppdatera powermt_custom.xml-filen med en powermt-lagring. Att ta bort powermt_custom.xml-filen skulle vara en mycket dålig idé eftersom det finns risk för att förlora relationen mellan de korrekta pseudoenheterna 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 rekommenderar vi att du helt enkelt använder kommandot "rmdev -dl <pseudo_device>".

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

för i 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$Jag
är klar

Efter denna rensning, kör 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 hårddiskar 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 display". Posterna rensas med kommandot "powermt check". Glöm i så fall inte att köra en "powermt save" igen efter den här sista rensningen.