VMware vSphere Lifecycle Manager’da “An Unknown Error Occurred While Performing the Operation” Hatası ve Çözümü

VMware vSphere Lifecycle Manager’da “An Unknown Error Occurred While Performing the Operation” Hatası ve Çözümü

VMware vSphere ortamlarında ESXi sunucularının yazılım sürümlerini, güncellemelerini ve bileşenlerini merkezi olarak yönetmek için kullanılan vSphere Lifecycle Manager (vLCM), sanallaştırma altyapısının güncel ve tutarlı tutulmasını sağlayan önemli bir bileşendir.

Lifecycle Manager’ın sunduğu Check Compliance özelliği, ESXi sunucularında yüklü olan yazılım bileşenlerinin vCenter üzerinde tanımlanan hedef imaj (Desired Image) ile uyumlu olup olmadığını kontrol eder. Bu işlem sayesinde sunucuların güncelleme gereksinimleri, sürüm farklılıkları ve yazılım uyumsuzlukları tespit edilebilir.

Ancak bazı durumlarda, özellikle daha önce güncelleme veya imaj hazırlama işlemi gerçekleştirilmiş ESXi sunucularında, uyumluluk kontrolü beklenmedik bir hata ile başarısız olabilir.

Bu makalede, vSphere Lifecycle Manager üzerinden Check Compliance işlemi gerçekleştirildiğinde karşılaşılan “An unknown error occurred while performing the operation” hatasının nedenlerini, log kayıtları üzerinden nasıl analiz edilebileceğini ve ESXi 7.x ile ESXi 8.x sürümlerinde uygulanabilecek çözüm yöntemlerini ele alacağız.

Problemin Tanımı

vCenter Server üzerinde imaj tabanlı olarak yönetilen bir ESXi sunucusu veya cluster için uyumluluk kontrolü başlatıldığında işlem tamamlanamayabilir.

vSphere Client arayüzünde aşağıdaki hata mesajı görüntülenir:

An unknown error occurred while performing the operation

Bu hata genellikle aşağıdaki işlem sırasında ortaya çıkar:

  1. vSphere Client arayüzüne giriş yapılır.
  2. Hosts and Clusters bölümünden ilgili cluster veya ESXi sunucusu seçilir.
  3. Updates > Hosts > Image bölümüne gidilir.
  4. Check Compliance işlemi başlatılır.

Normal şartlarda Lifecycle Manager, ESXi sunucusunun mevcut yazılım durumunu hedef imaj ile karşılaştırarak uyumluluk sonucunu gösterir. Ancak bu problem oluştuğunda tarama işlemi tamamlanamaz ve uyumluluk durumu doğru şekilde belirlenemez.

Hatanın yalnızca belirli bir ESXi sunucusunda görülmesi mümkündür. Aynı cluster içerisindeki diğer sunucularda uyumluluk kontrolü sorunsuz çalışırken, daha önce güncelleme hazırlığı yapılmış bir sunucuda işlem başarısız olabilir.

Hata Kayıtlarının İncelenmesi

Sorunun kaynağını belirlemek için ilk olarak hatadan etkilenen ESXi sunucusunun Lifecycle Manager log kayıtları incelenmelidir.

ESXi sunucusuna SSH üzerinden bağlanıldıktan sonra aşağıdaki log dosyası kontrol edilir:

/var/run/log/lifecycle.log

Log dosyasındaki son kayıtları görüntülemek için:

tail -n 100 /var/run/log/lifecycle.log

Alternatif olarak ilgili hata kayıtları filtrelenebilir:

grep -E "Failed to validate|KeyError|Scanner" /var/run/log/lifecycle.log

Problemin oluştuğu ortamlarda aşağıdakine benzer mesajlarla karşılaşılabilir:

YYYY-MM-DDThh:mm:ssZ Er(11) lifecycle[2240255]: Scanner:906 Failed to validate/extract the softwareSpec: 'VMware-VM-Tools_12.2.5.#####-######'
YYYY-MM-DDThh:mm:ssZ Er(11) lifecycle[2240255]: Scanner:907 Traceback (most recent call last):
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: File "/tmp/esx-update-2240255/lib64/python3.11/site-packages/vmware/esximage/ImageManager/Scanner.py", line 3388, in scan
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: self.stagedSoftwareSpec = self.getImageProfileScanSpec(
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: File "/tmp/esx-update-2240255/lib64/python3.11/site-packages/vmware/esximage/ImageManager/Scanner.py", line 1355, in getImageProfileScanSpec
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: compInfo = self.scanLocalComponents(imageProfile,
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: File "/tmp/esx-update-2240255/lib64/python3.11/site-packages/vmware/esximage/ImageManager/Scanner.py", line 1123, in scanLocalComponents
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: probs = hostComps.Validate(self._depotMgr.vibs)
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: File "/tmp/esx-update-2240255/lib64/python3.11/site-packages/vmware/esximage/Bulletin.py", line 1613, in Validate
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: return scanner.Validate()
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: File "/tmp/esx-update-2240255/lib64/python3.11/site-packages/vmware/esximage/ComponentScanner.py", line 1530, in Validate
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: self._GetAllProblems()
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: File "/tmp/esx-update-2240255/lib64/python3.11/site-packages/vmware/esximage/ComponentScanner.py", line 740, in _GetAllProblems
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: compRelation = self.componentScanResult[comp.id]
YYYY-MM-DDThh:mm:ssZ Er(11)[+] lifecycle[2240255]: KeyError: 'VMware-VM-Tools_12.2.5.#####-######'

Bu kayıtlarda özellikle iki mesaj dikkat çekmektedir:

Failed to validate/extract the softwareSpec: Lifecycle Manager, ESXi üzerinde hazırlık aşamasında bulunan yazılım imajına ait bileşen bilgilerini doğrulayamamaktadır.

KeyError: Uyumluluk taraması sırasında beklenen bir bileşen bilgisine erişilemediğini göstermektedir. Örnekte hata VMware Tools bileşeni üzerinden oluşsa da bu durum doğrudan VMware Tools yazılımının bozuk olduğu anlamına gelmez.

Dolayısıyla yalnızca bu hata mesajına bakarak VMware Tools bileşenini yeniden yüklemek veya ESXi sunucusunu güncellemek doğru bir yaklaşım değildir. Öncelikle hazırlık aşamasında bırakılmış imaj dosyalarının kontrol edilmesi gerekir.

Problemin Temel Nedeni

Broadcom tarafından yayımlanan 397593 numaralı bilgi bankası makalesine göre bu hata, ESXi sunucusunda bulunan staged image (önceden hazırlanmış yazılım imajı) nedeniyle oluşmaktadır.

vSphere Lifecycle Manager üzerinden bir ESXi sunucusuna güncelleme uygulanmadan önce gerekli yazılım paketleri ve bileşenler hazırlanabilir. Bu işlem staging olarak adlandırılır.

Staging işlemi sırasında Lifecycle Manager, güncellemeye ait dosyaları ESXi sunucusu üzerinde belirli dizinlere yerleştirir.

Ancak önceki bir güncelleme işleminin kesintiye uğraması, tamamlanamaması veya hazırlanan imaj bilgilerinin mevcut yazılım durumuyla tutarsız hale gelmesi sonucunda bu dizinlerde eski ya da geçersiz içerikler kalabilir.

Böyle bir durumda Lifecycle Manager yeni bir uyumluluk kontrolü gerçekleştirmeye çalıştığında, mevcut yazılım bileşenleriyle hazırlanan imaj arasında doğru bir ilişki kuramayabilir.

Sonuç olarak tarama işlemi başarısız olur ve vCenter arayüzünde genel bir hata mesajı görüntülenir.

Burada dikkat edilmesi gereken önemli nokta, problemin doğrudan çalışan sanal makinelerden veya ESXi üzerindeki mevcut veri depolarından kaynaklanmamasıdır. Bu senaryoda sorun, Lifecycle Manager’ın uyumluluk kontrolü sırasında değerlendirmeye çalıştığı geçici imaj hazırlık içerikleriyle ilişkilidir.

Çözüm Öncesinde Yapılması Gereken Kontroller

Sorunun giderilmesi için ESXi sunucusunda bulunan eski staging içeriklerinin temizlenmesi gerekebilir. Ancak bu işlem öncesinde bazı kontroller gerçekleştirilmelidir.

Öncelikle ESXi sunucusunun hangi sürümü kullandığı doğrulanmalıdır:

vmware -v

Ardından Lifecycle Manager üzerinden devam eden bir güncelleme, staging veya remediation işlemi bulunmadığından emin olunmalıdır.

Önemli: Aşağıdaki temizleme komutları dosyaları kalıcı olarak siler. Bu nedenle yalnızca eski veya kullanılmayan staging içerikleri doğrulandıktan sonra uygulanmalıdır. Devam eden ya da planlanan bir güncellemenin hazırlık dosyaları temizlenmemelidir. Üretim ortamlarında bakım penceresi planlanması ve ESXi yapılandırma yedeğinin alınması önerilir.

Ayrıca /bootbank ve /altbootbank gibi ESXi sisteminin önyükleme bölümleri kesinlikle bu işlem kapsamında silinmemelidir.

ESXi 7.x Üzerinde Hatanın Giderilmesi

ESXi 7.x sürümlerinde Lifecycle Manager tarafından hazırlanan geçici imaj içerikleri aşağıdaki dizinlerde bulunabilir:

/tmp/stagebootbank
/tmp/stageliveimage

Adım 1: Staging dizinlerini kontrol edin

ESXi sunucusuna SSH üzerinden bağlanarak ilgili dizinlerin mevcut olup olmadığını kontrol edin:

ls -ld /tmp/stagebootbank /tmp/stageliveimage

Dizinler mevcutsa içeriklerini görüntüleyin:

ls -lah /tmp/stagebootbank
ls -lah /tmp/stageliveimage

Bu dizinlerin bulunmaması normal olabilir. Böyle bir durumda ilgili dizin için temizleme işlemi uygulanmasına gerek yoktur.

Adım 2: Ramdisk yapılandırmasını inceleyin

ESXi 7.x üzerinde bu staging alanları geçici ramdisk yapılarıyla ilişkili olabileceğinden öncelikle mevcut ramdisk bilgilerini kontrol edin:

esxcli system visorfs ramdisk list

Bu komut, sunucu üzerindeki visorfs ramdisk yapılarını görüntülemek için kullanılabilir.

Adım 3: Eski staging içeriklerini temizleyin

İlgili dizinin eski ve kullanım dışı staging içerikleri barındırdığı doğrulandıktan sonra /tmp/stagebootbank için aşağıdaki komutlar uygulanabilir:

esxcli system visorfs ramdisk remove -t /tmp/stagebootbank
rm -rf /tmp/stagebootbank

Eğer problem /tmp/stageliveimage dizinindeki staging içerikleriyle ilişkiliyse:

esxcli system visorfs ramdisk remove -t /tmp/stageliveimage
rm -rf /tmp/stageliveimage

Bu komutların amacı eski staging alanlarını kaldırarak Lifecycle Manager’ın sonraki işlemlerinde yeni hazırlık içerikleri oluşturabilmesini sağlamaktır.

Ramdisk kaldırma işlemi alanın kullanımda olması nedeniyle başarısız olursa zorla silmeye devam edilmemeli; önce ilgili süreç ve güncelleme durumu incelenmelidir.

Adım 4: Uyumluluk kontrolünü yeniden çalıştırın

Temizleme işleminin ardından vSphere Client arayüzüne dönerek ilgili ESXi sunucusu veya cluster için Updates > Hosts > Image > Check Compliance işlemini tekrar başlatın.

Eski staging içerikleri soruna neden oluyorsa temizleme sonrasında uyumluluk taramasının başarılı şekilde tamamlanması beklenir.

ESXi 8.x Üzerinde Hatanın Giderilmesi

ESXi 8.x sürümlerinde staging içeriklerinin tutulduğu dizin yapısı ESXi 7.x sürümünden farklıdır.

Bu sürümde ilgili dizinler şunlardır:

/var/vmware/lifecycle/stagebootbank
/var/vmware/lifecycle/stageliveimage

Adım 1: Dizinlerin mevcut durumunu inceleyin

ESXi sunucusuna SSH bağlantısı gerçekleştirerek aşağıdaki komutları çalıştırın:

ls -lah /var/vmware/lifecycle/stagebootbank
ls -lah /var/vmware/lifecycle/stageliveimage

Bu kontroller sayesinde ilgili dizinlerde dosya bulunup bulunmadığı ve içeriklerin mevcut durumu incelenebilir.

Adım 2: Kullanılmayan staging içeriklerini temizleyin

Dizinlerde bulunan içeriklerin herhangi bir aktif güncelleme işlemine ait olmadığı doğrulandıktan sonra eski staging dosyaları temizlenebilir.

stagebootbank dizininin içeriğini temizlemek için:

rm -rf /var/vmware/lifecycle/stagebootbank/*

stageliveimage dizininin içeriğini temizlemek için:

rm -rf /var/vmware/lifecycle/stageliveimage/*

Bu komutlar, belirtilen staging dizinlerindeki eşleşen dosya ve klasörleri siler; dizinlerin kendisini hedef almaz.

Dikkat: Komutlardaki dizin yollarının doğru yazıldığından emin olunmalıdır. Özellikle rm -rf komutunun yanlış dizin üzerinde çalıştırılması, ESXi sisteminde ciddi sorunlara yol açabilir.

Adım 3: Check Compliance işlemini tekrar başlatın

Temizleme işlemi tamamlandıktan sonra vCenter Server arayüzüne dönün.

İlgili cluster veya ESXi sunucusunu seçerek Updates > Hosts > Image > Check Compliance işlemini tekrar çalıştırın.

Problemin nedeni eski staged image içerikleri ise Lifecycle Manager’ın yazılım bileşenlerini yeniden değerlendirmesi ve uyumluluk sonucunu oluşturması beklenir.

Sorunun Giderildiğinin Doğrulanması

Temizleme işleminden sonra yalnızca hata mesajının kaybolması değil, uyumluluk kontrolünün doğru şekilde tamamlandığı da doğrulanmalıdır.

Bunun için Lifecycle Manager üzerinde aşağıdaki durumlar kontrol edilmelidir:

KontrolBeklenen sonuç
Check Compliance göreviHatasız tamamlanmalı
Image ComplianceGeçerli bir uyumluluk durumu göstermeli
ESXi host bağlantısıConnected durumunda olmalı
Lifecycle log kayıtlarıAynı staging doğrulama hatası tekrarlanmamalı
Cluster imaj durumuHedef imajla karşılaştırma tamamlanmalı

Uyumluluk kontrolünün başarılı şekilde tamamlanması, ESXi sunucusunun mutlaka Compliant durumda olacağı anlamına gelmez.

Örneğin sunucu üzerinde hedef imajdan farklı yazılım sürümleri bulunuyorsa sonuç Non-Compliant olabilir. Burada önemli olan, Lifecycle Manager’ın yazılım envanterini analiz edebilmesi ve geçerli bir sonuç oluşturabilmesidir.

Hata Devam Ederse Yapılması Gerekenler

Staging dizinlerinin temizlenmesine rağmen problem devam ediyorsa farklı bir yapılandırma veya yazılım uyumsuzluğu söz konusu olabilir.

Bu durumda ilk olarak /var/run/log/lifecycle.log dosyası yeniden kontrol edilmeli ve aynı hatanın devam edip etmediği belirlenmelidir.

Ardından vCenter Server ve ESXi sürümleri, cluster üzerinde tanımlı hedef imaj, yazılım bileşenleri ve güncelleme görevlerinin durumu incelenmelidir.

Benzer uyumluluk hataları, hedef cluster imajının vCenter Server tarafından desteklenenden daha yeni bir ESXi sürümüne ayarlanması durumunda da ortaya çıkabilir. Bu farklı senaryoda çözüm, vCenter Server’ın uygun sürüme güncellenmesini gerektirebilir.

Dolayısıyla yalnızca arayüzde görüntülenen genel hata mesajına dayanarak işlem yapılmamalı, mutlaka ESXi log kayıtlarındaki gerçek hata nedeni belirlenmelidir.

VMware vSphere Lifecycle Manager üzerinde gerçekleştirilen Check Compliance işleminin “An unknown error occurred while performing the operation” hatasıyla başarısız olması, her zaman ESXi sunucusunda ciddi bir yazılım problemi bulunduğu anlamına gelmez.

Bu makalede ele alınan senaryoda hatanın temel nedeni, ESXi sunucusunda önceki güncelleme işlemlerinden kalan staging içeriklerinin Lifecycle Manager tarafından doğru şekilde değerlendirilememesidir.

ESXi 7.x ve 8.x sürümlerinde farklı konumlarda bulunan bu içeriklerin kontrollü şekilde temizlenmesi, uyumluluk taramasının yeniden gerçekleştirilebilmesini sağlayabilir.

Bununla birlikte üretim ortamlarında yapılacak müdahalelerde aktif güncelleme işlemlerinin bulunmadığından emin olunması ve yalnızca soruna neden olduğu doğrulanan staging içeriklerinin kaldırılması önemlidir.

Sonuç olarak, Lifecycle Manager kaynaklı uyumluluk hatalarında ilk yaklaşım ESXi sunucusunu yeniden başlatmak veya yazılım bileşenlerini yeniden kurmak yerine, ilgili log kayıtlarını analiz ederek hatanın gerçek nedenini belirlemek olmalıdır. Böylece gereksiz müdahaleler önlenebilir ve sanallaştırma altyapısının sürekliliği korunabilir.

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *