polecenia powermt kończą się niepowodzeniem z komunikatem "ERROR: Device Lam claim failed"

Ten konkretny problem może wystąpić tylko wtedy, gdy serwer jest podłączony zarówno do macierzy zarządzanych, jak i niezarządzanych PowerPath i nastąpiły zmiany konfiguracji obu macierzy. W naszym przykładzie niektóre urządzenia Clariion zostały usunięte, ale odpowiadające im pseudourządzenie nie zostało wyczyszczone. Następnie dodano pamięć masową IBM, a dyski hdisk, początkowo używane jako ścieżka do usuniętych urządzeń Clariion, zostały ponownie użyte do opisania nowych dysków IBM. Skutkowało to nieprawidłowymi wpisami w ODM.   

Środowisko :
OS : AIX (dowolna wersja)
DELL EMC SW : PowerPath dla AIX (dowolna wersja),
bez sprzętu Dell EMC: dyski z macierzy, która nie jest zarządzana przez PowerPath.

W środowisku AIX polecenia powermt kończą się niepowodzeniem z komunikatem "ERROR: Device Lam claim failed". Ten błąd nie jest udokumentowany w interfejsie CLI rodziny Dell EMC PowerPath ani w dokumentacji komunikatów systemowych.

Komunikat jest zgłaszany przez firmę PowerPath, gdy nie może ona określić, do którego modułu LAM (Loadable Array Module) należy urządzenie. Ponieważ polecenia PowerPath nie działają, rozwiązywanie problemów można przeprowadzić tylko patrząc na ODM. Jeśli Powerpath szuka LAM i nie może znaleźć odpowiedniego, oznacza to, że istnieje pseudourządzenie z wpisami w ODM, wskazującymi typ urządzenia nieoczekiwany przez PowerPath.

W przypadku, który spowodował powstanie tego artykułu, w ODM

mieliśmy następujące :CuAt:
name = "hdiskpower29"
attribute = "vpd_map"
value = "MF0808C,TM1010C,RL2004C,Z00008X,Z1040780C,SN081083X"
type = "V"
generic = ""
rep = "sl"
nls_index = 0

Sprawdzając PdAt dla tego rodzaju urządzenia, znajdujemy :

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

Nie jest to dysk firmy DELL EMC ani sprzęt zarządzany przez PowerPath: to jest dysk IBM.

Łatwiejszym dowodem na naturę urządzenia jest atrybut unique_id pseudourządzenia. W naszym przypadku mieliśmy (rzeczywista wartość została zmieniona w celu zachowania poufności) :

CuAt:
    name = "hdiskpower29"
atrybut = "unique_id"
wartość = "33213600507680C80017D3800000000000XXXXXXX4503IBMfcp"
type = "R"
generic = ""
rep = "s"
nls_index = 0
 
Jeśli takie wpisy istnieją w ODM, a pseudo urządzenie (tutaj hdiskpower29) jest przywoływane w "powermt_custom.xml", to "powermt config" nie będzie w stanie skojarzyć LAM z urządzeniem i zakończy się niepowodzeniem, a drugie polecenie "powermt" zakończy się niepowodzeniem z tym samym błędem.

Ponieważ wszystkie polecenia "powermt" kończą się niepowodzeniem, aktualizacja pliku "powermt_custom.xml" za pomocą polecenia "powermt save" nie jest możliwa. Usunięcie pliku "powermt_custom.xml" byłoby bardzo złym pomysłem ze względu na ryzyko utraty relacji między poprawnymi pseudourządzeniami a urządzeniami macierzy zarządzanej PowerPath.

Jedynym sposobem rozwiązania tego problemu jest usunięcie z ODM wszystkich pseudourządzeń, których atrybut "unique_id" to XXXXIBMfcp. Zamiast używać niebezpiecznych poleceń "odmdelete", zaleca się po prostu użyć polecenia "rmdev -dl <pseudo_device>".

Oto przykład poleceń, które zostały uruchomione w celu usunięcia błędnych wpisów w naszym przykładzie (oczywiście każdy przypadek jest unikalny, a poniższa lista jest tylko przykładem):

dla i w 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$Zrobiłem


Po tym czyszczeniu uruchom "powermt config", a następnie "powermt save". Na tym etapie można również wykryć pewne "martwe" ścieżki (dla pseudourządzeń, również usuniętych z konfiguracji, ale gdzie odpowiednie dyski hdisk nie zostały ponownie użyte do wskazywania dysków zarządzanych innych niż PowerPath i które nie zostały wykryte w ODM podczas sprawdzania atrybutu "unique_id") w "powermt display". Wpisy te zostaną wyczyszczone za pomocą polecenia "powermt check". W takim przypadku nie zapomnij ponownie uruchomić "powermt save" po tym ostatecznym czyszczeniu.