Zaczęło się niewinnie: do zrestartowania kilka serwerów ESXi 3.5. Najlepszą porą na tego typu operacje jest noc, kiedy ewentualne problemy będą zauwazone przez jak najmniejszą liczbę użytkowników, a administrator ma trochę więcej czasu na ich ewentualne rozwiązanie. Aktualizacja poszła gładko na wszystkich serwerach już dużo wcześniej, bo w ESX można ją wykonać bez przestoju maszyn wirtualnych, a obraz hypervisora podmieniany jest dopiero przy następnym restarcie. Prawie wszystkie serwery zrestartowały się bez problemu, ale jak to często bywa, został jeden - ostatni. Z nim tak łatwo już nie było...
Po restarcie maszyny wirtualne wstały, ale data i godzina na hoście ESXi wskazywała 1970-01-01 01:00... Mocno się zdziwiłem, ale fakt ten jeszcze wtedy bardziej działał na moją ciekawość, niż złość. Byłem spokojny, bo nie korzystamy z synchronizacji czasu maszyn wirtualnych z czasem hosta - na kontrolerach domen (które u nas są w całości zwirtualizowane) jest to w ogóle niezalecane przez Microsoft, a na reszcie serwerów i tak powierzamy synchronizację czasu usłudze Win32Time, żeby zachować prawidłową hierarchię w domenie i jej nie dublować. Okazało się jednak, że pomimo wyłączenia synchronizacji czasu hosta i maszyn wirtualnych w ustawieniach VMware Tools taka synchronizacja mimo tego nastąpiła na wszystkich systemach, które pracują na tym jednym feralnym hoście. Pech chciał, że pracował tam kontroler domeny pełniący rolę Primary Domain Controller, a więc będący autorytatywnym źródłem czasu w całej domenie... i dalej można się już chyba domyślić.
Efekt był niemal błyskawiczny, w ciągu dosłownie kilku minut nawet mój notebook podłączony przez VPN zmienił datę i godzinę. Na dodatek prawdopodobnie przez różnice w interpretacji dat pomiędzy ESXi a systemem Windows, data na laptopie była przesunięta o 100 lat do przodu, czyli był rok 2070. Z uwagi na architekturę protokołu Kerberos praca w sieci stała się praktycznie niemożliwa, na dodatek wszystkie certyfikaty nagle straciły ważność, kontrolery przestały pomiędzy sobą rozmawiać i ogólnie doszło do tego, że nie mogłem nigdzie się zalogować na swoje konto domenowe - nawet na konsoli serwera.
Próba ustawienia czasu na tym jednym złośliwym ESXi na właściwy zakończyła się niepowodzeniem, każde kliknięcie w konsoli VI Client skutkowało dziwnymi komunikatami o błędach. Nie pomogło nawet ustawienie czasu synchronizowanego z zewnętrznym serwerem NTP, a na dodatek zegar stał w miejscu - cały czas był 1970-01-01 01:00! Wreszcie po wielu dość mało racjonalnych czynnościach takich jak wielokrotne restartowanie usługi NTP, wylogowywanie i logowanie ponowne do VI Clienta itp. oraz aktualizacji VMware Tools na kontrolerze PDC udało się wreszcie sprawić, że czas podstawowego kontrolera nie był już synchronizowany z hostem. Wtedy wystarczyło polecenie w32tm /resync, by wszystko wróciło do normy... Gwoli ścisłości dodam tylko, że synchronizacja czasu z hostem w ustawieniach VMware Tools była cały czas wyłączona.
Co to zatem było? Nie wiem, pozostaje to dla mnie zagadką. Najgorsze jest to, że na wspomnianym hoście ESXi nadal czas stoi w miejscu - po ustawieniu go dzisiaj rano na właściwy (co dziwne, udało się to bez problemu - hm...) zegar nie działa. Nie pomaga nawet ustawienie serwera NTP - czas synchronizuje się po uruchomieniu usługi, ale nie zwiększa się. Coś jest więc ewidentnie nie tak, niestety na razie nie wiem co... Może ktoś z Was ma jakiś pomysł?