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şlerle sonuçlandı

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

Bir AIX ortamında, powermt komutları "ERROR: Device Lam iddiası başarısız oldu." Bu hata, Dell PowerPath Ailesi CLI ve Sistem Mesajları Referansımızda belgelenmemiştir.

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

Bu makalenin oluşturulmasına neden olan durumda, ODM'de aşağıdakilere sahiptik:

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 cihaz için PdAt'ı kontrol ettiğimizde şunları 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 türü disk veya PowerPath tarafından yönetilen herhangi bir şey değildir: Bu bir IBM diskidir.

Sözde cihazın unique_id özelliği, cihazın doğası hakkında daha kolay kanıt sağlar. 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 mevcut olduğ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üncelleştirmek 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 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 (her durum benzersizdir ve aşağıdaki liste 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$i
done

Bu temizleme işleminin ardından bir "powermt config" ve ardından "powermt save" çalıştırın. Bu aşamada, "powermt display" içinde bazı "ölü" yollar da keşfedebilirsiniz (yapılandırmadan da çıkarı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 temizlenir. Böyle bir durumda, bu son temizlikten sonra tekrar bir "powermt save" çalıştırmayı unutmayın.