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:
system operacyjny: AIX (dowolny smak)
DELL SW: PowerPath dla AIX (dowolna wersja)
Sprzęt innych niż DELL: dyski z macierzy, która nie jest zarządzana przez PowerPath.

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

PowerPath zgłasza ten komunikat, gdy nie może określić, do którego modułu macierzy Loadable Array Module (LAM) 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źć odpowiedniej LAM, 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 elementy:

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

To nie jest dysk firmy DELL ani nic zarządzanego przez PowerPath: to jest dysk IBM.

Atrybut unique_id pseudourządzenia daje łatwiejszy dowód na charakter urządzenia. W naszym przypadku mieliśmy (rzeczywista wartość została zmieniona w celu zachowania poufności):

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

Jeśli takie wpisy istnieją w ODM, a pseudo urządzenie (w tym przypadku hdiskpower29) jest przywoływane w "powermt_custom.xml", to "powermt config" nie może skojarzyć LAM z urządzeniem i zakończyć się niepowodzeniem, a drugie polecenie "powermt" kończy się niepowodzeniem z tym samym błędem.

Ponieważ wszystkie polecenia "powermt" kończą się niepowodzeniem, nie można zaktualizować pliku "powermt_custom.xml" za pomocą polecenia "powermt save". Usunięcie pliku "powermt_custom.xml" byłoby 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 nieprawidłowych wpisów w naszym przykładzie (każdy przypadek jest unikalny, a poniższa lista jest przykładem):

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

Po zakończeniu czyszczenia uruchom polecenie "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 wskazania 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 są czyszczone za pomocą polecenia "powermt check". W takim przypadku nie zapomnij ponownie uruchomić "powermt save" po tym ostatecznym czyszczeniu.