vSphere Lifecycle Manager ekranında iki ESXi host aynı sürümde görünürken birinin “Out of Compliance”, diğerinin “Host not compatible with the image” durumunda olması şaşırtıcı değil. İkisi aynı hata değil. İlki çoğu zaman hedef imaj ile host üzerindeki paketlerin farklı olduğunu anlatırken, ikincisinde mevcut bileşenler hedef imaja geçişi engelleyebilir. Farkı anlamadan Remediate tuşuna basmak, özellikle OEM sürücülü ortamlarda gereksiz riske yol açar.
Buradaki asıl soru “Host güncel mi?” değil, “Host üzerinde çalışan yazılım bileşimi, kümenin tanımladığı hedef imaja güvenli biçimde dönüştürülebilir mi?” olmalı. vLCM’in baktığı şey sadece ESXi build numarası değildir.
Desired image hangi bileşenlerden oluşuyor?
Cluster > Updates > Hosts > Image ekranı, kümenin istenen durumunu tanımlar. Burada ESXi sürümünün yanında Vendor Addon, varsa Firmware and Drivers Addon ve ayrıca eklenmiş Components alanlarını kontrol etmek gerekir. Host üzerinde bulunan VIB veya bileşenler bu tanımdan farklıysa vLCM uyumsuzluk raporlayabilir.
Örnek: İki host da ESXi 8.0 Update 3 çalıştırıyor. Bir host, üreticinin özel ISO dosyasıyla kurulmuş ve daha yeni bir ağ sürücüsü içeriyor. Diğeri standart imajdan kurulmuş. Cluster image içindeki Vendor Addon, ilk hostun sürücüsünden daha eski sürümü getiriyorsa sistem bunu basit bir “patch eksik” problemi olarak değerlendirmez. İmajın uygulanması sürücü düşürme işlemi gerektirebilir. Broadcom'un KB 403277 ve KB 320562 kayıtlarında bu tür durumlar açıkça anlatılıyor.
Bu nedenle yalnızca ESXi Version alanını karşılaştırarak karar vermemek gerekiyor. Özellikle ağ bağdaştırıcısı, HBA, depolama denetleyicisi ve firmware bağımlılıkları önemlidir.
İki durumun operasyonel farkı
Out of Compliance, hostun mevcut durumunun tanımlı imajdan farklı olduğunu belirtir. Uyum kontrolü gerekli değişiklikleri belirleyebiliyor ve ön kontroller olumluysa remediation planlanabilir. Bu bir “kesin güvenli” etiketi değildir; yine bakım penceresi, HA/DRS kapasitesi, vMotion ve yedekleme koşulları incelenir.
Host not compatible with the image ise daha çok ön koşul veya bileşen eşleşmesi sorunlarına işaret eder. Örneğin mevcut VIB daha yeni olabilir, hedef imaj bir bileşeni düşürmeye çalışabilir ya da host modeline uygun OEM ek bileşenleri eksik olabilir. Bu noktada otomatik onarım yerine bileşen uyuşmazlığının nedenini çözmek gerekir.
Hatanın metninde “Downgrades of manually added Components are not supported” yazıyorsa önce ilgili component'in hosttaki ve hedef imajdaki sürümlerini karşılaştır. Özellikle VIB sürüm dizgelerini yalnızca ilk rakamlara bakarak yorumlamak yanıltıcı olabilir; OEM build ve ESXi ana sürüm bilgileri de hesaba katılmalıdır.
Değişiklik yapmadan önce toplayacağım veriler
İlk adım hostları sıralayıp sorunun yalnızca belirli marka/model veya sürücülerde mi tekrarlandığını bulmak. vSphere Client'ta Cluster > Updates > Hosts > Image bölümünde Check Compliance çalıştırıp her hostun detaylarını açarım. Image tanımını değiştirmeden önce mevcut ESXi sürümünü, Vendor Addon versiyonunu ve ek bileşenleri not ederim.
Host üzerinde yetkili erişim varsa aşağıdaki komutlar kurulu yazılımı görmeye yardımcı olur:
esxcli software vib list
esxcli software component listKomutların sonuçları, vLCM ekranındaki desired image bilgileriyle birlikte değerlendirilmelidir. Özellikle ağ ve depolama sürücülerini körlemesine silmek yanlış bir yaklaşım olur; host yönetim bağlantısını veya datastore erişimini kaybetmek mümkündür. SSH'ı sırf veri almak için kalıcı açık tutmak yerine kurumun erişim politikasına göre geçici ve denetimli kullanım tercih edilmelidir.
Bir sonraki kontrol Cluster Image içindeki ilgili Vendor Addon'un gerçekten o donanım için doğru sürüm olup olmadığıdır. Üreticinin uyumluluk matrisi, firmware/driver eşleşmesi ve varsa üreticiye ait offline bundle bu aşamada belirleyici olur. Sadece hatayı susturmak için rastgele yeni bir addon seçmek de doğru değildir.
Remediation öncesi karar sırası
- İlk olarak Check Compliance sonucundaki hatalı host ve bileşen adlarını kaydet.
- Cluster imajının ESXi Version, Vendor Addon ve Components bölümlerini mevcut hostla karşılaştır.
- Uyumsuzluk sürüm düşürmeden kaynaklanıyorsa daha uygun imaj veya desteklenen component sürümünü araştır.
- Pre-remediation Check çalıştır; bakım moduna geçişi, VM taşıma kapasitesini, olası yeniden başlatmayı ve donanım uyumluluğunu kontrol et.
- Planlı bakım penceresinde önce sınırlı kapsamlı bir hostla ilerle; sonuç ve loglar temizse kalan hostlara geç.
Özellikle üretim cluster'ında “Remediate All” seçeneğiyle doğrudan başlamak yerine değişikliğin DRS, HA admission control, depolama erişimi ve ağ bağımlılıklarını nasıl etkileyeceğini görmek gerekir. Ön kontrol, bakım penceresi planlamasının yerine geçmez.
Ne zaman image düzenlenmeli, ne zaman host onarılmalı?
Hostlar doğru üretici sürücülerini çalıştırıyor, fakat desired image daha eski bileşenleri içeriyorsa image tarafını düzeltmek daha mantıklı olabilir. Buna karşılık image kurumsal standart olarak doğrulanmış, yalnızca birkaç host farklı kurulduysa kontrollü remediation düşünülebilir. Kararı teknik uyumluluk matrisi ve geri dönüş planı belirler; tek başına vLCM butonunun aktif olması değil.
Benzer şekilde, yeni bir bileşeni imaja eklemek sorunu çözerken istenmeyen başka hostları etkileyebilir. Aynı cluster içindeki donanım çeşitliliği yüksekse bu etkiyi ayrıca değerlendirmek gerekir. Image kaydı değiştiğinde kümenin hedef durumu değişir; bu da sonraki bakım işlerinin referansını etkiler.
Özetle iki hata için tek bir düzeltme komutu yok. Önce hatanın bir “eksik güncelleme” mi yoksa “hedef imaja geçiş engeli” mi olduğunu ayırmak, daha sonra OEM bileşenleri ve bakım koşullarına göre ilerlemek gerekir.
Kaynak
- Broadcom KB 403277 — https://knowledge.broadcom.com/external/article/403277
- Broadcom KB 320562 — https://knowledge.broadcom.com/external/article/320562
- Broadcom KB 426960 — https://knowledge.broadcom.com/external/article/426960
- VMware vSphere 8.0 U3 Performance Best Practices — https://www.vmware.com/docs/vsphere-esxi-vcenter-server-80U3-performance-best-practices
