Ten serwer vCenter został właśnie zaktualizowany do wersji 5.1 aktualizacji 1. Przechodzę przez hosty i aktualizuję oprogramowanie układowe, a następnie aktualizuję je z różnych wersji 5.0 do 5.1u1.
vCenter 5.1u1 wydaje się mieć ciekawe nowe zachowanie: usuwa hosty z trybu konserwacji, kiedy ponownie się łączą po rozłączeniu - ale bardzo niekonsekwentnie, widziałem to może 4 lub 5 razy przy ~ 25-30 ponownych uruchomieniach hosta. Widziałem to tylko na hostach 5.0, które nie zostały jeszcze uaktualnione do 5.1.
Na obrazie umieściłem hosta w trybie konserwacji i ponownie uruchomiłem go w trybie automatycznej aktualizacji płyty HP SPP DVD. Po zwykłym ~ 40-minutowym procesie aktualizacji host powrócił do trybu online .. i 7 sekund przed zalogowaniem się, że host ponownie się połączył, vCenter wysłał hostowi zadanie wyjścia z trybu konserwacji.
W moim rozumieniu vCenter może tylko opuścić hosta z trybu konserwacji tylko wtedy, gdy vCenter przełączy go w tryb konserwacji (np. Zadanie aktualizacji VUM).
Dlaczego to vCenter jednostronnie wychodzi z hosta z trybu konserwacji inicjowanego przez użytkownika?
Edytuj, dodatkowe informacje:
Uruchomiłem aktualizacje oprogramowania na 5 kolejnych hostach jednocześnie. Dwóch z nich opuściło tryb konserwacji po ponownym połączeniu, trzy nie. Wspólnym czynnikiem wychodzącym z trybu konserwacji wydaje się być czas, przez który byli offline ; dwa, które wymagały kilku prób rozruchu do wirtualnego nośnika, to dwa, które zostały wykluczone z trybu konserwacji.
- esx31 (obrazek powyżej): 45 minut nie odpowiada
- esx19 (wyjście z konserwacji): 87 minut nie odpowiada
- esx24 (pozostał w utrzymaniu): 32 minuty nie odpowiada
- esx29 (pozostał w utrzymaniu): 39 minut nie odpowiada
- esx32 (pozostał w utrzymaniu): 30 minut nie odpowiada
- esx34 (zakończono konserwację): 70 minut nie odpowiada
Edycja: Idea czasu rozłączenia wydaje się być czerwonym śledziem, ponieważ nie dzieje się to konsekwentnie.
Dodatkowo , w vpxd.logwyjściu z trybu konserwacji wydaje się, że inicjowanie zadania zawsze następuje natychmiast po vim.EnvironmentBrowser.queryProvisioningPolicywywołaniu SOAP. Oto linie, lekko przycięte dla jasności:
15:27:49.535 [info 'vpxdvpxdVmomi'] [ClientAdapterBase::InvokeOnSoap] Invoke done (esx31, vim.EnvironmentBrowser.queryProvisioningPolicy)
15:27:49.560 [info 'commonvpxLro'] [VpxLRO] -- BEGIN task -- esx31 -- HostSystem.exitMaintenanceMode --
Pamiętaj, że w węzłach, które nie otrzymują zadania wyjścia, vim.EnvironmentBrowser.queryProvisioningPolicyzdarzenie nadal występuje. Nie widzę żadnych innych różnic w zdarzeniach przed ani po tym w procesie ponownego łączenia, oprócz dodatkowych zdarzeń spowodowanych wychodzeniem z trybu konserwacji.
Biorąc pod uwagę dziennik dotyczący zasad udostępniania, wyszukiwanie problemów związanych z trybem konserwacji związanym z automatycznym wdrażaniem powoduje pojawienie się skarg na podobne zachowanie (chociaż wcale nie korzystam z automatycznego wdrażania).
źródło
Odpowiedzi:
Widziałem, jak to się dzieje z hostami ESXi 4.1 po tym, jak łatka przypadkowo zepsuła folder / tmp / scratch. Możesz sprawdzić, czy ten katalog nadal istnieje na hostach, które automatycznie opuściły tryb konserwacji.
Jeśli ich brakuje, będziesz chciał, aby mkdir je utworzył. Ponadto należy sprawdzić, czy trwałe rysowanie jest poprawnie skonfigurowane na każdym hoście, postępując zgodnie z tym artykułem z bazy wiedzy VMware:
VMware KB: Tworzenie trwałej lokalizacji scratch dla ESXi 4.xi 5.x
źródło