vCenter 9.1 Yükseltmesinde Kritik Supervisor Uyarısı: Önce Durun, Sonra Yükseltin

Bu sabah gündemi kontrol ederken VMware Cloud Foundation ekibinin 9 Ekim 2026’da yayımladığı kritik uyarıyı gördüm ve diğer her şeyi bir kenara bırakıp onunla başlamaya karar verdim. Sebebi basit: eğer ortamınızda vSphere Supervisor veya VKS (vSphere Kubernetes Service) kümeleri çalışıyorsa ve yakın zamanda vCenter 9.1.0 ya da 9.1.1’e geçmeyi planlıyorsanız, bu uyarı doğrudan sizi ilgilendiriyor ve ertelenecek türden değil. Zira “kötü senaryoda” kaybedilen şey birkaç log satırı değil; Supervisor Control Plane sanal makineleri ve Foundation Load Balancer’ların envanterden silinmesi.

Ben bu senaryoyu henüz kendi laboratuvarımda yeniden üretme fırsatı bulamadım; aşağıdaki değerlendirme resmî Broadcom duyurusu ile bağımsız güvenlik kaynaklarına dayanıyor. Ama bir sistem mühendisi olarak “envanterden VM silinmesi” ifadesini okuduğumda içimin nasıl ürperdiğini tahmin edebilirsiniz. Gelin somut olarak ne olduğuna bakalım.

VMware’in vCenter 9.1 yükseltme uyarısı tam olarak neyi anlatıyor?

Uyarının teknik özü şu: Geçmişte vLCM/VUM depo veritabanını KB 316581‘deki reset scripti ile sıfırladıysanız, veritabanı şeması tutarsız kalmış olabilir. Bu reset işlemi, yerleşim (placement) politikası kolonlarını ve ilişki tablolarını düşürüyor. 9.1 ile gelen yeni LCCM alt sistemi ise sistem VM’lerini keşfetmek için tam olarak bu ilişkilere güveniyor. Sonuç olarak, tutarsız bir şema üzerine 9.1.x yükseltmesi yapıldığında LCCM Supervisor durumunu uzlaştıramıyor ve etkilenen VM’ler ile FLB’leri envanterden kaldırıyor.

Etkilenen kaynak sürümler vCenter Server 8.0 Update 3 ve sonrası ile 9.0.0 / 9.0.1 / 9.0.2; hedef sürümler ise VCF 9.1.0 ve 9.1.1. Yani “ben zaten 9.0’dayım, bende olmaz” rahatlığı burada geçerli değil. Kritik nokta, sorunun yükseltmenin kendisinden değil, geçmişte çalıştırılmış bir reset scriptinin bıraktığı izden kaynaklanması. Bu yüzden ekrandaki sürüm numarasına bakıp “temizim” demek yeterli değil; veritabanını fiilen doğrulamak gerekiyor.

Peki ne yapmalı? Uyarının önerdiği sıralama net ve ben de aynen bu sırayla ilerlerdim. Önce yükseltmeyi bekletin; 9.1.0 veya 9.1.1’e geçmeden tutarlılığı doğrulamadan dokunmayın. Doğrulama için iki yol var: KB 455737‘deki denetim (checker) scriptini çalıştırmak ya da VCF Diagnostic Tool for vSphere (VDT) ile bir sağlık taraması yapmak. VDT çıktısında “[FAIL] VUM SCHEMA CHECK” görüyorsanız sorun sizde var demektir. İkinci adım, aynı KB’deki düzeltme (remediation) adımlarını uygulamak. Üçüncü ve benim gözümde pazarlık edilemez adım: yükseltmeden önce vCenter ve Supervisor’ın yedeğini/snapshot’ını almak. Dördüncüsü, bunlar tamamsa yükseltmeye geçmek.

En kötü durum için de bir çıkış yolu var: Yükseltmeyi çoktan yaptıysanız ve Supervisor VM’leri kaybolduysa, yükseltme öncesi yedeğe/snapshot’a dönüp Supervisor durumunu geri yükledikten sonra veritabanı düzeltmesini uygulamanız gerekiyor. Kurtarma adımları KB 457944‘te. Buradaki sıralama önemli: önce geri dön, Supervisor’ı ayağa kaldır, sonra düzeltmeyi uygula.

Arka plandaki güvenlik tablosu: VMSA-2026-0006

Bu yükseltme telaşı boşlukta değil. vCenter 9.1.x’in neden gündemde olduğunu anlamak için 29 Temmuz 2026’da yayımlanan VMSA-2026-0006 advisory’sine bakmak gerekiyor. İçinde iki kritik açık var ve ikisi de CVSSv3.1 taban puanı 9.8 ile işaretlenmiş; yani ağ erişimi olan, kimlik doğrulaması bile yapmamış bir saldırgan tarafından istismar edilebilir seviyede.

CVE-2026-59309, VMware Directory Service üzerinde bir kimlik doğrulama atlatma açığı; başarılı istismarda saldırgan vCenter yönetim düzlemine yetkisiz erişim kazanabiliyor. CVE-2026-59310 ise vCenter Syslog sunucusundaki bir dizin gezinme (directory traversal) açığı ve uzaktan kod çalıştırma riskini doğuruyor. Broadcom’un belirttiğine göre bir workaround yok; tek gerçek çözüm yama.

Düzeltme sürümleri şöyle: vCenter 9.1.x için 9.1.0.0300, 9.0.x için 9.0.2.0100, 8.0 için 8.0 U3k, VCF 5.x için 8.0 U3k’ye async yama. Dikkatinizi çekerim: 9.1.x cephesindeki düzeltme 9.1.0.0300, yani yukarıda konuştuğumuz yükseltme uyarısı ile bu güvenlik yaması aynı sürüm ailesinde buluşuyor. İşte tam da bu yüzden “önce veritabanı tutarlılığını doğrula, sonra yükselt” tavsiyesi bu kadar kritik: güvenlik için zaten 9.1.x’e geçmek isteyeceksiniz, ama kör bir yükseltme Supervisor’ınıza mal olabilir.

Bir dürüstlük notu: VMSA ilk yayımlandığında Rapid7 gibi kaynaklar vahşi ortamda bilinen bir istismar ya da tarama gözlemlenmediğini belirtmişti. Sonradan bazı üçüncü taraf bloglar hızlı istismar iddiaları dile getirdi; ben bunları bağımsız olarak doğrulayamadım. İstismar olsun ya da olmasın, CVSS 9.8 ve “workaround yok” kombinasyonunda benim yaklaşımım tartışmasız: yamalamayı acil işler kuyruğunun en başına almak.

Sunucu tarafı: 6. nesil AMD EPYC ve “agentic” veri merkezi söylemi

Sanallaştırma katmanından bir kat aşağıya, demire inelim. Bu yılın Advancing AI 2026 etkinliğinde (23 Temmuz 2026) duyurulan 6. nesil AMD EPYC (9006 serisi), kurumsal sunucu planlaması yapan herkesin radarında olmalı. AMD bu nesli açıkça “agentic veri merkezi” söylemiyle konumlandırıyor; yani çok sayıda eşzamanlı yapay zeka ajanını CPU üzerinde koşturma iddiası.

Rakamlar etkileyici: SP7 soketinde 256 çekirdeğe (SMT ile 512 iş parçacığına) kadar, bazı 9006X varyantlarında 5.15 GHz’e varan saat hızları, PCIe Gen 6 ve 16 kanala kadar 12.8 GT/s MRDIMM desteği. Ancak buradaki tüm performans ve kapasite karşılaştırmaları AMD’nin kendi verileri. “Rack başına şu kadar agent” gibi ölçümler, AMD’nin footnote’larında da açıkça yazdığı gibi, CPU iş parçacığı kaynaklarından türetilen tahminler. Benim iş yüküme göre bu sayıların ne ifade ettiğini anlamak için bağımsız kıyaslamaları ve kendi POC testlerimi beklerim. Yine de çekirdek yoğunluğu ve bellek bant genişliğindeki bu sıçrama, VMware lisanslamasının çekirdek/soket başına fiyatlandığı Broadcom dünyasında konsolidasyon matematiğini doğrudan etkiliyor; yani bu haber sanallaştırma tarafıyla göründüğünden daha bağlantılı.

Yapay zeka araçları ve nasıl yapılır: Bir advisory’yi runbook’a çevirmek

Bu hafta pratik bir iş akışını paylaşmak istiyorum, çünkü yukarıdaki iki VMware haberi tam da bu akışın işe yaradığı türden. Bir güvenlik advisory’si düştüğünde ben artık ham metni doğrudan bir yapay zeka asistanına “özetle” diye vermiyorum; bunun yerine yapılandırılmış bir çıktı isteyerek doğrulanabilir bir kontrol listesine dönüştürüyorum. Kabaca kullandığım istem iskeleti şöyle:

Rol: Kıdemli VMware platform mühendisi.
Girdi: [advisory metnini buraya yapıştır]
İstenen çıktı (tablo halinde):
1) Etkilenen ürün + sürüm aralığı
2) Etkilenmeyen sürümler (açıkça)
3) Düzeltme/hedef sürüm
4) Ön koşul/doğrulama adımı (KB no ile)
5) Geri alma (rollback) adımı (KB no ile)
Kural: Metinde olmayan hiçbir sürüm/KB numarasını uydurma;
emin değilsen "kaynakta belirtilmemiş" yaz.

Son satır benim için kritik: modele “bilmiyorsan uydurma” demezseniz, eksik bir sürüm numarasını doldurma eğilimi işi tehlikeli hale getirir. Çıktıyı aldıktan sonra her KB numarasını ve sürüm etiketini resmî kaynaktan tek tek doğrularım; asistan burada bir taslak hızlandırıcısı, nihai otorite değil. Bu yaklaşımla bir VMSA’yı okunabilir bir değişiklik kaydına (change request) dönüştürmek dakikalar sürüyor, ama sorumluluk hâlâ mühendiste.

Türkiye’den kısa bir not

Yurt içi tarafta da ivme sürüyor. TÜİK’in 2026 verilerine göre Türkiye’de yapay zeka kullanımının bir yılda neredeyse ikiye katlandığı, kurumsal benimsemenin hızlandığı bildirildi. Bununla paralel olarak Türkiye Yapay Zeka Eylem Planı’nın Resmî Gazete’de yayımlanmış olması, kamu ve kurumsal tarafta veri merkezi ve yapay zeka altyapısı yatırımlarının politika zeminine oturduğunu gösteriyor. Bu, bizim gibi altyapıyı taşıyan mühendisler için orta vadede daha fazla kapasite planlaması ve uyum gereksinimi demek.

vCenter 9.1’e geçmeyi tamamen ertelemeli miyim?

Hayır. VMSA-2026-0006 nedeniyle güvenlik tarafında 9.1.x zaten istenen hedef. Ertelenmesi gereken şey, veritabanı tutarlılığını doğrulamadan yapılan kör yükseltme. Önce KB 455737 denetimini veya VDT taramasını çalıştırın.

Hiç reset scripti çalıştırmadıysam da risk altında mıyım?

Sorun esas olarak geçmişte KB 316581 reset scriptini çalıştırmış ortamları hedefliyor. Ancak emin değilseniz doğrulama adımı birkaç dakikanızı alır; “[FAIL] VUM SCHEMA CHECK” çıkmazsa içiniz rahat eder.

Bu iki haber (yükseltme uyarısı ve CVE’ler) aynı şey mi?

Hayır, ayrı konular. VMSA-2026-0006 güvenlik açıklarıyla ilgili (Temmuz); 9 Ekim tarihli uyarı ise yükseltme sırasında Supervisor/VKS kaybı riskiyle ilgili operasyonel bir uyarı. Ama ikisi de 9.1.x sürüm ailesinde kesiştiği için birlikte planlanmalı.

Değerlendirmem

Bugünün en zaman-hassas ve mühendis-ilgili gelişmesi, hiç tereddütsüz, VMware’in vCenter 9.1 yükseltme uyarısıydı; o yüzden makaleyi onunla açtım. Mesajım net: güvenlik yüzünden 9.1.x’e geçme baskısı gerçek, ama bu baskıyı veritabanı doğrulamasını atlamak için bahane yapmayın. Benim defterime bu hafta üç madde yazıldı — ortamda KB 316581 geçmişini sorgula, yükseltmeden önce VDT/KB 455737 denetimini çalıştır, ve yedeği al. Demir tarafında EPYC 9006 heyecan verici ama ben kararımı bağımsız testlere göre vereceğim; üretici slaytı bir başlangıç noktası, karar noktası değil. Kendi ortamınızda denediyseniz, özellikle VDT çıktılarınızı yorumlarda paylaşırsanız sevinirim.

Not: Yükseltme kararlarınızı mutlaka kendi ortamınızda ve güncel resmî KB’ler üzerinden doğrulayın.