Nie rób tego swojemu ESXowi! | Mój błąd…

10… 20… 30 minut a host nie wraca po restarcie….. czy już można zacząć się martwić ?

I stało się po zalogowaniu do konsoli zarządzającej piękny fioletowy kolor mógł oznaczać tylko jedno – PSOD (Purple Screen of Death). Oczywiście wtedy uświadomiłem sobie swój błąd bo wczoraj jeszcze o tym pamiętałem…. tak zrobiłem to zaktualizowałem hosta do wersji ESXi, która jest już za wysoka dla tego sprzętu. Maks miał być ESXi 6.5 U2 a teraz jest na ESXi 6.7 U3

 

 

Myślę sobie… ale co tam… wracamy zatem do niższej wersji przecież jest to wspierana ścieżka zgodnie z KB 

 

 

Proces przeszedł bez problemów i po około 30 minutach miałem już hosta w poprzedniej wersji… uff.. z głowy 🙂 Teraz tylko wyjście z MMa i na dziś spokój.

 

Nie nie… nie tym razem 🙂 Zaraz po wyjściu z Maintenace Mode było widać iż vCenter próbuje… i próbuje zainstalować coś na tym ESXie co jest normalne. W tym przypadku następuje weryfikacja konfiguracja hosta i na ESXi instalowany jest np. agent od HA. No tak i tutaj właśnie był problem. Pojawiały się komunikaty typu:

“Timeout” dla tej operacji…

 

👉 Diagnostyka czyli tzw. troubleshooting

1. Zacząłem więc spokojnie używać swoich hackerskich umiejętności pracy w GUI i najpierw użyłem opcji ponownej rekonfiguracji agenta od HA na hoscie.

 

 

Wynik w zasadzie był taki sam.

 

 

2. Dalej postanowiłem użyć stary i sprawdzony sposób aby na chwilę wyłączyć HA na klastrze (nie zalecam tego bez świadomości jaki wprowadzasz czynnik ryzyka) i po chwile włączyć ponowie.

 

Działa to w ten sposób że agenty na hostach są wyłączane (VIBy pozostają nadal zainstalowane ale hosty nie tworzą klastra HA i hosty nie mają podziału na role typu “master” , “slave”)

 

 

3. Kolejnym etapem była ręczna próba deinstalacji agenta HA z hosta.

Czynność wykonana wg. dokumentu KB ta wprowadziła mnie na pewien trop.

 


[root@esxi: esxcli software vib remove -n vmware-fdm
[DependencyError]
VIB VMware_locker_tools-light_10.3.10.12406962-14141615 requires esx-version >= 6.6.0, but the requirement cannot be satisfied within the ImageProfile.

Komunikat wskazywał iż zależny komponent “tools-light” wymaga pewnej wersji komponentu w wersji większej lub równej 6.6.0. (Nie jestem pewien czy chodzi to o wersje ESXi choć nazwa na to wskazuje)

👉 Wnioski i przygotowania do naprawy

Tak wpadłem na dokument KB  , a wg. tego trzeba przeinstalować tools-light na taką odpowiadającą wersji ESXi obecnie zainstalowanego.

Po doczytaniu dokumentu KB  od przywrócenia poprzedniej wersji ESXi wiemy już dlaczego

“Reverting to a previous build does not revert the tools-light vib version installed on the ESXI host”

 

 

4. Wersje jaka była teraz zainstalowana mogłem tylko odczytać poprzez komendę:


esxcli software profile get

ponieważ komenda, która spodziewałbym się ze da mi jakąś odpowiedz nic w tym temacie nie wyświetliła.


esxcli software vib list


Jakby tego VIBa nie było zainstalowanego.

Poszukałem po frazie “tools-light” i znalazłem na dole wyniku “tools-light 10.3.10.12406962-14141615”.

 

Dalej Informacje o tej paczce znalazłem w Release Notes do ESXi 6.7u2 więc uznałem że jestem “w domu”. Można to w tym dokumencie wyszukać po “12406962-14141615”

 

 

Podobną rzecz zrobiłem na poprawnie działającym hoscie w tym samym klastrze:

 

Tutaj też zadziałała i potwierdziła mi znalezisko komenda:


esxcli software vib list


 

 

Tak po wersji build tools-light doszedłem do dokumentu z opisem z jakiego patcha on pochodzi “ESXi650-201805102-SG”

Następnie na podstawie nazwy paczki “ESXi650-201805102-SG” postanowiłem ją sciągnąć na dysk ze strony https://my.vmware.com/group/vmware/patch#search

 

Dalej ściągnięta paczkę wrzuciłem na współdzielony datastore i wróciłem do wiersza poleceń na problematycznym hoście.

I w tym już momencie mogłem przeinstalować wg. KBa tools-light.

 

👉 Implementacja rozwiązania

Na poniższym screenie najpierw zweryfikowałem co się zrobi a następnie wykonałem reinstalacje wskazując na paczkę, którą przed chwilą wrzuciłem na datastore.

 

Dalej zweryfikowałem wersje tools-light zainstalowaną obecnie na ESXi. Oczekiwałem wersji “6.5.0-1.47.8285314”. Tym razem działała komenda:.


esxcli software vib list


Można było też potwierdzić tą samą obecną wersje poprzez komendę:


esxcli software profile get


i wyszukać np po frazie “tools”

Po reinstalacji agent HA “vmware-fdm” odinstalował się bez problemu przez komendę:


esxcli software vib remove -n vmware-fdm


Reszta czynności to co już robiliśmy.

  • wyciągniecie hosta z MMa
  • Wyłączenie HA na klastrze
  • Ponownie włączenie HA na klastrze

 

W tej chwili agent poprawnie zainstalował się na hoscie a żadne błędy nie pojawiły się w GUI.

 

Przez parę minut jeszcze trzeba było poczekać na rekonfigurację NSX. Nie mogły utworzyć się początkowo VTEPy na hoscie.

 

 

 

Po ponownym wejściu w hosta w MM (nie jestem pewien czy to było konieczne) NSX ponowił konfiguracje tym razem z powodzeniem.

Jeśli chciałbyś być na bieżąco i budować swoją wiedzę razem zemną w tematach IT dodaj się do listy mailowej poniżej np.  . Co jakiś czas będę podsyłał Tobie informacje co się dzieje na blogu i w świecie cloud computingu, którym także się zajmuję. Masz jakieś pytania lub myślisz że moglibyśmy zrobić coś razem ? daj znać!

 

Informacje o nowych artykułach, świecie wirtualizacji i "cloud computingu" prosto na Twojego maila:

Dodam Cię do listy mailowej, z której możesz wypisać się w dowolnym momencie (jeden klik.) | Polityka Prywatności