ESXi Host Not Responding: vCenter Bağlantısı Kesildiğinde Güvenli Teşhis ve Kurtarma

ESXi host not responding uyarısı, vCenter Server’ın bir ESXi ana makinesiyle yönetim iletişimini kaybettiğini gösterir. Bu durum her zaman fiziksel sunucunun kapandığı veya sanal makinelerin durduğu anlamına gelmez: VM’ler çalışmayı sürdürürken yalnızca vCenter envanterinden yönetilemez hâle gelebilir. Ancak yönetim ağı kesintisi, kilitlenmiş yönetim ajanları, datastore erişim sorunu veya gerçek bir donanım arızası da aynı uyarıyı oluşturabilir. Bu rehber, etki alanını ayırmayı; ağ, hostd/vpxa, depolama ve vCenter katmanlarını güvenli sırayla incelemeyi; ardından en düşük riskli kurtarma adımını uygulamayı açıklar.

Belirti ve kapsam: Uyarının gerçek etkisini belirleyin

vSphere Client içinde host bağlantı durumu Not Responding görünür. Konuk işletim sistemleri erişilebilir olabilir, yeni VM işlemleri başarısız olabilir veya host üzerindeki performans metrikleri güncellenmeyebilir. Önce aşağıdaki ayrımı yapın:

• Yalnızca tek host etkileniyorsa: Yönetim VMkernel ağı, fiziksel NIC, switch portu, host ajanları veya hosta bağlı depolama önceliklidir.
• Birden çok host aynı anda etkileniyorsa: vCenter Server, ortak yönetim VLAN’ı, DNS, ağ geçidi, fiziksel switch ya da güvenlik duvarı değişikliklerini inceleyin.
• VM’ler çalışıyor ancak vCenter erişemiyorsa: Konuk trafiği ile yönetim trafiği farklı ağlardaysa problem yalnızca yönetim düzleminde olabilir.
• VM’ler de erişilemiyorsa: Hostun fiziksel sağlık durumu, uplink’ler, datastore ve ağ altyapısı için olay yönetimi başlatın.

ESXi Host Not Responding için hızlı teşhis özeti

Değişiklik yapmadan önce bu kontrol listesini tamamlayın. Amaç, gereksiz host yeniden başlatma riskini ortadan kaldırmaktır.

1. vCenter alarm zamanını, son ağ/depolama değişikliklerini ve diğer hostların durumunu karşılaştırın.
2. Yönetim IP’sine izleme sisteminden veya aynı VLAN’daki güvenilir bir noktadan erişimi test edin.
3. Doğrudan ESXi Host Client erişimini deneyin: https://ESXi-YONETIM-IP/ui.
4. Mümkünse iDRAC, iLO, IPMI veya fiziksel konsoldan DCUI ekranını açın; ekranın yanıt verip vermediğini kontrol edin.
5. Host erişilebiliyorsa önce ağ ve logları toplayın; ardından yalnızca yönetim ajanlarını yeniden başlatın.
6. Hosta erişim yoksa fiziksel konsol, ağ anahtarı ve donanım olay kayıtlarına yönelin.

Gözlem	Olası katman	İlk güvenli işlem
Host Client açılıyor, vCenter hostu kırmızı gösteriyor	vpxa, vCenter-host iletişimi	vpxa/hostd loglarını inceleyin
Yönetim IP’sine ping ve HTTPS yok, DCUI çalışıyor	VMkernel ağ yapılandırması veya uplink	vmk0, NIC ve switch/VLAN kontrolleri
Birden çok host aynı anda Not Responding	vCenter veya ortak ağ	vCenter servisleri ve ortak ağ kontrolleri
DCUI ve uzaktan yönetim konsolu da yanıt vermiyor	Host kilitlenmesi veya donanım	Donanım olay günlükleri ve kontrollü yeniden başlatma planı
Loglarda APD/PDL ya da path kaybı	SAN/NAS veya datastore erişimi	Depolama ekibiyle path ve fabric kontrolleri

Olası nedenler

Yönetim ağı ve fiziksel uplink sorunları

Yanlış VLAN ataması, switch portunun kapanması, LACP veya NIC teaming uyumsuzluğu, MTU farkı ve hatalı statik rota; vCenter ile ESXi arasındaki yönetim trafiğini kesebilir. Özellikle switch, dağıtık switch veya güvenlik duvarı değişikliğinin hata saatine denk gelmesi güçlü bir göstergedir.

hostd ve vpxa yönetim ajanlarının yanıt vermemesi

hostd, Host Client ve yerel yönetim işlemlerini; vpxa ise ESXi ile vCenter arasındaki iletişimi yürütür. VM’ler çalışırken bu süreçlerin takılması, hostun vCenter’da yanıt vermiyor görünmesine yol açabilir. Ajanı yeniden başlatmak çoğu zaman VM’leri kapatmaz; buna rağmen aktif yönetim işleri ve anlık envanter sorguları kesintiye uğrayabilir.

Depolama erişim gecikmesi veya kaybı

iSCSI, Fibre Channel, NFS ya da vVol altyapısındaki yol kayıpları host yönetimini yavaşlatabilir. All Paths Down (APD) veya Permanent Device Loss (PDL) kayıtları varken sorunu yalnızca ajan yeniden başlatarak çözmeye çalışmayın. Önce datastore erişimini ve storage fabric durumunu doğrulayın.

Kaynak tükenmesi, donanım veya vCenter tarafı sorunları

Aşırı CPU bellek baskısı, sürücü/firmware uyumsuzluğu, fiziksel NIC hatası, disk denetleyicisi uyarısı veya vCenter servis sorunu da aynı belirtiyi doğurabilir. Birden fazla host aynı anda etkilenmişse tek tek ESXi hostlarını yeniden başlatmak yerine ortak bağımlılıkları inceleyin.

Log toplama ve komutlarla teşhis

SSH erişimi varsayılan olarak kapalı olabilir. Erişimi yalnızca bakım süresince, yetkili yönetim ağından açın ve işlem sonrasında tekrar kapatın. Komutlar ESXi Shell veya SSH oturumunda uygulanır. SSH açmak mümkün değilse DCUI üzerinden ağ ayarlarını ve Restart Management Agents seçeneğini kullanabilirsiniz.

Önce VMkernel arayüzleri, fiziksel NIC’ler ve rota durumunu görüntüleyin:

esxcli network ip interface ipv4 get
esxcli network nic list
esxcli network ip route ipv4 list
vmkping -I vmk0 YONETIM_AG_GECIDI

vmk0 örnektir. Ortamınızda yönetim trafiği başka bir VMkernel adaptöründeyse doğru vmkX değerini kullanın. Ağ geçidine ping başarılıyken vCenter’a erişim yoksa DNS, güvenlik duvarı, rota veya vCenter tarafını değerlendirin. Hosttan vCenter yönetim IP’sine test için:

vmkping -I vmk0 VCENTER_YONETIM_IP

Yönetim ve depolama günlüklerinin son kayıtlarını inceleyin:

tail -n 200 /var/log/hostd.log
tail -n 200 /var/log/vpxa.log
tail -n 200 /var/log/vmkernel.log
tail -n 200 /var/log/vmkwarning.log

hostd.log ve vpxa.log içinde bağlantı, kimlik doğrulama veya servis hatalarını; vmkernel.log içinde NIC link değişimi, APD/PDL, NFS ya da iSCSI zaman aşımı kayıtlarını arayın. Depolama görünümünü de doğrulayın:

esxcli storage filesystem list
esxcli storage core path list
esxcli storage core device list

Uzun çıktıları yalnızca gerekli ekiplerle, IP adresi ve altyapı ayrıntılarını koruyacak şekilde paylaşın. Destek kaydı için VMware destek paketi gerekirse, host erişilebilir durumdayken vm-support aracıyla paket oluşturulabilir; paketin disk alanı ve hassas yapılandırma bilgileri içerebileceğini unutmayın.

Güvenli adım adım çözüm

1. Ağ ve vCenter erişimini düzeltin

Yönetim IP’si erişilemiyorsa DCUI’da Configure Management Network bölümünden fiziksel adaptör, VLAN, IPv4 adresi, ağ geçidi ve DNS değerlerini mevcut ağ tasarımıyla karşılaştırın. Aktif bağlantıların bulunduğu üretim hostunda ağ ayarını deneme-yanılma ile değiştirmeyin. Switch tarafında ilgili portun link, VLAN ve hata sayaçlarını ağ ekibiyle kontrol edin.

Birden çok host etkilenmişse vCenter Server Appliance üzerinde vCenter servis durumunu inceleyin. Bu komut, VCSA kabuğunda ve gerekli yetkiyle çalıştırılmalıdır:

service-control --status vmware-vpxd

vmware-vpxd kapalıysa, yeniden başlatmadan önce appliance kaynakları, sertifika/kimlik doğrulama olayları ve servis günlükleri değerlendirilmelidir. vCenter servisini rastgele yeniden başlatmak, aynı anda süren yönetim görevlerini kesintiye uğratabilir.

2. Yönetim ajanlarını kontrollü olarak yeniden başlatın

Hosta SSH, ESXi Shell veya DCUI ile erişebiliyor; VM’lerin çalıştığını ve depolama tarafında kritik hata bulunmadığını doğruluyorsanız önce en düşük etkili kurtarma seçeneğini uygulayın. DCUI’da Troubleshooting Options > Restart Management Agents yolunu tercih edebilirsiniz.

Komut satırında süreçleri sırayla yeniden başlatın:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

Bu işlem ESXi hostunu veya çalışan VM’leri yeniden başlatmaz. Yine de geçici yönetim bağlantısı kesintisi yaşanır. Anlık vMotion, yedekleme, snapshot birleştirme ya da konfigürasyon değişikliği sürüyorsa uygun bakım penceresini bekleyin. Tüm ESXi servislerini topluca yeniden başlatan komutları rutin çözüm olarak kullanmayın; etki alanı daha geniş olabilir.

3. Depolama hatası varsa önce altyapıyı onarın

Loglarda APD/PDL, NFS bağlantı kopması veya iSCSI oturum sorunu görülürse LUN’u yeniden taramak ya da hostu yeniden başlatmak veri tutarlılığı riskini tek başına çözmez. SAN switch, HBA, iSCSI VLAN, NAS erişimi ve datastore kapasitesi incelenmelidir. Etkilenen VM’lerde uygulama sahipleriyle birlikte tutarlılık kontrolü planlayın.

4. Host yeniden başlatmayı son seçenek yapın

DCUI yanıt vermiyor, uzaktan yönetim konsolu kilitlenmiş veya donanım günlükleri kritik hata gösteriyorsa yeniden başlatma gerekebilir. Bu işlem çalışan VM’leri durdurabilir ve veri kaybına neden olabilir. Öncesinde geçerli yedekleri doğrulayın, mümkünse erişilebilir VM’leri başka bir hosta vMotion ile taşıyın, bakım penceresi açın ve uygulama sahiplerini bilgilendirin. HA davranışının küme ayarlarına göre değişeceğini unutmayın.

Çözümü doğrulama

Ajan veya ağ düzeltmesinden sonra vSphere Client’ta host durumunun Connected olduğunu, alarmın temizlendiğini ve envanter verilerinin güncellendiğini doğrulayın. Ardından aşağıdaki kontrolleri yapın:

• Host Client’a HTTPS ile doğrudan erişim sağlanıyor mu?
• Yönetim ağ geçidi ve vCenter IP’sine doğru VMkernel arayüzünden ping başarılı mı?
• Tüm gerekli datastore’lar bağlı ve erişilebilir mi?
• hostd.log ile vpxa.log içinde tekrarlayan bağlantı hatası devam ediyor mu?
• VM durumları, ağ erişimi ve varsa yedekleme işleri beklenen şekilde çalışıyor mu?

Tekrarını önleme

Yönetim ağını konuk trafiğinden mantıksal olarak ayırın, fiziksel uplink yedekliliğini test edin ve switch tarafındaki VLAN/MTU standardını belgelendirin. ESXi sürümüyle uyumlu NIC, HBA ve depolama firmware/sürücü kombinasyonlarını üretici uyumluluk matrisine göre yönetin. vCenter, ESXi, switch ve storage alarmlarını merkezi izleme sisteminde korele edin. Ayrıca vCenter yapılandırması ve kritik VM’ler için geri yüklenebilir yedeklerin düzenli testini yapın.

Sonuç

ESXi host not responding olayı, çoğu zaman hostun tamamen kapandığını değil, vCenter ile yönetim iletişiminin bozulduğunu ifade eder. Önce kapsamı belirlemek, ağ ve depolama kanıtlarını toplamak, sonra yalnızca gerekli yönetim ajanını yeniden başlatmak güvenli yaklaşımı oluşturur. Host yeniden başlatma ise VM kesintisi ve veri tutarlılığı riski nedeniyle ancak doğrulanmış bir bakım planının son adımı olmalıdır.

Sık sorulan sorular

ESXi host Not Responding iken sanal makineler çalışmaya devam eder mi?

Evet. Sorun yalnızca vCenter ile host arasındaki yönetim bağlantısındaysa VM’ler çalışmaya devam edebilir. Kesin durum için VM ağ erişimini, host konsolunu ve datastore sağlığını ayrıca kontrol edin.

hostd ve vpxa yeniden başlatmak VM’leri kapatır mı?

Normal koşullarda kapatmaz. Ancak host yönetimi geçici olarak kesilir; devam eden yönetim görevleri etkilenebilir. Üretim ortamında işlem öncesi aktif görevleri kontrol edin.

Yalnızca bir host etkileniyorsa vCenter’ı yeniden başlatmalı mıyım?

Hayır. Öncelikle ilgili hostun yönetim ağı, fiziksel uplink’i, hostd/vpxa günlükleri ve datastore bağlantısını inceleyin. vCenter yeniden başlatma, tek-host sorununda ilk çözüm değildir.

ESXi yönetim IP’sine ping var ama Host Client açılmıyor; neden?

Ağ katmanı erişilebilir olsa bile HTTPS hizmeti veya hostd yanıt vermiyor olabilir. Host konsolundan günlükleri inceleyin ve depolama kaynaklı gecikme olmadığını doğruladıktan sonra yönetim ajanlarını yeniden başlatın.

APD veya PDL kaydı gördüğümde ne yapmalıyım?

Bu kayıtlar depolama erişim sorununa işaret eder. Hostu veya ajanları tekrar tekrar yeniden başlatmak yerine SAN/NAS, ağ yolu, HBA ve datastore tarafını inceleyin; kritik VM’ler için uygulama tutarlılığı değerlendirmesi yapın.