powermt komutları "ERROR: Device Lam claim failed"

Bu özel sorun yalnızca sunucu hem PowerPath tarafından yönetilen hem de PowerPath yönetilmeyen dizilere bağlandığında ve her iki dizide de yapılandırma değişikliklerini takiben ortaya çıkabilir. Örneğimizde, bazı Clariion aygıtları kaldırılmıştı ancak karşılık gelen sözde aygıt temizlenmemişti. Daha sonra IBM depolaması eklendi ve başlangıçta kaldırılan bu Clariion aygıtlarına bir yol olarak kullanılan hdiskler, yeni IBM disklerini tanımlamak için yeniden kullanıldı. Bu, ODM'de bu yanlış girişlere neden oldu.   

Çevre:
İşletim Sistemi : AIX (herhangi bir aroma)
DELL EMC SW: AIX için PowerPath (herhangi bir sürüm)
olmayan DELL EMC HW: PowerPath tarafından yönetilemeyen bir dizideki diskler.

Bir AIX ortamında, powermt komutları "ERROR: Device Lam claim failed". Bu hata, Dell EMC PowerPath Ailesi CLI ve Sistem Mesajları Referansımızda belgelenmemiştir.

PowerPath bir aygıtın hangi LAM'a (Yüklenebilir Dizi Modülü) ait olduğunu belirleyemediğinde mesaj PowerPath tarafından bildirilir. PowerPath komutları çalışmadığından, sorun giderme yalnızca ODM'ye bakarak yapılabilir. Powerpath bir LAM arıyorsa ve uygun olanı bulamıyorsa, bu, ODM'de girişleri olan ve PowerPath tarafından beklenmeyen bir cihaz türüne işaret eden bir sözde cihaz olduğu anlamına gelir.

Bu makalenin oluşturulmasına neden olan durumda, ODM'de

şunlar vardı: CuAt:
name = "hdiskpower29"
attribute = "vpd_map"
value = "MF0808C,TM1010C,RL2004C,Z00008X,Z1040780C,SN081083X"
type = "V"
generic = ""rep
= "sl"
nls_index = 0

Bu tür bir aygıt için PdAt'ı kontrol ettiğimizde şunu

buluyoruz: 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

Bu bir DELL EMC disk türü veya PowerPath tarafından yönetilen herhangi bir şey değildir: bu bir IBM diskidir.

Cihazın doğasının daha kolay kanıtı, sözde cihazın unique_id özelliği ile verilir. Bizim durumumuzda, vardı (gizliliği korumak için gerçek değer değiştirildi) :

CuAt:
    name = "hdiskpower29"
attribute = "unique_id"
value = "33213600507680C80017D3800000000000XXXXXXX4503IBMfcp"
type = "R"
generic = "" rep = "s
"
nls_index = 0
 
ODM'de bu tür girişler bulunduğunda ve sözde aygıta (burada hdiskpower29) "powermt_custom.xml" içinde atıfta bulunulduğunda, "powermt config" bir LAM'ı aygıtla ilişkilendiremez ve başarısız olur.ve diğer "powermt" komutu aynı hatayla başarısız olur.

Tüm powermt" komutları başarısız olduğu için "powermt_custom.xml" dosyasını "powermt save" ile güncellemek mümkün değildir. Doğru sözde aygıtlar ile PowerPath yönetilen dizi aygıtları arasındaki ilişkiyi kaybetme riski nedeniyle "powermt_custom.xml" dosyasını silmek çok kötü bir fikir olacaktır.

Sorunu gidermenin tek yolu, "unique_id" özniteliğinin XXXXIBMfcp olduğu tüm sözde aygıtları ODM'den kaldırmaktır. Ve tehlikeli "odmdelete" komutları kullanmak yerine, sadece bir "rmdev -dl <pseudo_device>" komutu kullanmanız önerilir.

Örneğimizdeki yanlış girişleri kaldırmak için çalıştırılan komutlara bir örnek aşağıda verilmiştir (elbette her durum benzersizdir ve aşağıdaki liste sadece bir örnektir) :

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$Bu
temizlemeyi takiben

, bir "powermt config" ve ardından bir "powermt save" çalıştırın. Bu aşamada, "powermt display" içinde bazı "ölü" yollar da keşfedebilirsiniz (yapılandırmadan kaldırılan ancak ilgili hdisk'lerin PowerPath tarafından yönetilmeyen diskleri gösterecek şekilde yeniden kullanılmadığı ve "unique_id" özniteliği kontrol edilirken ODM'de tespit edilmeyen aygıtlar için). Bu girişler bir "powermt check" komutuyla temizlenecektir. Böyle bir durumda, bu son temizlikten sonra tekrar bir "powermt save" çalıştırmayı unutmayın.