ESXi i vSphere po aktualizacji: najczęstsze błędy, checklisty i szybki plan powrotu

Cel administratora po aktualizacji ESXi i vSphere

Administrator infrastruktury VMware chce mieć aktualne, bezpieczne i wspierane środowisko, ale bez niespodziewanego przestoju, utraty danych ani długiej nocy w serwerowni. Chodzi o to, aby proces aktualizacji ESXi i vSphere był przewidywalny, udokumentowany oraz miał gotowy, przećwiczony plan powrotu do stanu sprzed zmian.

Frazy kluczowe powiązane z tematem: aktualizacja ESXi krok po kroku, aktualizacja vCenter i vSphere, najczęstsze błędy po upgrade ESXi, checklista przed aktualizacją vSphere, backup i snapshoty maszyn wirtualnych, rollback i downgrade ESXi, kompatybilność sprzętu HCL VMware, problemy z siecią po aktualizacji, błędy storage i datastore po upgrade, plan przywracania vCenter po aktualizacji.

Po co aktualizować ESXi i vSphere – zysk vs ryzyko

Realne korzyści z aktualizacji ESXi i vSphere

Aktualizacja ESXi i vSphere to nie tylko „nowe guziki w konsoli”. W praktyce najważniejsze korzyści są cztery: bezpieczeństwo, wsparcie producenta, poprawki błędów oraz wydajność. W kontekście bezpieczeństwa nowe wersje łatają podatności, które są publicznie znane i często zautomatyzowane w narzędziach atakujących. Utrzymywanie starej wersji hypervisora i vCenter to zaproszenie do problemów, zwłaszcza gdy vCenter jest wystawiony do sieci administracyjnej o szerokim zasięgu.

Wsparcie to druga, często niedoceniana kwestia. Gdy środowisko jest poza supportem (EoGS/EoL), zarówno VMware, jak i vendorzy sprzętu mogą odmówić pomocy lub ograniczyć ją do „best effort”. W krytycznych incydentach każdy dzień bez pełnego wsparcia oznacza potencjalne straty biznesowe. Aktualizacja vSphere do wspieranych wersji przywraca pełne prawo do zgłaszania SR-ów (Service Request) i korzystania z bazy wiedzy z konkretnymi poprawkami.

Nowe funkcje i wydajność często schodzą na drugi plan, dopóki nie zostaną potrzebne. vSphere kolejnymi wydaniami wprowadza usprawnienia w DRS, HA, vMotion, obsłudze sprzętu, a także nowe możliwości integracji z backupem czy monitoringiem. Dobrze zaplanowany upgrade może ułatwić automatyzację, uprościć zarządzanie i otworzyć drogę do późniejszych projektów (np. NSX, vSAN, chmura hybrydowa).

Lęki administratorów związane z upgrade’em

Obawy przed aktualizacją ESXi i vSphere są w większości uzasadnione. Najczęściej pojawiają się trzy scenariusze: długotrwały downtime, utrata konfiguracji oraz nieprzewidziane błędy po aktualizacji. Każdy, kto kiedyś „uwalił” vCenter w nocy z piątku na sobotę, dobrze wie, jak wygląda weekend z ręcznym podłączaniem hostów ESXi i odtwarzaniem klastrów.

Downtime to realny koszt biznesowy. Jeśli na klastrze vSphere działa produkcyjny ERP, system płatności lub serwis, który musi być dostępny 24/7, nawet krótkie przerwy są problemem. Obawa wynika też z niewiedzy: ile czasu potrwa aktualizacja vCenter, jak zachowa się DRS, czy HA nie zrestartuje wirtualek niepotrzebnie. Tu pomaga precyzyjne okno serwisowe i jasna komunikacja z biznesem.

Utrata konfiguracji albo konieczność odtwarzania wszystkiego „z pamięci” to drugi koszmar. Gdy nie ma kopii konfiguracji hostów ESXi, backupu vCenter ani aktualnej dokumentacji VLAN-ów i datastore’ów, każdy rollback zajmuje wielokrotnie więcej czasu. Trzeci element to niespodziewane bugi – błędy w sterownikach, niekompatybilne pluginy, kapryśne API dla systemów backupu. Tego nie da się wyeliminować całkowicie, ale da się mocno ograniczyć przez testy i analizę kompatybilności.

Aktualizacje krytyczne a „nice to have”

Nie każda aktualizacja ESXi czy vCenter jest tak samo pilna. Dobrym podejściem jest podział na:

• aktualizacje krytyczne bezpieczeństwa – łaty na podatności z wysokim CVSS, exploity „in the wild”;
• aktualizacje utrzymaniowe – poprawki błędów, stabilność, pełne wsparcie od vendorów;
• aktualizacje funkcjonalne – nowe funkcje, zmiany UI, optymalizacje nie wpływające na krytyczne ryzyka.

Aktualizacje krytyczne są z reguły „must have” i nie powinny czekać w nieskończoność. Wymagają dobranego terminu, ale zbyt długie odkładanie często jest bardziej ryzykowne niż sam upgrade. Aktualizacje utrzymaniowe warto planować cyklicznie, łącząc je z innymi pracami serwisowymi.

Nowe funkcje (np. nowy widok w vSphere Client, dodatkowe opcje w DRS) to „nice to have”. Ich wdrażanie można zaplanować po stronie mniej krytycznych klastrów, a dopiero potem w produkcji. Pomaga to sprawdzić, jak ekipa administratorska czuje się w nowym interfejsie, czy automatyzacje i skrypty nadal działają.

Kiedy lepiej nie aktualizować ESXi i vSphere

Są momenty, kiedy rozsądniej jest wstrzymać się z aktualizacją ESXi i vSphere, nawet jeśli nowa wersja kusi na horyzoncie. Klasyczne przykłady to:

• ogłoszony freeze change – okres w organizacji, gdy zabronione są zmiany w krytycznych systemach (np. koniec roku, sezon rozliczeniowy);
• okresy szczytowe – nagłe skoki obciążenia (Black Friday, koniec kwartału w firmach finansowych, duże kampanie marketingowe);
• brak sprawdzonego backupu – backup istnieje tylko „na papierze” albo nigdy nie testowano odtwarzania;
• brak okna serwisowego – biznes oczekuje pełnej dostępności, ale nie akceptuje formalnie żadnego downtime’u.

Jeśli chociaż jeden z tych punktów jest spełniony, lepiej skupić się na przygotowaniach: poprawie backupów, testach w środowisku testowym, dopięciu procesu komunikacji i zgód. Awaryjna aktualizacja ESXi w nieprzemyślanym momencie często obraca się przeciwko zespołowi IT.

Przygotowanie środowiska – fundament bezbolesnego upgrade’u

Inwentaryzacja: co faktycznie działa w środku

Solidny upgrade zaczyna się od trzeźwego spojrzenia na to, co naprawdę działa w środowisku. Minimalna inwentaryzacja przed aktualizacją ESXi i vSphere powinna objąć:

• listę hostów ESXi z wersjami buildów, licencjami i rolami (np. klastry produkcyjne, testowe, DMZ);
• wersję i typ vCenter (VCSA vs Windows, topologia SSO/PSC);
• pluginy i integracje w vSphere Client (backup – Veeam/Commvault/Rubrik, monitoring, narzędzia vendorów storage);
• systemy monitorujące (Zabbix, vROps, inne NMS) – czy mają integrację z vCenter, API, alarmy;
• integracje z SIEM (logi z hostów ESXi, vCenter, NSX, vSAN).

Najprościej zebrać dane z vSphere Client oraz PowerCLI. Skrypty mogą wyeksportować listę hostów, wersje, konfigurację sieci i datastore’ów. To jednocześnie wstępna dokumentacja stanu przed upgrade’em. W małych środowiskach wystarczy aktualny zrzut ekranu z konfiguracji klastrów i opis VLAN-ów, w większych – plik w repozytorium z wersjonowaniem.

Dodatkowo warto osobno wypisać wszystkie integracje „z zewnątrz”: kto komunikuje się z vCenter (backup, CMDB, orkiestracja, systemy biletowe). Te elementy najczęściej zawodzą po zmianie wersji vCenter lub po wymianie certyfikatów.

Licencje i wsparcie producenta

Przed aktualizacją trzeba sprawdzić, czy licencje i wsparcie nadążają za planowaną wersją vSphere. Kluczowe punkty:

• ważność kontraktów SnS (Support and Subscription) dla VMware – bez tego dostęp do nowych wersji i wsparcia może być ograniczony;
• licencje vSphere/vCenter – czy obejmują docelową wersję (przy dużych skokach wersji bywa konieczna zmiana typu licencji);
• wsparcie vendorów sprzętu (serwery, macierze) – czy planowana wersja ESXi jest wspierana na danym modelu.

Niekiedy drobny szczegół, jak wygasły SnS, potrafi zatrzymać upgrade w połowie: dostęp do plików ISO jest, ale VMware odmawia wsparcia przy krytycznym błędzie. Warto wcześniej skontaktować się z partnerem lub bezpośrednio z VMware i upewnić się, że środowisko ma pełne prawo do wsparcia zestawione z planowaną wersją.

Zależności między komponentami platformy

Infrastruktura wirtualna to nie tylko ESXi i vCenter. W typowej organizacji dochodzą:

• NSX (sieć wirtualna, mikrosegmentacja);
• vSAN (storage rozproszony);
• Horizon (VDI);
• Site Recovery Manager (DR/BCP);
• vRealize/vROps (monitoring, automatyzacja);
• systemy backupu integrujące się przez VADP/CBT.

Między tymi komponentami istnieje konkretna matryca zależności wersji. Przykład: niektóre wersje NSX wspierają tylko wybrane wydania vSphere. Podobnie vSAN wymaga minimalnej wersji ESXi na hostach. Przed aktualizacją należy ułożyć łańcuch wersji: od vCenter, przez ESXi, po NSX, vSAN i narzędzia do backupu.

Brak tej analizy kończy się sytuacją, w której po udanym upgrade vCenter plugin SRM przestaje działać, a system backupu nie widzi już listy VM. Zamiast tego lepiej przejrzeć dokumentację „Interoperability” VMware i vendorów, zapisać wspierane kombinacje i dopasować do nich plan upgrade’u.

Dokumentacja stanu wyjściowego

Im lepiej udokumentowany jest stan przed aktualizacją, tym łatwiej wrócić do niego w razie rollbacku lub odtworzyć konfigurację po awarii. Minimalny pakiet dokumentacji obejmuje:

• topologię klastrów vSphere (hosty, role, DRS/HA, lokalizacje datacenter/fault domains);
• konfigurację sieci wirtualnej (vSwitch/vDS, portgroupy, VLAN ID, MTU, teaming, uplinki);
• listę datastore’ów (typ, rozmiar, lokalizacja, macierz, NFS/iSCSI/FC, vSAN);
• wersje firmware i BIOS/UEFI serwerów hostujących ESXi;
• konfigurację vCenter (topologia SSO, PSC, certyfikaty, integracje z AD/LDAP, role i uprawnienia).

Najprościej trzymać te informacje w repozytorium (Git, system dokumentacji), z datą, wersją i krótkim opisem. Taki dokument służy później jako punkt odniesienia przy sprawdzaniu, czy po aktualizacji wszystko wróciło do normy. Pomaga też nowym administratorom szybko zrozumieć, co zastali.

Kompatybilność i planowanie wersji – jak nie ustrzelić własnej infrastruktury

VMware Compatibility Guide (HCL) w praktyce

Kompatybilność jest kluczowa. Potężny host z dużą ilością RAM i CPU jest bezużyteczny, jeśli nowa wersja ESXi nie jest oficjalnie wspierana na jego modelu. Do sprawdzania zgodności służy VMware Compatibility Guide (HCL). Wyszukuje się:

• modele serwerów (vendor, generacja, konfiguracja CPU);
• karty sieciowe (NIC) – modele, sterowniki, firmware;
• HBA (Fibre Channel, iSCSI) i karty RAID;
• macierze i storage (np. profile dla vSAN).

Przed aktualizacją do konkretnej wersji ESXi warto jasno odpowiedzieć na pytanie: czy wszystkie serwery na liście hostów są wspierane dla tego wydania? Jeśli nie, są trzy opcje: wymiana sprzętu, pozostanie na niższej wersji ESXi dla części hostów lub odłożenie upgrade’u do czasu zaplanowania modernizacji hardware’u.

Ignorowanie HCL bywa kuszące („u nas działa”), ale niesie realne konsekwencje: brak wsparcia, dziwne błędy sterowników, a w skrajnych przypadkach utratę dostępu do storage czy sieci przy dużych obciążeniach.

Matryca zgodności: vCenter, ESXi i dodatki

Poza HCL konieczna jest matryca zgodności wersji produktów VMware. VMware publikuje narzędzia „Interoperability Matrix”, gdzie można sprawdzić, jakie wersje vCenter współpracują z jakimi wersjami ESXi, NSX, vSAN, SRM, Horizon czy vROps.

Dla planu aktualizacji warto przygotować prostą tabelę, ułatwiającą podjęcie decyzji:

Taka tabela pozwala szybko wychwycić wąskie gardła. Jeśli jeden komponent „ciągnie w dół” całą resztę (np. stary NSX lub backup), decyzja brzmi: aktualizujemy go najpierw albo projekt upgrade’u vSphere przesuwamy.

Ścieżki upgrade’u i ograniczenia „skoków” wersji

Nie każdą wersję vSphere można przeskoczyć bezpośrednio do najnowszej. Istnieją wspierane ścieżki upgrade’u, które wymuszają pośrednie kroki (np. z vCenter 6.0 najpierw do 6.7, a dopiero potem do 7/8, w zależności od konkretnej kombinacji). To samo dotyczy hostów ESXi oraz dodatków (NSX, SRM, Horizon).

Przykładowe ograniczenia, które często wychodzą w praniu:

• brak wsparcia bezpośredniego upgrade’u z bardzo starej wersji vCenter do bieżącej – wymagany „przystanek pośredni”;
• konieczność podniesienia poziomu vSphere Distributed Switch (vDS) w kilku krokach, aby nie stracić kompatybilności ze starszymi hostami;
• ograniczenia przy migracji vCenter Windows do VCSA – określone minimalne buildy, z których można migrować;
• NSX w starszej linii (np. NSX-V) wspierany tylko do konkretnej wersji vSphere – później wymagana migracja do NSX-T.

Przed wyborem wersji docelowej dobrze jest zbudować prosty diagram: z jakich wersji startujemy, do jakich możemy legalnie dojść, jakie pośrednie kroki są konieczne. To pośrednio definiuje harmonogram i liczbę okien serwisowych.

Strategia aktualizacji: kolejność, okna serwisowe, środowisko testowe

Logika kolejności: od góry do dołu

Przy aktualizacji całego stosu wirtualizacji stosuje się zasadę: najpierw komponenty zarządzające, potem data plane. W praktyce oznacza to:

1. aktualizacja narzędzi zarządzających i monitoringu (backup, vROps, integracje z CMDB);
2. upgrade vCenter (oraz powiązanych komponentów SSO/PSC);
3. aktualizacja NSX / vSAN / SRM (jeśli występują);
4. upgrade hostów ESXi w klastrach (najpierw testowe / mniej krytyczne, potem produkcja);
5. aktualizacja VMware Tools i VM hardware w maszynach wirtualnych.

Odwrócenie logicznej kolejności (np. podniesienie hostów przed vCenter) zwykle kończy się ograniczeniami funkcjonalnymi, błędami w klientach lub koniecznością ręcznego zarządzania hostami przez Direct Console / SSH.

Okna serwisowe: negocjacja z biznesem

Małe środowiska często narzekają, że „nie ma okien serwisowych”. W praktyce okno trzeba zaprojektować i sprytnie sprzedać biznesowi. Pomaga konkretna propozycja:

• jasny zakres – które klastry, które aplikacje, czy przewidywany jest pełny czy częściowy downtime;
• dokładne ramy czasowe – od godziny do godziny, z marginesem na rollback;
• opis korzyści – np. usunięcie znanych bugów, wsparcie dla nowych funkcji HA/DRS, wymóg podniesienia wersji przez dostawcę oprogramowania;
• plan komunikacji – kto i kiedy dostanie informację o rozpoczęciu, zakończeniu, ewentualnym wydłużeniu prac.

Dobrym trikiem jest rozbicie dużej aktualizacji na kilka mniejszych okien: najpierw klaster testowy, potem mniej krytyczne systemy, na końcu core biznes. Dzięki temu rośnie zaufanie do procesu – po pierwszym udanym oknie łatwiej uzyskać zgodę na kolejne.

Środowisko testowe: minimum, które ma sens

Nie każde przedsiębiorstwo ma pełne, odseparowane środowisko testowe 1:1 z produkcją. Da się jednak zbudować sensowny poligon nawet z ograniczonych zasobów. Przykładowy schemat:

• osobny klaster testowy (choćby 2 hosty) z osobnym vCenter lub osobnym Datacenter w istniejącym vCenter;
• kilka krytycznych aplikacji sklonowanych z produkcji (lub zainstalowanych w wersji „demo”) podpiętych do tych samych typów storage i VLAN-ów;
• kopie konfiguracji NSX/vSAN/SRM (jeśli występują);
• testowa instancja systemu backupowego, podpinająca się do testowego vCenter.

W takim środowisku można „przejechać” całą ścieżkę upgrade’u: vCenter, ESXi, integracje, backup, a na końcu testy aplikacyjne (np. logowanie do ERP, generowanie raportu, test transakcji). Lepiej wyłapać niekompatybilny plugin backupu czy błąd sterownika NIC na testach niż na krytycznym klastrze.

Strategia stopniowa vs „big bang”

Przy większych środowiskach aktualizacja „big bang” (całość w jedno okno) jest ryzykowna. Bezpieczniej podzielić projekt na fale:

1. fala 1 – środowisko testowe i/lub lab; weryfikacja ścieżki; poprawki do procedur;
2. fala 2 – mniej krytyczne klastry (np. Dev/UAT); zderzenie z realnym obciążeniem;
3. fala 3 – klastry produkcyjne, zaczynając od tych o mniejszym wpływie na biznes;
4. fala 4 – core biznes + DR (SRM, replikacje); ostatni etap po pełnej weryfikacji wcześniejszych kroków.

Po każdej fali potrzebny jest krótki przegląd: co poszło dobrze, co wymaga zmiany w playbooku. To nie musi być formalne spotkanie z dziesiątkami osób. Wystarczy dokument z aktualizacją checklist i parę zdań w systemie ticketowym.

Checklista przed aktualizacją ESXi i vSphere – minimum, bez którego lepiej nie zaczynać

Backup i plan powrotu (rollback)

Backup to nie tylko „mamy VM w Veeamie”. Przed upgrade’em potrzebne są konkretne kroki:

• pełny backup vCenter (VCSA – file-based backup + snapshot/appliance backup, vCenter na Windows – backup bazy + VM);
• snapshoty konfiguracji hostów ESXi (np. export profile, esxcli, host profiles, backup plików konfiguracyjnych);
• backup konfiguracji NSX/vSAN/SRM (jeśli zastosowane);
• backup bazy systemu backupowego (tak, system backupu też wymaga backupu);
• sprawdzone przywracanie przynajmniej raz – nawet na małej maszynie testowej.

Plan powrotu nie może ograniczać się do zdania „odtworzymy z backupu”. Powinien zawierać jasno określone warianty:

• rollback vCenter – jak przywracamy appliance/bazę, jak odtwarzamy certyfikaty i rejestrujemy hosty z powrotem;
• rollback ESXi – czy cofamy się snapshotem, czy przeinstalowujemy hosta i odtwarzamy konfigurację z host profiles / backupu;
• rollback integracji – np. powrót do poprzedniej wersji backupu lub pluginu, jeśli nowy przestaje działać.

W małej firmie mieliśmy sytuację, w której vCenter po aktualizacji nie chciał wystartować przez uszkodzone rozszerzenie. Decyzja: powrót do backupu appliance sprzed upgrade’u. Cała operacja zajęła kilkadziesiąt minut, bo scenariusz rollbacku był wcześniej przećwiczony na labie.

Weryfikacja kompatybilności narzędzi backupu i monitoringu

Narzędzia backupowe i monitoringowe są pierwszymi ofiarami różnic w API między wersjami vSphere. Przed podniesieniem vCenter i ESXi trzeba sprawdzić:

• czy wersja backupu (Veeam/Commvault/Rubrik itp.) wspiera docelową wersję vSphere;
• czy wymagane jest wcześniejsze podniesienie backupu do nowszej wersji;
• czy pluginy vSphere Client / Web Client i agenci monitoringu mają wersje zgodne z nowym vCenter;
• czy dostawca backupu publikuje znane problemy (KB) dla planowanej wersji vSphere.

Niedopasowanie tych komponentów kończy się brakiem możliwości wykonywania backupów po aktualizacji lub cichymi błędami (np. nie działający CBT). Potem przy pierwszej awarii wychodzi na jaw, że backupy są nieużywalne.

Sprawdzenie stanu klastrów: HA, DRS, vSAN

Przed uruchomieniem procedury upgrade’u trzeba mieć pewność, że stan wyjściowy klastra jest zdrowy:

• wszystkie hosty w klastrze są w statusie Connected i nie mają aktywnych błędów krytycznych;
• HA nie zgłasza problemów z agentami na hostach; brak izolowanych węzłów;
• DRS (jeśli w użyciu) działa poprawnie i nie ma „stuck” migracji vMotion;
• vSAN (jeśli obecny) ma status Healthy, bez komponentów w stanie „Degraded” i bez długotrwałej rebalance/resync.

Aktualizacja na klastrze z istniejącymi błędami może je tylko pogłębić lub utrudnić diagnozę po zmianie wersji. Dobry nawyk: przed każdym dużym oknem serwisowym robić krótki „health check” i dokumentować wyniki (zrzuty ekranu, eksport raportów).

Stabilność storage i sieci

ESXi i vSphere są wrażliwe na problemy w warstwie storage i sieci. Przed upgrade’em trzeba sprawdzić co najmniej:

• logi macierzy i przełączników SAN – brak powtarzających się błędów, timeoutów, resetów portów;
• konfigurację ścieżek (multipathing) – czy wszystkie ścieżki są aktywne i w prawidłowym stanie;
• opóźnienia i błędy w sieci VMkernel (vMotion, iSCSI, NFS, vSAN);
• spójność konfiguracji vSwitch / vDS – takie same VLAN ID, MTU, teaming na wszystkich hostach.

Aktualizacja hosta na tle niestabilnego storage często kończy się błędami podczas restartu usług, utratą datastore’ów lub zawieszonymi VM. Takie problemy są później mylone z błędami nowej wersji ESXi, choć przyczyna tkwi poziom niżej.

Komunikacja i eskalacje

Przed startem prac trzeba ustalić, kto jest kim w razie problemów:

• osoba odpowiedzialna technicznie za upgrade (lead);
• kanał komunikacji w zespole (Teams/Slack/mostek telefoniczny) na czas prac;
• kontakty do vendorów (VMware, producenci macierzy, dostawca backupu) z aktywnymi numerami kontraktów;
• procedura eskalacji – po jakim czasie od pojawienia się krytycznego błędu podejmowana jest decyzja o rollbacku.

Dobrą praktyką jest przygotowanie krótkiego dokumentu dla biznesu: co robimy, w jakich godzinach, co uznajemy za „poważny problem” i kiedy w takim przypadku cofamy zmiany. Pozwala to uniknąć sporów w trakcie awarii.

Przebieg aktualizacji vCenter i ESXi – praktyczne ścieżki i decyzje

Upgrade vCenter: in-place, migracja czy nowa instalacja

Przy vCenter są trzy główne scenariusze:

• upgrade in-place VCSA do nowszej wersji – standard dla aktualnych środowisk;
• migracja starego vCenter na Windows do VCSA – konieczna, bo linia Windows jest wygaszona;
• nowa instalacja VCSA i ręczne przeniesienie konfiguracji – np. przy „posprzątaniu” starego, mocno zanieczyszczonego środowiska.

Scenariusz wybiera się na podstawie wieku, stanu i skomplikowania obecnego vCenter. Jeśli instancja ma lata historii, mnóstwo starych pluginów, niewiadome integracje – nowa instalacja bywa czystszym podejściem, choć wymaga więcej pracy przy rekonfiguracji.

Kluczowe kroki przy aktualizacji VCSA

Dla typowego upgrade’u VCSA (z GUI lub ISO) sekwencja jest podobna:

1. backup VCSA (file-based + snapshot VM, jeśli polityka na to pozwala);
2. sprawdzenie miejsca na datastore’ze i w bazie (vCenter potrafi odmówić upgrade’u przy braku przestrzeni);
3. wyłączenie niekrytycznych pluginów / rozszerzeń (szczególnie vendor-specific);
4. uruchomienie instalatora / upgrade’u (Stage 1 – deployment nowej maszyny, Stage 2 – migracja danych);
5. weryfikacja dostępu – logowanie do vSphere Client, sprawdzenie statusu usług;
6. sprawdzenie rejestracji hostów ESXi i podstawowych funkcji (vMotion, HA, DRS).

Dobrym zwyczajem jest też szybkie przejrzenie logów po upgrade (np. /var/log/vmware/vsphere-ui/, /var/log/vmware/vpxd/) oraz statusu certyfikatów. Przy błędach w certyfikacji bardzo szybko przestają działać integracje zewnętrzne.

Aktualizacja hostów ESXi: vLCM, Update Manager czy ręcznie

Obecnie dominują trzy metody aktualizacji ESXi:

• vSphere Lifecycle Manager (vLCM) – nowoczesne podejście oparte o image, sensowne przy standardyzacji hostów;
• vSphere Update Manager (VUM) – starszy mechanizm oparty o baselines, wciąż spotykany w wielu środowiskach;
• ręczna aktualizacja – z ISO, offline bundle, przez iLO/IMM/IDRAC lub boot z ISO.

Plusy i minusy poszczególnych metod aktualizacji ESXi

Każda metoda ma swoje zastosowania. Zestawienie w praktycznym ujęciu:

• vLCM:
  • plusy: standaryzacja hostów, jednolity image (ESXi + sterowniki + firmware), łatwiejsze utrzymanie zgodności z HCL;
  • minusy: wymaga uporządkowanego sprzętu (podobne modele hostów), przy mieszance hardware’u bywa kłopotliwy; nie zawsze od razu „dogada się” z integracjami vendorów.
• VUM:
  • plusy: dobrze znany, elastyczny, sprawdza się w środowiskach z różnymi modelami serwerów;
  • minusy: trudniejsza kontrola spójności sterowników/firmware, łatwiej o drobne różnice między hostami.
• ręczna aktualizacja:
  • plusy: pełna kontrola, dobre do pojedynczych hostów, labów, sytuacji awaryjnych;
  • minusy: mała skalowalność, większe ryzyko „ludzkiego” błędu, trudniejsza automatyzacja.

Przy kilku hostach w jednym klastrze ręczne podejście jeszcze przejdzie. Przy kilkudziesięciu – bez vLCM/VUM bardzo szybko pojawi się chaos konfiguracyjny.

Standardowa sekwencja aktualizacji hosta ESXi w klastrze

Bez względu na narzędzie, ogólny schemat dla jednego hosta jest podobny:

1. sprawdzenie stanu hosta (brak alarmów, poprawne połączenie z vCenter);
2. ewakuacja maszyn (vMotion) na inne hosty;
3. przełączenie hosta w Maintenance Mode;
4. wykonanie aktualizacji (vLCM/VUM/offline bundle/ISO);
5. restart hosta;
6. weryfikacja logów i podstawowych funkcji (storage, sieć, vMotion);
7. wyjście z Maintenance Mode i stopniowe przywrócenie obciążenia.

Istotne, aby w jednym czasie nie „wycinać” z klastra zbyt wielu hostów. HA musi mieć gdzie przenieść maszyny przy ewentualnych problemach. Przy klastrach 3-node zazwyczaj aktualizuje się tylko jeden host naraz.

Specyfika aktualizacji hostów z vSAN

Przy vSAN drobny błąd w planowaniu może skończyć się niedostępnością danych. Dlatego sekwencja musi brać pod uwagę stan klastrów storage’owych:

• przed startem – sprawdzenie vSAN Health i Resyncing Objects (brak trwających dużych resynców);
• włączenie vSAN Maintenance Mode na hostach z odpowiednią opcją (najczęściej „Ensure accessibility” albo „Full data migration” – zależnie od poziomów redundancji i okna);
• aktualizacja jednego hosta na raz, szczególnie w małych klastrach (3–4 nody);
• po aktualizacji – weryfikacja stanu obiektów (brak komponentów w stanie „Absent/Degraded” przez dłuższy czas).

Dobrym zwyczajem jest zaplanowanie większego marginesu czasowego dla klastrów z vSAN. Balansowanie danych po aktualizacji kilku hostów może potrwać, szczególnie w środowisku mocno obciążonym I/O.

Mikro-checklista tuż przed kliknięciem „Upgrade”

Krótki przegląd, który realnie zmniejsza ryzyko:

• potwierdzenie, że jest świeży backup vCenter i konfiguracji hostów;
• sprawdzenie komunikatu w vLCM/VUM – czy nie ma ostrzeżeń o brakujących sterownikach lub niezgodnym firmware;
• weryfikacja wolnego miejsca na lokalnym datastore (logi, zrzuty);
• przygotowany numer SR do VMware (choćby zapisany kontrakt i dane logowania do portalu);
• przypomnienie w zespole: kto decyduje o rollbacku, przy jakich objawach.

Najczęstsze błędy po aktualizacji ESXi – objawy, przyczyny, szybkie diagnozy

Brak dostępu do maszyn wirtualnych po restarcie hostów

Częsty scenariusz: hosty zaktualizowane, klastry „zielone”, ale część VM nie odpowiada. Typowe objawy:

• brak pinga do VM, ale konsola przez vSphere działa;
• VM widzi sieć (np. pinguje bramę), ale nie wychodzi poza jeden VLAN;
• część maszyn z danego hosta działa poprawnie, część nie.

Najczęstsze przyczyny:

• przywrócenie nieprawidłowego profilu vSwitch/vDS przy aktualizacji hosta;
• zmiana sterownika karty sieciowej (np. nowy driver vmnic) z inną obsługą offloadów lub VLAN;
• niezsynchronizowane MTU lub porty trunk na fizycznych przełącznikach.

Szybka diagnoza:

• porównanie konfiguracji sieci (vSwitch/vDS, port groups, VLAN ID, MTU) między hostem z problemem a działającym;
• sprawdzenie logów /var/log/vmkernel.log i /var/log/vobd.log pod kątem błędów sieciowych;
• przepięcie problematycznej VM na inny host (vMotion) – jeśli zadziała, problem leży w host/network, nie w VM.

Problemy ze storage: znikające datastore’y, błędy I/O, „All paths down”

Po aktualizacji hostów zdarzają się kłopoty z dostępem do LUN-ów lub udziałów NFS:

• datastore znika z jednego lub kilku hostów;
• VM logują w systemie gościa błędy I/O, a w vSphere pojawiają się alarmy storage;
• w logach hosta widać komunikaty „APD” (All Paths Down) lub „PDL” (Permanent Device Loss).

Najczęstsze źródła problemu:

• zmiana sterownika HBA lub kolejności ścieżek po aktualizacji;
• niekompatybilny firmware kontrolera z nową wersją ESXi;
• niewspierane już moduły multipath (np. specyficzny plugin vendorowy wycięty w nowej wersji);
• niewłaściwe time-outy/parametry na macierzy niezgodne z rekomendacjami VMware.

Jak szybko zawęzić problem:

• sprawdzić esxcli storage core device list i esxcli storage core path list – czy wszystkie ścieżki są widoczne;
• porównać wersje sterowników i firmware HBA z hostem, który działa poprawnie (jeśli są różnice – mocna wskazówka);
• zajrzeć do logów macierzy i przełączników SAN w czasie aktualizacji (czy nie było resetów portów, zoning changes);
• porównać ustawienia SATP/PSP (policy) dla LUN-ów z rekomendacjami producenta macierzy.

vMotion przestaje działać albo jest bardzo wolny

Objaw zazwyczaj jest wyraźny: migracje trwają znacznie dłużej niż wcześniej, albo kończą się błędami. Do tego często dochodzą:

• komunikaty o niedostępności sieci vMotion lub niespójnych MTU;
• zatrzymujące się migracje w okolicach 14% / 90% (klasyczne punkty problemowe vMotion).

Najczęstsze przyczyny:

• zmienione ustawienia sieci VMkernel (brak zaznaczonej opcji vMotion na nowym interfejsie po rekonfiguracji);
• zmiana sterownika karty sieciowej wpływająca na obsługę jumbo frames;
• różne wersje ESXi z inną implementacją vMotion (najczęściej przy bardzo dużym „skoku” wersji między hostami).

Szybka ścieżka sprawdzenia:

• porównanie konfiguracji VMkernel na wszystkich hostach (adresy, VLAN, MTU, włączone usługi);
• test ping z użyciem dużych pakietów między interfejsami vMotion (vmkping -d -s 8972 dla MTU 9000);
• sprawdzenie logów /var/log/vmkernel.log w czasie nieudanej migracji;
• wykonanie testowego vMotion małej, mało obciążonej VM – czy problem jest ogólny, czy dotyczy tylko ciężkich maszyn.

HA i DRS zachowują się inaczej niż przed aktualizacją

Po podniesieniu wersji vSphere zmieniają się algorytmy i dostępne funkcje HA/DRS. Efekt bywa taki, że:

• DRS zaczyna agresywniej migrować maszyny niż wcześniej;
• HA zgłasza nowe typy ostrzeżeń, których nie było w starej wersji;
• po restarcie hosta maszyny nie „wracają” tam, gdzie się ich spodziewano (np. zmiana zasad affinity).

Źródła problemów:

• zmieniony poziom funkcjonalny klastra (np. Cluster Functional Level po aktualizacji vCenter);
• nowe opcje DRS/HA automatycznie włączone przy konwersji konfiguracji;
• stare reguły affinity/anti-affinity, które w nowej wersji są interpretowane nieco inaczej lub z większym rygorem.

Jak się za to zabrać:

• przejrzeć ustawienia klastra po aktualizacji, zwłaszcza sekcje DRS/HA i Admission Control;
• sprawdzić, czy nie pojawiły się nowe reguły lub zmienione priorytety restartu VM;
• krótkoterminowo – przełączyć DRS na tryb mniej agresywny (np. Balanced) i obserwować obciążenie;
• odczytać opisy nowych alarmów HA – często wskazują konkretną zmianę w logice (np. Datastore Heartbeat).

Problemy z agentami backupu i integracjami tuż po aktualizacji

Nawet jeśli narzędzia backupowe oficjalnie wspierają nową wersję vSphere, po aktualizacji często pojawiają się:

• błędy przy tworzeniu snapshotów (VM Backup Error, „Cannot create quiesced snapshot”);
• nieudane joby backupu tylko dla części maszyn lub jednego klastra;
• komunikaty o nieprawidłowych uprawnieniach konta, które wcześniej działało bez zarzutu.

Najczęstsze powody:

• problem z API (zmienione endpointy, wymagania co do TLS/certyfikatów);
• stary plugin w vCenter, który częściowo działa, ale powoduje błędy w backgroundzie;
• zmiana SID/UUID vCenter przy migracji, przez co system backupu „nie poznaje” instancji.

Szybka diagnostyka:

• sprawdzić, czy system backupowy widzi poprawnie nową wersję vCenter (często w logach lub podsumowaniu konfiguracji);
• przelogować lub przeutworzyć konto serwisowe (czasem wymagana jest aktualizacja tokenów/autoryzacji);
• zrobić testowy backup pojedynczej małej VM z nowo utworzonej polityki – jeśli działa, problem leży w starych jobach/konfiguracji;
• przejrzeć znane problemy (KB) dostawcy backupu dla konkretnej wersji vSphere.

Błędy certyfikatów i problemy z logowaniem do vSphere Client

Po aktualizacji vCenter jednym z pierwszych symptomów kłopotu są:

• ostrzeżenia przeglądarki o nieprawidłowych/niezaufanych certyfikatach (często mocniejsze niż przedtem);
• problemy z logowaniem przy użyciu SSO/AD, mimo że lokalne konto administratora działa;
• niedziałające integracje, które wcześniej korzystały z certyfikatów vCenter (monitoring, backup, portale self-service).

Przyczyny zwykle kręcą się wokół:

• przeładowania lub zmiany Certificate Authority w ramach VCSA;
• certyfikatów wystawionych w innym formacie/algorytmie niż oczekują integracje;
• złego „wiązania” (binding) usług vCenter z nowymi certyfikatami po upgrade.

Co sprawdzić na początku:

• status usług vCenter (VAMI > Services lub service-control --status w CLI);
• sekcję Administration > Certificate Management w vSphere Client – który certyfikat jest aktualnie używany;
• logi /var/log/vmware/vmcad/, /var/log/vmware/vmdird/ – błędy związane z certyfikacją/SSO;
• w przypadku integracji – czy certyfikat CA vCenter (lub zewnętrznego CA) jest zainstalowany w zaufanych repozytoriach tych systemów.

Spadek wydajności VM po aktualizacji ESXi

Nie zawsze po update’cie jest szybciej. Zdarza się, że:

• CPU hostów jest wyraźnie bardziej obciążone przy tym samym workloadzie;
• czas odpowiedzi aplikacji wydłuża się, mimo braku wyraźnych błędów;
• w systemach gości pojawiają się nowe ostrzeżenia w logach (np. sterowniki PV, czas systemowy).

Typowe przyczyny:

• zmiana wersji wirtualnego sprzętu (Virtual Hardware) bez późniejszej aktualizacji VMware Tools;