Команди powermt завершуються помилкою "ПОМИЛКА: Заява про пристрій Лам не вдалася"

Ця конкретна проблема може виникнути лише тоді, коли сервер підключено як до керованих PowerPath, так і до некерованих масивів PowerPath і після змін конфігурації обох масивів. У нашому прикладі деякі пристрої Clariion було видалено, але відповідний псевдопристрій не було очищено. Потім було додано сховище IBM, і диски, які спочатку використовувалися як шлях до цих видалених пристроїв Clariion, були повторно використані для опису нових дисків IBM. Це призвело до цих неправильних записів в ODM.   

Навколишнє середовище :
OS : AIX (будь-який смак)
DELL EMC SW : PowerPath для AIX (будь-якого релізу)
без DELL EMC HW : диски з масиву, яким не керує PowerPath.

У середовищі AIX команди powermt завершуються помилкою «ПОМИЛКА: Заява про пристрій Лам не вдалася». Ця помилка не задокументована в нашому довіднику Dell EMC PowerPath Family CLI та системних повідомлень.

Повідомлення повідомляє Powerpath, коли PowerPath не може визначити, до якого LAM (модуля завантажувального масиву) належить пристрій. Оскільки команди PowerPath не працюють, усунення несправностей можна виконати лише дивлячись на ODM. Якщо Powerpath шукає LAM і не може знайти відповідний, це означає, що існує псевдопристрій із записами в ODM, що вказують на тип пристрою, який не очікується PowerPath.

У випадку, який спричинив створення цієї статті, ми мали наступне в ODM :CuAt:
name = "hdiskpower29"
attribute = "vpd_map"value
= "MF0808C,TM1010C,RL2004C,Z00008X,Z1040780C,SN081083X"type
= "V"
generic = ""rep
= "sl"
nls_index = 0

Перевіряючи PdAt для цього виду пристрою, ми знаходимо :

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

Це не диск типу DELL EMC і не щось, що керується PowerPath: це диск IBM.

Більш простий доказ характеру пристрою дає unique_id атрибут псевдопристрою. У нашому випадку у нас було (реальне значення було змінено для збереження конфіденційності) :

CuAt:
    name = "hdiskpower29"
attribute = "unique_id"
value = "33213600507680C80017D38000000000XXXXX4503IBMfcp"
type = "R"
generic = ""
rep = "s"
nls_index = 0
 
Коли такі записи існують в ODM, і коли псевдопристрій (тут hdiskpower29) посилається в"powermt_custom.xml", то "powermt config" не зможе пов'язати LAM з пристроєм і вийде з ладу.і інша команда "powermt" зазнає невдачі з тією ж помилкою.

Оскільки всі команди "powermt" зазнають невдачі, оновити файл "powermt_custom.xml" за допомогою "powermt save" неможливо. Видалення файлу "powermt_custom.xml" було б дуже поганою ідеєю через ризик втрати зв'язку між правильними псевдопристроями та пристроями керованого масиву PowerPath.

Єдиний спосіб вирішити проблему – видалити з ODM усі псевдопристрої, де атрибутом «unique_id» є XXXXIBMfcp. І замість того, щоб використовувати небезпечні команди "odmdelete", рекомендується просто використовувати команду "rmdev -dl <pseudo_device>".

Ось приклад команд, які були запущені для видалення неправильних записів у нашому прикладі (звичайно, кожен випадок унікальний, а наведений нижче список є лише прикладом) :

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$Після цього очищення запустіть
"конфігурацію powermt", а потім "збереження powermt".

На цьому етапі ви також можете виявити деякі «мертві» шляхи (для псевдопристроїв, які також видалено з конфігурації, але де відповідні диски не використовувалися повторно, щоб вказувати на диски, не керовані PowerPath, і які не були помічені в ODM під час перевірки атрибута «unique_id») у «дисплеї powermt». Ці записи буде очищено командою "powermt check". У такому випадку не забудьте знову запустити «збереження powermt» після цього остаточного очищення.