Команди powerMT не виходять з "ERROR: Позов Device Lam не вдалося»

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

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

У AIX-середовищі команди powermt не виконуються з "ERROR: Заява Device Lam не вдалася.» Ця помилка не зафіксована у нашому CLI Family Dell PowerPath та System Messages Reference.

PowerPath повідомляє це повідомлення, коли не може визначити, до якого Loadable Array Module (LAM) належить пристрій. Оскільки команди PowerPath не працюють, усунення несправності можна здійснювати лише за допомогою ODM. Якщо PowerPath шукає LAM і не може знайти відповідний 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 і не управляється PowerPath: це диск IBM.

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

CuAt:
    name = "hdiskpower29"
    attribute = "unique_id"
    value = "33213600507680C80017D3800000000000XXXXXXX4503IBMfcp"
    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$i
done

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