ESXi Host Not Responding: Hostd ve VPXA Yönetim Ajanlarını Güvenle Kurtarma

ESXi Host Not Responding uyarısı, vCenter Server’ın ESXi ana makinesiyle yönetim iletişimini kaybettiğini gösterir. Bu durum her zaman sanal makinelerin kapandığı anlamına gelmez: VM’ler çalışmaya ve ağ trafiği üretmeye devam ederken yalnızca vCenter yönetimi, görev takibi ve alarm görünürlüğü kesilmiş olabilir. Ancak depolama erişimi, fiziksel ağ veya ana makine kaynak kilitlenmesi de aynı uyarıya neden olabileceğinden, rastgele yeniden başlatma yapmak risklidir. Bu rehber, önce erişimin ve çalışan VM’lerin durumunu koruyarak sorunun yönetim ağı mı, hostd/vpxa ajanları mı, datastore gecikmesi mi yoksa donanım sorunu mu olduğunu ayırmayı ve uygun kurtarma adımını uygulamayı açıklar.

Belirti, kapsam ve ilk güvenlik sınırı

vSphere Client üzerinde hostun durumu Not Responding görünür; envanter yenilenmez, konsol açma veya VM taşıma görevleri zaman aşımına düşebilir. Buna rağmen VM’lerin işletim sistemi içinden erişilebilir olması, hostun tamamen kapandığını kanıtlamaz; çoğu kez veri düzlemi çalışırken yönetim düzlemi etkilenmiştir.

İlk amaç hostu yeniden başlatmak değil, çalışan iş yüklerini ve depolama bütünlüğünü korumaktır. Özellikle üretim VM’lerinde açık disk yazmaları, snapshot işlemleri veya yoğun veri tabanı yükü varsa bakım penceresi olmadan host reboot işlemi planlamayın.

Hızlı teşhis kontrol listesi

• VM’lere uygulama veya işletim sistemi seviyesinde erişim sürüyor mu?
• vCenter’dan değil, yönetim ağındaki başka bir sistemden hostun yönetim IP’sine erişilebiliyor mu?
• HTTPS yönetim arayüzü https://ESXI_YONETIM_IPSI/ui açılıyor mu?
• DCUI, iDRAC, iLO, IPMI veya fiziksel konsol erişimi var mı?
• Başka hostlarda aynı anda bağlantı sorunu oluştu mu? Oluştuysa ortak switch, VLAN, DNS, vCenter veya uplink katmanını önceleyin.
• Datastore erişiminde gecikme, APD/PDL veya yol hatası belirtileri bulunuyor mu?

ESXi Host Not Responding için olası nedenler

Katman	Tipik bulgu	İlk yaklaşım
Yönetim ağı	Ping, HTTPS veya TCP 443 erişimi yok; vmnic linki düşmüş olabilir.	VLAN, vmk0, uplink, fiziksel switch portu ve MTU yapılandırmasını inceleyin.
hostd / vpxa	VM’ler çalışır, ancak Host Client veya vCenter envanteri yanıt vermez.	Logları inceleyin; uygun olduğunda yalnız yönetim ajanlarını yeniden başlatın.
vCenter bağlantısı	Host Client erişilebilir, yalnız vCenter hostu yanıt vermiyor gösterir.	DNS, saat eşitlemesi, sertifika ve vCenter servis/erişim durumunu değerlendirin.
Depolama	Yüksek gecikme, I/O hata mesajları, datastore görünmezliği veya takılan görevler.	HBA, SAN/NAS, ağ depolaması ve path durumunu inceleyin; reboot ile gizlemeyin.
Kaynak / donanım	DCUI yavaş veya yanıtsız, donanım olayları ya da bellek/CPU baskısı.	Out-of-band yönetim logları ve fiziksel donanım uyarılarını kontrol edin.

Önce erişimi ayırın: ağ mı, yalnızca vCenter mı?

Yönetim VLAN’ında bulunan bir Linux veya Windows yönetim sunucusundan temel erişimi test edin. ICMP’nin güvenlik politikasıyla engellenebileceğini unutmayın; HTTPS testi daha anlamlıdır.

ping -c 4 ESXI_YONETIM_IPSI
curl -k -I --connect-timeout 5 https://ESXI_YONETIM_IPSI/ui/

Windows PowerShell ortamında:

Test-Connection ESXI_YONETIM_IPSI -Count 4
Test-NetConnection ESXI_YONETIM_IPSI -Port 443

TCP 443 açık ve Host Client çalışıyorsa, sorun vCenter bağlantısı veya vpxa ajanı tarafında olabilir. Host Client da açılamıyorsa ancak VM’ler erişilebiliyorsa, yönetim VMkernel arayüzü ya da hostd önceliklidir. Ağ erişimi tamamen kayıpsa DCUI veya out-of-band konsola geçin; SSH erişiminin önceden açık olduğunu varsaymayın.

Log ve komutlarla güvenli teşhis

ESXi Shell veya SSH ile erişiminiz varsa, önce mevcut durumu kaydedin. ESXi sürümüne, güvenlik politikasına ve kurumsal erişim standardınıza göre SSH kapalı olabilir. Mümkünse geçici erişimi yalnız DCUI üzerinden açın ve işlem sonunda yeniden kapatın.

Ağ ve yönetim arayüzü durumunu kontrol edin

esxcli network ip interface list
esxcli network ip interface ipv4 get
esxcli network nic list
esxcli network nic stats get -n vmnic0

vmnic0 yalnız örnektir; yönetim trafiğini taşıyan fiziksel adaptör adını önce esxcli network nic list çıktısından belirleyin. Yönetim VMkernel arayüzünde doğru IP, VLAN ve bağlantı yolu yoksa ajan restart etmek sorunu çözmez.

Yönetim ajanı ve sistem günlüklerini inceleyin

ESXi günlükleri döngüsel olabilir. Sorun yaşanırken ilgili satırları mümkün olduğunca erken toplayın. Kalıcı uzak syslog yapılandırması yoksa reboot sonrasında önemli kanıtlar kaybolabilir.

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/vobd.log

hostd.log içindeki bağlantı havuzu, görev zaman aşımı veya bellek baskısı kayıtları yönetim servisinin durumunu; vpxa.log vCenter ajanının bağlantısını gösterir. vmkernel.log içindeki depolama yolu, ağ sürücüsü veya aygıt hataları ise daha derin bir altyapı sorununa işaret edebilir.

Depolama kaynaklı kilitlenme olasılığını dışlayın

esxcli storage filesystem list
esxcli storage core path list
esxcli storage core device stats get

Path durumlarının beklenmedik biçimde dead veya off olması, datastore’ların erişilemez görünmesi ya da günlüklerde APD/PDL mesajları görülmesi halinde depolama ekibiyle birlikte ilerleyin. Bu koşulda yönetim ajanlarını yeniden başlatmak geçici erişim sağlayabilir, fakat kök nedeni ve VM I/O riskini ortadan kaldırmaz.

Güvenli çözüm sırası: en az etkili işlemden başlayın

1. vCenter tarafını ve doğrudan host erişimini karşılaştırın

Host Client açılıyor, VM’ler çalışıyor ve yalnız vCenter hostu Not Responding gösteriyorsa vCenter’ın hosta ağ erişimini, isim çözümlemesini ve zaman eşitlemesini inceleyin. Hostu envanterden kaldırmak, yeniden eklemek veya bağlantıyı zorla kesmek ilk adım olmamalıdır; mevcut görev geçmişini ve alarm bağlamını gereksiz yere karmaşıklaştırabilir.

2. DCUI üzerinden yönetim ajanlarını yeniden başlatın

VM’ler çalışıyor, hostun DCUI ekranı erişilebilir ve ağ/depoda kritik hata bulgusu yoksa tercih edilen yöntem DCUI’de Troubleshooting Options > Restart Management Agents seçeneğidir. Bu işlem ESXi yönetim ajanlarını yeniden başlatır; normal koşullarda çalışan VM’leri kapatmaz. Buna karşın aktif vCenter görevleri, Host Client oturumları ve bazı yönetim işlemleri kesilebilir.

İşlemden önce mümkünse çalışan görev olmadığını doğrulayın ve ekip üyelerini bilgilendirin. Ajanlar geri geldikten sonra vCenter’ın host durumunu yenilemesi birkaç dakika alabilir.

3. Sadece SSH erişimi varsa ajan durumunu kontrollü yönetin

DCUI kullanılamıyor, ancak ESXi Shell/SSH erişimi varsa önce servis durumunu gözlemleyin:

/etc/init.d/hostd status
/etc/init.d/vpxa status

Loglar yönetim ajanında takılmayı gösteriyor ve depolama ya da donanım kaynaklı host kilitlenmesi bulgusu yoksa, sıralı yeniden başlatma uygulanabilir:

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

Bu komutlar yalnızca ESXi yönetim servislerini hedefler. Tüm servisleri topluca yeniden başlatan geniş kapsamlı komutlar kullanmayın; bunlar ortamın ihtiyacına göre daha fazla yönetim bileşenini etkileyebilir. Komutlar başarısız oluyor, kabuk gecikmeli yanıt veriyor veya günlükler I/O hatalarıyla doluyorsa sorunu zorlamayın; fiziksel konsol ve depolama/donanım incelemesine geçin.

4. Host yeniden başlatmayı yalnız kontrollü bakımda uygulayın

Host reboot, son çaredir. Önce vMotion/DRS ile VM’leri sağlıklı hostlara taşıyın. Bu mümkün değilse planlı kesinti, uygulama sahiplerinin onayı ve güncel yedek ya da kurtarma planı olmadan yeniden başlatma yapmayın. Bakım moduna alma işlemi, host üzerinde çalışan VM’leri kendiliğinden güvenle taşımaz; DRS yapılandırmasına ve uyumluluğa bağlıdır.

Host erişilebilir hale geldiğinde bakım modu ve tahliye tamamlandıktan sonra, kurumunuzun onaylı yöntemleriyle yeniden başlatma yapılabilir. Fiziksel konsol tamamen donmuşsa yalnız out-of-band denetleyici üzerinden yapılan güç işlemi kalabilir; bu işlem ani kesinti yaratabileceğinden VM ve dosya sistemi bütünlüğü açısından en yüksek riskli seçenektir.

Çözüm sonrası doğrulama

Ajan restart veya altyapı düzeltmesinden sonra sadece vCenter’daki yeşil simgeyle yetinmeyin. Aşağıdaki kontrolleri birlikte yapın:

• Host, vCenter’da Connected durumuna döndü mü ve envanter yenileniyor mu?
• Host Client üzerinden görevler, alarmlar ve VM listesi gecikmeden açılıyor mu?
• Yönetim IP’sinde HTTPS/443 erişimi kararlı mı?
• Datastore’lar görünür mü; storage path durumları sağlıklı mı?
• VM’lerin uygulama sağlık kontrolleri, ağ erişimi ve kritik servisleri normal mi?
• hostd.log, vpxa.log ve vmkernel.log içinde hata tekrar ediyor mu?

Sorun düzelse bile olay zaman aralığındaki switch, SAN/NAS ve vCenter kayıtlarını saklayın. Tekrarlayan kesintilerde bu kayıtlar, anlık ajan restart işleminden çok kök neden analizini hızlandırır.

ESXi Host Not Responding tekrarını önleme

• ESXi yönetim trafiğini iş yükü trafiğinden uygun VLAN ve fiziksel yedeklilik tasarımıyla ayırın.
• Host, vCenter, DNS ve ağ cihazlarında zaman eşitlemesini düzenli kontrol edin.
• ESXi loglarını merkezi syslog platformuna yönlendirin; yerel döngüsel loglara bağımlı kalmayın.
• Firmware, NIC/HBA sürücüsü ve ESXi sürümünü donanım üreticisinin uyumluluk matrisiyle planlı biçimde güncelleyin.
• Datastore gecikmesi, path kaybı, NIC hata sayacı ve yönetim ağı erişimi için izleme/alarm eşikleri oluşturun.

Sonuç

ESXi Host Not Responding hatasında en güvenli yaklaşım, VM’lerin gerçek çalışma durumunu belirlemek, yönetim ağı ile depolama/donanım bulgularını ayırmak ve yalnızca gerektiğinde hostd ile vpxa ajanlarını yeniden başlatmaktır. Host reboot işlemi, erişim ve günlükler değerlendirildikten, iş yükleri güvenli biçimde tahliye edildikten sonra uygulanmalıdır. Böylece kısa süreli vCenter bağlantı kaybını, veri ve hizmet kesintisi riski taşıyan daha büyük bir olaya dönüştürmeden yönetebilirsiniz.

Sık sorulan sorular

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

Evet. Uyarı çoğunlukla vCenter ile ESXi yönetim iletişiminin kesildiğini ifade eder. VM’lerin durumunu uygulama erişimi, izleme sistemi ve doğrudan host erişimiyle ayrıca doğrulamak gerekir.

Restart Management Agents çalışan VM’leri kapatır mı?

Normalde hayır; işlem yönetim ajanlarını hedefler. Ancak vCenter görevleri, Host Client oturumları ve geçici yönetim işlemleri etkilenebilir. Depolama veya host kilitlenmesi varsa işlem kök nedeni çözmeyebilir.

Hostu vCenter envanterinden kaldırıp tekrar eklemek çözüm müdür?

İlk çözüm değildir. Önce ağ erişimi, Host Client, hostd/vpxa logları ve vCenter bağlantısı incelenmelidir. Envanter işlemleri sorunun nedenini gizleyebilir veya yönetim bağlamını karmaşıklaştırabilir.

Ping yanıt vermiyor ama Host Client açılıyor; bu normal mi?

Evet. ICMP trafiği güvenlik duvarı veya ağ politikasıyla engellenmiş olabilir. HTTPS üzerinden TCP 443 erişimi ve Host Client yanıtı, yönetim erişimi için daha anlamlı göstergelerdir.

APD veya PDL kaydı varsa yönetim ajanlarını yeniden başlatmalı mıyım?

Önce depolama erişim sorununu ele alın. APD/PDL, datastore veya yol erişim problemine işaret edebilir; ajan restart işlemi yalnızca yönetim belirtisini geçici olarak değiştirebilir ve asıl I/O riskini ortadan kaldırmaz.