VMware vSphere altyapılarında sanal makinelerin kesintisiz taşınabilmesi, ESXi hostlarının merkezi olarak yönetilebilmesi ve ağ yapılandırmalarının tutarlı şekilde çalışabilmesi için sunucu, ağ ve depolama bileşenlerinin birbiriyle sağlıklı iletişim kurması gerekir.
Bu bileşenlerden herhangi birinde meydana gelen performans düşüklüğü veya erişim problemi, ilk bakışta farklı bir altyapı katmanından kaynaklanıyormuş gibi görünen hatalara neden olabilir.
Özellikle depolama altyapısında yaşanan yüksek I/O gecikmeleri (Storage Latency) veya bağlantı problemleri, ESXi yönetim servislerinin yanıt vermemesine ve vSphere Distributed Switch (vDS) yapılandırmasının vCenter Server ile senkronizasyonunu kaybetmesine yol açabilir.
Böyle bir durumda sanal makinelerin vMotion ile taşınması başarısız olabilir, Distributed Port Group işlemleri tamamlanamayabilir veya ESXi hostları vDS üzerinde Out of Sync durumuna geçebilir.
Bu makalemde VMware ESXi 8.0 üzerinde karşılaşılabilecek bu sorunun belirtilerini, olası nedenlerini, log analizini ve güvenli çözüm yöntemlerini adım adım inceleyeceğiz.
Sorunun Belirtileri
Sorun genellikle vCenter Server üzerinden gerçekleştirilen ağ yönetimi işlemleri veya sanal makine taşıma operasyonları sırasında ortaya çıkar.
Etkilenen ESXi hostunda aşağıdaki belirtilerden biri veya birkaçı görülebilir:
- Sanal makinelerin vMotion işlemleri başarısız olur.
- Distributed Port Group oluşturma veya güncelleme işlemleri tamamlanamaz.
- vSphere Distributed Switch yapılandırması Out of Sync durumuna geçebilir.
- ESXi hostu vCenter Server üzerinde yanıt vermeyebilir veya bağlantı problemleri yaşayabilir.
hostdvevpxayönetim servisleri durmuş ya da yanıt veremez duruma gelmiş olabilir.
Bu sorun sırasında vSphere Client üzerinde aşağıdakine benzer bir hata görüntülenebilir;
A general system error occurred: DVS error
Cannot create Distributed Port Group dvportgroup-#### of VDS [VDS-NAME] on the host [HOST-NAME]
Cannot complete a vSphere Distributed Switch operation for one or more host members.Bu hata mesajı vCenter Server tarafından başlatılan Distributed Switch işleminin ilgili ESXi hostunda tamamlanamadığını gösterir.
Ancak önemli bir noktaya dikkat edilmelidir: DVS hata mesajının görüntülenmesi, sorunun mutlaka ağ altyapısından kaynaklandığı anlamına gelmez.
Asıl neden, depolama altyapısındaki erişim veya performans sorunlarının ESXi yönetim servislerini etkilemesi olabilir.
Sorunun Temel Nedeni: Storage Latency ve Yönetim Servisleri
VMware ESXi, sanal makinelerin çalıştırılmasının yanı sıra ağ, depolama ve host yönetimi için çeşitli servislerden yararlanır.
Bu servislerden özellikle ikisi, vCenter Server ile ESXi arasındaki yönetim iletişiminde kritik rol oynar.
hostd (Host Management Service)
ESXi hostunun yerel yönetim işlemlerinden sorumludur. Sanal makine yönetimi, yapılandırma değişiklikleri ve host yönetim taleplerini işler.
vpxa (vCenter Server Agent)
ESXi hostu ile vCenter Server arasındaki yönetim iletişimini sağlar. vCenter üzerinden gönderilen işlemlerin host tarafında yürütülmesinde görev alır.
Normal koşullarda bu servisler birlikte çalışarak vCenter Server ile ESXi yapılandırmalarının tutarlı kalmasını sağlar.
Ancak depolama sisteminde ciddi I/O gecikmeleri veya erişim hataları oluştuğunda, ESXi üzerindeki bazı yönetim işlemleri beklemeye girebilir.
Örneğin, depolama yanıt sürelerinin birkaç yüz milisaniyeye ulaşması, özellikle yoğun I/O altında yönetim işlemlerinin tamamlanmasını geciktirebilir.
VMware Distributed Switch yapılandırmasına ait bazı meta veriler datastore üzerindeki .dvsData dizininde tutulur.
hostd servisinin bu dizine erişmesi veya gerekli meta veri işlemlerini tamamlaması engellenirse servis yanıt veremez duruma gelebilir.
Bunun sonucunda vCenter Server ile ESXi arasındaki vDS yapılandırması tutarsız hale gelebilir.
Sorunun oluşum süreci genel olarak şu şekilde açıklanabilir:
Storage Latency / Storage I/O Failure → hostd işlemlerinde gecikme veya yanıt vermeme → vCenter yönetim iletişiminde sorun → vDS senkronizasyon hatası → vMotion veya Port Group işlemlerinde başarısızlık
Bu ilişki, ağ tarafında görülen hatanın gerçekte depolama altyapısındaki bir problemden kaynaklanabileceğini göstermesi açısından önemlidir.
ESXi VMkernel Loglarının İncelenmesi
Sorunun temel nedenini belirlemek için ilk incelenmesi gereken kaynaklardan biri ESXi VMkernel loglarıdır.
VMkernel, depolama aygıtları, fiziksel donanım ve düşük seviyeli I/O işlemleriyle ilgili önemli hata kayıtları oluşturur.
ESXi hostuna SSH üzerinden bağlanarak aşağıdaki log dosyası incelenebilir;
/var/run/log/vmkernel.logİlgili depolama hatalarını filtrelemek için;
grep -i "ScsiDeviceIO" /var/run/log/vmkernel.logPaylaşılan örnekte, VMkernel loglarında aşağıdaki hata bilgileri görülmektedir;
ScsiDeviceIO: 4697: Cmd(0x...) 0x28 ... failed
H:0x0 D:0x2 P:0x0 Valid sense data: 0x4 0x84 0x0Bu kayıtlar VMware ESXi tarafından bir depolama aygıtına gönderilen SCSI komutunun başarısız olduğunu göstermektedir.
Log satırlarında yer alan bazı alanların anlamı şöyledir:
| Parametre | Açıklama |
|---|---|
ScsiDeviceIO | Depolama aygıtı üzerindeki SCSI I/O işlemlerine ilişkin log kaydı |
Cmd 0x28 | SCSI READ(10) komutu |
H:0x0 | Host seviyesinde hata raporlanmadığını gösterir |
D:0x2 | SCSI Check Condition durumunu ifade eder |
P:0x0 | Plugin seviyesinde hata raporlanmadığını gösterir |
Sense 0x4 | SCSI Hardware Error sense key |
0x84 0x0 | Ek sense kodları; cihaz ve üretici bilgileriyle birlikte değerlendirilmelidir |
Bu örnekte özellikle D:0x2 ve Sense 0x4 alanları dikkat çekmektedir.
Kayıtlar, ilgili depolama aygıtının bir okuma komutunu başarıyla tamamlayamadığını göstermektedir. Bununla birlikte, yalnızca bu log satırlarından hareketle kesin olarak Storage Latency teşhisi konulamaz.
Sorunun bir disk arızası, storage controller problemi, SAN bağlantı hatası veya depolama altyapısındaki başka bir bileşenden kaynaklanıp kaynaklanmadığı ayrıca araştırılmalıdır.
Önemli: Loglarda yer alan naa.* kimliği, hatanın hangi depolama aygıtıyla ilişkili olduğunu belirlemek için kullanılabilir.
Storage Altyapısının Kontrol Edilmesi
Yönetim servislerine müdahale edilmeden önce depolama altyapısının sağlıklı çalıştığından emin olunmalıdır.
Öncelikle ilgili datastore’un erişilebilirliği ve storage path durumları kontrol edilmelidir.
ESXi üzerinde tanımlı depolama aygıtlarının incelenmesi için;
esxcli storage core device listDepolama bağlantı yollarının görüntülenmesi için;
esxcli storage core path listBu çıktılarda problemli cihazın durumu, bağlantı yolları ve ilgili storage adapter bilgileri incelenebilir.
Daha sonra esxtop aracı kullanılarak depolama performansı analiz edilebilir.
esxtopArdından disk aygıtları görünümüne geçmek için u tuşuna basılabilir.
İnceleme sırasında özellikle şu performans metrikleri önemlidir:
| Metrik | Açıklama |
|---|---|
| DAVG/cmd | Depolama aygıtı tarafındaki ortalama I/O gecikmesi |
| KAVG/cmd | VMkernel seviyesindeki ortalama gecikme |
| GAVG/cmd | ESXi tarafından gözlemlenen toplam ortalama I/O gecikmesi |
Bu değerlerin yüksek olması veya beklenmedik şekilde artması, depolama performansı açısından araştırılması gereken bir durumu gösterebilir.
Gecikme değerleri depolama teknolojisine, iş yüküne ve altyapı tasarımına göre değerlendirilmelidir.
Eğer SAN veya harici storage kullanılıyorsa disklerin, storage controller bileşenlerinin, bağlantı portlarının, HBA adaptörlerinin ve backend fabric altyapısının ayrıca kontrol edilmesi önerilir.
Depolama altyapısındaki sorun devam ederken yalnızca ESXi yönetim servislerini yeniden başlatmak, kalıcı çözüm sağlamayabilir.
hostd ve vpxa Servislerinin Kontrol Edilmesi
Depolama tarafındaki sorun giderildikten veya altyapının kararlı çalıştığı doğrulandıktan sonra ESXi yönetim servisleri incelenmelidir.
Öncelikle servislerin mevcut durumu kontrol edilir.
/etc/init.d/hostd status
/etc/init.d/vpxa statusServislerden biri durmuş veya yanıt veremez durumdaysa kontrollü yeniden başlatma işlemi uygulanabilir.
hostd servisinin yeniden başlatılması;
/etc/init.d/hostd restartvpxa servisinin yeniden başlatılması:
/etc/init.d/vpxa restartBu işlemler, ESXi yönetim bileşenlerinin yeniden başlatılmasını ve vCenter Server ile host arasındaki iletişimin yeniden kurulmasını sağlayabilir.
Servisler yeniden başlatıldıktan sonra kısa bir süre beklenmeli ve vCenter Server üzerinden hostun bağlantı durumu kontrol edilmelidir.
Ardından servis logları incelenerek hataların devam edip etmediği doğrulanmalıdır.
/var/run/log/hostd.log
/var/run/log/vpxa.logKritik uyarı: Bazı kaynaklarda tüm yönetim servislerinin services.sh restart komutuyla yeniden başlatılması önerilmektedir. Ancak vSAN, NSX, LACP veya paylaşımlı grafik teknolojilerinin kullanıldığı ortamlarda bu komut ciddi hizmet kesintilerine yol açabilir.
Bu nedenle mümkün olduğunca ilgili servislerin ayrı ayrı yeniden başlatılması tercih edilmeli, işlem öncesinde ortamın yapılandırması doğrulanmalıdır. Yönetim servislerini yeniden başlatmak da aktif görevleri ve bazı sanal makine işlemlerini etkileyebilir.
VMware vSphere Distributed Switch Senkronizasyonunun Kontrol Edilmesi
ESXi yönetim servisleri yeniden çalışır duruma geldikten sonra vDS yapılandırmasının vCenter Server ile tutarlı olup olmadığı kontrol edilmelidir.
Bunun için vSphere Client üzerinden Networking bölümüne geçilir.
İlgili vSphere Distributed Switch seçilerek bağlı ESXi hostlarının senkronizasyon durumu incelenir.
Etkilenen hostun durumu In Sync olarak görüntüleniyorsa vDS yapılandırması vCenter Server ile senkronize durumdadır.
Ancak Out of Sync durumunun devam etmesi halinde ağ yapılandırmasının yeniden eşitlenmesi gerekebilir.
Bu noktada işlemin üretim ortamına etkisi mutlaka değerlendirilmelidir.
Çünkü Distributed Switch üzerinde Management Network, vMotion, vSAN veya sanal makinelere ait kritik Port Group bağlantıları bulunabilir.
Dolayısıyla vDS üzerinden host kaldırma işlemi doğrudan uygulanmamalıdır.
vDS Yapılandırmasının Yeniden Oluşturulması ve Senkronizasyon
Depolama ve yönetim servisleri sağlıklı olmasına rağmen vDS senkronizasyon sorunu devam ediyorsa ilgili ESXi hostunun Distributed Switch bağlantısının yeniden oluşturulması değerlendirilebilir.
Bu yöntem, hostun vDS yapılandırmasını yeniden almasını sağlayabilir.
Ancak işlem öncesinde ağ bağlantılarının güvenli şekilde taşınması gerekir.
Adım 1 – Ağ yapılandırmasını yedekleyin ve kayıt altına alın
vDS Port Group yapılandırmaları, VLAN ID değerleri, MTU ayarları, uplink eşleştirmeleri ve VMkernel bağlantıları kontrol edilmelidir.
Mümkünse vDS yapılandırmasının dışa aktarılmış bir yedeği alınmalıdır.
Adım 2 – Management Network erişimini güvenceye alın
ESXi hostunun Management Network bağlantısı ilgili vDS üzerinde bulunuyorsa hostun vDS üzerinden kaldırılması yönetim erişimini kesebilir.
Bu nedenle gerekli VMkernel adapter, fiziksel uplink ve sanal makine bağlantıları uygun bir vSphere Standard Switch (vSS) veya alternatif ağ altyapısına güvenli şekilde taşınmalıdır.
İşlem öncesinde iLO, iDRAC veya eşdeğer out-of-band yönetim erişiminin hazır olması önerilir.
Adım 3 – ESXi hostunu Maintenance Mode durumuna alın
Çalışan sanal makineler güvenli şekilde başka hostlara taşındıktan veya uygun biçimde kapatıldıktan sonra ESXi hostu Maintenance Mode durumuna alınır.
vMotion çalışmıyorsa hostun boşaltılması için alternatif bir bakım planı hazırlanmalıdır.
Adım 4 – ESXi hostunu vDS üzerinden kaldırın
vSphere Client üzerinden:
Networking → vDS → Add and Manage Hosts → Remove hosts
İlgili ESXi hostu seçilerek kaldırma işlemi tamamlanır.
Bu işlem yalnızca hostun kritik ağ bağlantıları güvenli şekilde başka bir yapıya taşındığında gerçekleştirilmelidir.
Adım 5 – ESXi hostunu yeniden vDS üzerine ekleyin
Aynı Distributed Switch üzerinde:
Networking → vDS → Add and Manage Hosts → Add hosts
Seçeneği kullanılarak host yeniden eklenir.
Ardından fiziksel adapter eşleştirmeleri, VMkernel bağlantıları ve gerekli sanal makine ağları kontrollü şekilde yeniden yapılandırılır.
Adım 6 – Senkronizasyon durumunu doğrulayın
Host yeniden eklendikten sonra vDS yapılandırmasının In Sync durumuna dönüp dönmediği kontrol edilir.
Management Network, vMotion Network ve diğer gerekli ağ servisleri doğrulandıktan sonra host Maintenance Mode durumundan çıkarılabilir.
Sorun Devam Ederse ESXi Hostunun Yeniden Başlatılması Gerekecektir.
Depolama sorununun giderilmesine ve yönetim servislerinin yeniden başlatılmasına rağmen host hâlâ yanıt vermiyorsa kontrollü bir ESXi reboot işlemi değerlendirilebilir.
Ancak reboot işlemine geçmeden önce çalışan sanal makinelerin durumu kontrol edilmelidir.
Host üzerinde aktif sanal makineler bulunuyorsa bunların güvenli şekilde taşınması veya kapatılması gerekir.
ESXi hostunun yeniden başlatılması, depolama sorununun temel nedenini ortadan kaldırmaz. Bu işlem yalnızca yönetim servislerinin ve hostun çalışma durumunun yeniden oluşturulmasına yardımcı olabilir.
Üretim ortamlarında plansız reboot yapılmamalıdır.
İşlem Sonrası Doğrulama
Sorun giderme işlemleri tamamlandıktan sonra yalnızca hata mesajının kaybolması yeterli kabul edilmemelidir.
Altyapının kararlı çalıştığını doğrulamak için aşağıdaki kontroller gerçekleştirilmelidir:
- ESXi hostunun vCenter Server üzerinde Connected durumda olduğu doğrulanmalıdır.
- vDS senkronizasyonu In Sync olarak görüntülenmelidir.
hostdvevpxaservislerinin çalıştığı kontrol edilmelidir.- Storage Latency değerleri ve depolama bağlantı yolları yeniden incelenmelidir.
- VMkernel loglarında yeni
ScsiDeviceIOhatalarının oluşup oluşmadığı kontrol edilmelidir. - Uygun bir sanal makine ile test vMotion işlemi gerçekleştirilmelidir.
- Gerekli Port Group bağlantıları ve VMkernel ağ erişimleri doğrulanmalıdır.
Bütün kontroller başarılı şekilde tamamlandığında altyapı normal operasyon durumuna döndürülebilir.
VMware vSphere ortamlarında karşılaşılan vMotion ve Distributed Switch hataları her zaman doğrudan ağ altyapısından kaynaklanmaz.
Özellikle depolama sistemlerindeki yüksek I/O gecikmeleri ve erişim problemleri, ESXi yönetim servislerinin çalışmasını etkileyerek vCenter Server ile host arasındaki yapılandırma senkronizasyonunun bozulmasına neden olabilir.
Bu nedenle sorun giderme sürecinde yalnızca ekranda görüntülenen DVS hata mesajına odaklanmak yerine ESXi VMkernel logları, storage performansı, hostd ve vpxa servisleri birlikte değerlendirilmelidir.
En doğru yaklaşım, öncelikle depolama altyapısındaki temel sorunu tespit etmek, ardından yönetim servislerini sağlıklı duruma getirmek ve yalnızca gerekli olduğunda Distributed Switch yapılandırmasına müdahale etmektir.
Bu yöntem hem gereksiz ağ yapılandırması değişikliklerini önler hem de üretim ortamında oluşabilecek hizmet kesintisi riskini azaltır.
