vCenter üzerinde bir ESXi sunucusunun ESXi Host Not Responding durumuna düşmesi, vCenter’ın hostun yönetim servisleriyle iletişim kuramadığını gösterir. Bu durum her zaman sanal makinelerin kapandığı anlamına gelmez: VM’ler çalışmaya devam ederken yalnızca yönetim bağlantısı, envanter güncellemesi veya görev yürütme işlevi kesilmiş olabilir. Ancak ağ kopması, hostd/vpxa ajan kilitlenmesi, depolama gecikmesi, kaynak tükenmesi ya da fiziksel donanım arızası gibi daha ciddi bir olayın belirtisi de olabilir. Bu rehber, ESXi Host Not Responding sorununu VM’lere gereksiz risk oluşturmadan teşhis etmeye, yönetim bağlantısını geri getirmeye ve kalıcı önlemler almaya odaklanır.
Belirti, kapsam ve ilk güvenlik kuralı
vSphere Client’ta host simgesi gri görünebilir, durum alanında Not Responding yazabilir ve envanterdeki VM durumları güncel olmayabilir. vMotion, yeni VM açma, snapshot alma veya yapılandırma değişikliği gibi işlemler başarısız olabilir.
İlk aşamada hostu hemen yeniden başlatmayın. Özellikle VM’lerin gerçekten çalışıp çalışmadığı doğrulanmadan yapılan kontrolsüz yeniden başlatma, çalışan iş yüklerinin kesilmesine ve açık disk yazmalarının risk altına girmesine neden olabilir. Üretim ortamında bakım penceresi, güncel yedek ve mümkünse konsol/iLO, iDRAC, IPMI veya fiziksel erişim hazır olmadan kesintili işlem uygulamayın.
ESXi Host Not Responding için hızlı teşhis özeti
- vCenter’dan değil, ayrı bir yönetim istemcisinden ESXi yönetim IP’sine erişimi test edin.
- Hostun fiziksel konsolundan veya uzaktan donanım konsolundan VM’lerin çalıştığını gözlemleyin.
- Yönetim VMkernel adaptörünün IP, VLAN, fiziksel NIC linki, gateway ve MTU durumunu doğrulayın.
- ESXi Shell veya SSH erişimi varsa
hostd,vpxa, ağ ve çekirdek günlüklerini inceleyin. - Yalnızca yönetim ajanları yanıt vermiyorsa önce kontrollü ajan yeniden başlatmayı değerlendirin.
- Depolama, donanım veya hostun tamamında kilitlenme belirtisi varsa yeniden başlatmadan önce olayın etkisini ve HA davranışını değerlendirin.
| Gözlem | Olası kapsam | İlk yaklaşım |
|---|---|---|
| VM’ler erişilebilir, ESXi arayüzü ve vCenter erişilemez | Yönetim ağı veya yönetim ajanı | vmk0, VLAN, gateway, hostd/vpxa ve günlükleri inceleyin |
| VM’ler çalışıyor, SSH açık fakat vCenter hostu yönetemiyor | vpxa-hostd iletişimi veya vCenter bağlantısı | DNS, saat, sertifika olayları ve ajan günlüklerini kontrol edin |
| VM’lerde de ağ/disk gecikmesi veya kesinti var | Fiziksel NIC, switch, datastore veya host kaynak sorunu | Donanım, uplink, datastore ve vmkernel olaylarını inceleyin |
| Konsol donmuş, ping yok, donanım alarmı mevcut | Host veya donanım kilitlenmesi | Out-of-band konsol ve donanım loglarıyla kontrollü kurtarma planlayın |
Olası nedenler
Yönetim ağı, VLAN veya fiziksel uplink sorunu
En sık senaryoda ESXi çalışır, fakat yönetim VMkernel arayüzü vCenter’a erişemez. Switch portunun kapanması, yanlış VLAN ataması, LACP/teaming uyumsuzluğu, fiziksel NIC link kaybı, gateway sorunu veya hatalı MTU yapılandırması buna yol açabilir. vCenter ve host farklı ağlarda ise yönlendirme ya da güvenlik duvarı değişiklikleri de incelenmelidir.
hostd veya vpxa yönetim ajanlarının yanıt vermemesi
hostd, ESXi hostun yerel yönetim servisidir; vpxa ise vCenter ile iletişim kuran vCenter ajanıdır. Kaynak baskısı, uzun süren API çağrıları, depolama gecikmeleri veya yazılımsal sorunlar bu servislerin zamanında yanıt verememesine neden olabilir. Bu durumda VM’ler çoğu kez çalışmayı sürdürür.
Depolama gecikmesi ve kaynak tükenmesi
Datastore erişiminde kesinti, APD/PDL olayları, çok yüksek disk gecikmesi, bellek baskısı veya CPU kaynaklı yönetim gecikmeleri hostun genel yanıtını etkileyebilir. Bu olaylar yalnızca vCenter bağlantısı olarak görülmemelidir; VM’lerin disk ve uygulama sağlığı ayrıca kontrol edilmelidir.
DNS, saat senkronizasyonu ve vCenter tarafı sorunları
Hostun yönetim IP’si erişilebilir olduğu hâlde yalnızca vCenter bağlantısı kopuyorsa vCenter hizmetleri, DNS ileri/ters kayıtları, host adı çözümlemesi, NTP sapması ve sertifika ile ilgili kayıtlar önem kazanır. Sorunun aynı anda birden fazla hostta görülmesi, ortak switch, DNS, vCenter veya yönetim ağı bileşenlerini öncelikli aday yapar.
Loglar ve güvenli teşhis komutları
Aşağıdaki komutlar ESXi Shell veya etkinleştirilmiş SSH üzerinden çalıştırılır. SSH erişimini yalnızca gerektiği süre açık tutun ve işiniz bittiğinde kapatın. ESXi sürümüne, ağ tasarımına ve yönetim VMkernel adınıza göre vmk0 dışındaki bir arayüzü kullanmanız gerekebilir.
Ağ ve yönetim arayüzünü inceleme
esxcli network nic list
esxcli network ip interface list
esxcli network ip interface ipv4 get
esxcli network ip route ipv4 list
esxcli network ip neighbor list
esxcli network nic list çıktısında yönetim vSwitch veya distributed switch uplink’i olarak kullanılan fiziksel adaptörlerin Up durumunda olması beklenir. IP adresinin doğru VMkernel arayüzünde olduğunu, gateway rotasının bulunduğunu ve VLAN yapılandırmasının switch tarafıyla eşleştiğini kontrol edin.
Hosttan varsayılan ağ geçidine ve vCenter adresine bağlantıyı test edin. ICMP’ye izin verilmemesi tek başına arıza kanıtı değildir; ancak iki yönlü bağlantı sorunları için değerli bir işarettir.
vmkping -I vmk0 <varsayilan_gateway_ip>
vmkping -I vmk0 <vcenter_ip_adresi>
Jumbo frame kullanılıyorsa, yalnızca ilgili ağın uçtan uca 9000 MTU desteklediğinden eminseniz büyük paket testi yapın:
vmkping -I vmk0 -d -s 8972 <hedef_ip_adresi>
Bu test başarısız olursa MTU değerlerini host, fiziksel switch ve hedef uç boyunca karşılaştırın. Yönetim trafiğinde jumbo frame zorunlu değilse, rastgele MTU değişikliği yapmak yerine standartlaştırılmış tasarımı doğrulayın.
Yönetim servisleri ve günlük kayıtları
/etc/init.d/hostd status
/etc/init.d/vpxa status
esxcli system version get
esxcli system uptime get
Son hata satırlarını görmek için günlükleri inceleyin:
tail -n 100 /var/log/hostd.log
tail -n 100 /var/log/vpxa.log
tail -n 100 /var/log/vmkernel.log
tail -n 100 /var/log/syslog.log
hostd.log içinde zaman aşımı, API hatası veya servis yeniden başlama kayıtlarını; vpxa.log içinde vCenter bağlantı ve kimlik doğrulama sorunlarını arayın. vmkernel.log tarafında NIC link değişimi, depolama yolu hatası, APD/PDL, aygıt sıfırlama veya sürücü hataları daha geniş kapsamlı bir problemi gösterebilir.
VM’lerin ve kaynakların durumunu kontrol etme
vim-cmd vmsvc/getallvms
esxcli vm process list
esxcli hardware cpu global get
esxcli hardware memory get
esxcli storage filesystem list
esxcli storage core path list
Bu kontroller hostun kabuk seviyesinde yanıt verip vermediğini, VM süreçlerinin görünürlüğünü ve mount edilmiş dosya sistemlerini anlamaya yardımcı olur. Üretim VM’lerini yalnızca envanter güncel değil diye kapatmayın veya zorla sonlandırmayın.
Adım adım güvenli çözüm
1. Sorunun vCenter mı, host mu olduğunu ayırın
Başka bir hostta aynı alarm var mı kontrol edin. Birden fazla host etkileniyorsa tek tek ESXi yeniden başlatmak yerine vCenter erişimi, yönetim switch’i, DNS ve ortak uplinkleri inceleyin. Yalnızca tek host etkileniyorsa host yönetim IP’sine bağımsız bir istemciden erişmeyi deneyin. Mümkünse ESXi Direct Console User Interface (DCUI) veya out-of-band donanım konsolundan durumu kontrol edin.
2. Yönetim ağını geri getirin
Fiziksel NIC linki kapalıysa kablo, transceiver, switch portu ve port hata sayaçlarını ağ ekibiyle kontrol edin. VLAN değişikliği yapmadan önce mevcut port grubu ve switch yapılandırmasını kaydedin. Yönetim VMkernel IP’si, subnet maskesi ve gateway doğruysa; switch üzerinde ilgili VLAN’ın trunk/erişim kuralını, uplink failover politikasını ve olası port güvenlik kısıtlarını doğrulayın.
3. Sadece ajan sorunu doğrulanırsa hostd ve vpxa’yı yeniden başlatın
Ağ erişimi ve host kabuğu sağlıklı, VM’ler çalışıyor, fakat vCenter bağlantısı geri gelmiyorsa yönetim ajanlarını yeniden başlatmak uygun olabilir. Bu işlem normal koşullarda çalışan VM’leri kapatmaz; buna rağmen vCenter görevleri ve geçici yönetim bağlantıları kesilir. HA, yedekleme, replikasyon veya otomasyon işlemi varsa önce bunların etkisini değerlendirin.
/etc/init.d/hostd restart
/etc/init.d/vpxa restart
İşlemden sonra birkaç dakika bekleyin ve hostd.log ile vpxa.log kayıtlarında başarılı bağlantı işaretlerini kontrol edin. Arayüz yanıt veriyorsa, DCUI üzerinden Restart Management Agents seçeneği de kullanılabilir. Bu seçenek de yönetim bağlantısını keser; çalışma saatlerinde etkisini değerlendirmeden uygulamayın.
4. Depolama veya donanım olayı varsa kök nedeni çözün
vmkernel.log içinde datastore erişim hataları, yol kaybı veya aygıt sıfırlamaları görünüyorsa yönetim ajanını tekrar tekrar başlatmak sorunu çözmez. SAN/NAS erişimi, HBA/NIC sürücü ve firmware uyumluluğu, çoklu yol yapılandırması ve depolama ağını inceleyin. Donanım yönetim arayüzünde bellek, CPU, güç kaynağı, sıcaklık ve disk denetleyicisi alarmlarını kontrol edin.
Host tamamen yanıt vermiyor, DCUI donmuş veya donanım günlükleri ciddi hata gösteriyorsa kontrollü yeniden başlatma gerekebilir. Önce mümkünse çalışan VM’leri sağlıklı hostlara vMotion ile taşıyın. vMotion mümkün değilse iş sürekliliği planı, HA davranışı, uygulama bağımlılıkları ve veri tutarlılığı dikkate alınarak bakım penceresinde işlem yapın.
Çözüm doğrulaması
ESXi Host Not Responding alarmı kaybolduktan sonra yalnızca hostun yeşil görünmesiyle yetinmeyin. Aşağıdaki doğrulamaları yapın:
- vSphere Client’ta host durumu Connected veya normal işletim durumunda görünmelidir.
- Host özeti, performans grafikleri ve VM envanteri güncel zaman damgasıyla yüklenmelidir.
- Yönetim VMkernel arayüzünden gateway ve vCenter erişimi tekrar test edilmelidir.
hostd.logvevpxa.logiçinde tekrarlayan bağlantı kopmaları olmamalıdır.- Datastore’lar erişilebilir olmalı; VM’lerin ağ, disk ve uygulama sağlık kontrolleri ayrı ayrı yapılmalıdır.
Tekrarını önleme
- ESXi, vCenter, NIC/HBA sürücüleri ve firmware sürümlerini VMware uyumluluk gereksinimlerine göre planlı güncelleyin.
- Yönetim ağı için yedekli fiziksel uplink, doğru failover politikası ve belgelenmiş VLAN/MTU standardı kullanın.
- vCenter, ESXi hostlar ve ağ cihazlarında NTP yapılandırmasını izleyin; DNS ileri ve ters kayıtlarını tutarlı tutun.
- vCenter alarmlarında host bağlantı kaybı, NIC link değişimi, datastore gecikmesi ve donanım sağlık olaylarını ayrı eşiklerle takip edin.
- Her host için iLO, iDRAC veya IPMI gibi bant dışı erişimi erişilebilir ve güncel tutun; acil durumda yalnızca vCenter’a bağımlı kalmayın.
Sonuç: ESXi Host Not Responding olayını kök nedenle kapatın
ESXi Host Not Responding hatasında en güvenli yaklaşım, önce VM’lerin gerçek çalışma durumunu korumak, sonra yönetim ağı ile host servislerini birbirinden ayırarak teşhis etmektir. Ağ ve ajan sorunlarında kontrollü düzeltme genellikle yeterlidir; depolama, fiziksel donanım veya host kilitlenmesi belirtilerinde ise yeniden başlatma kararını kök neden, HA tasarımı ve bakım planıyla birlikte vermek gerekir. Olay sonrası logları saklamak, tekrar eden belirtileri yakalamak için önemlidir.
Sık sorulan sorular
ESXi Host Not Responding hatasında sanal makineler kapanır mı?
Hayır, zorunlu olarak kapanmaz. Bu alarm çoğunlukla vCenter ile host yönetim bağlantısının kesildiğini anlatır. VM’ler host üzerinde çalışmayı sürdürebilir; ancak bunu konsol, uygulama izleme veya ağ erişimiyle doğrulamak gerekir.
hostd ve vpxa yeniden başlatmak VM’leri etkiler mi?
Normal koşullarda VM’ler çalışmaya devam eder. Buna karşılık vCenter yönetimi, görevler, envanter güncellemesi ve bazı otomasyonlar geçici olarak kesilir. Üretim ortamında aktif bakım, yedekleme veya taşıma işlemlerini önce kontrol edin.
Host ping’e yanıt veriyor ama vCenter’da Not Responding görünüyor; neden?
IP erişimi çalışsa bile hostd veya vpxa servisi yanıt vermiyor olabilir. DNS, saat sapması, vCenter iletişimi, sertifika sorunları ya da host kaynak baskısı da bu görünüme yol açabilir. hostd.log ve vpxa.log incelemesi gerekir.
Not Responding olan hostu vCenter’dan Remove edip tekrar eklemek çözüm müdür?
Genellikle ilk çözüm değildir. Ağ veya ajan problemi sürüyorsa hostu tekrar eklemek kalıcı sonuç vermez ve yapılandırma takibini zorlaştırabilir. Önce bağlantı, günlükler ve yönetim servisleri incelenmelidir.
Hostu ne zaman yeniden başlatmalıyım?
Yönetim ağı, ajanlar ve vCenter tarafı kontrol edildiği hâlde host tamamen yanıt vermiyorsa; DCUI/konsol kilitlenmişse veya donanım/çekirdek sorunu doğrulanmışsa planlı yeniden başlatma değerlendirilir. Öncesinde VM taşıma olanağı, HA etkisi, yedekler ve bakım penceresi mutlaka gözden geçirilmelidir.
