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ć!
Dodam Cię do listy mailowej, z której możesz wypisać się w dowolnym momencie (jeden klik.) | Polityka Prywatności