Системное время продолжает сбрасываться на 4 часа в прошлом событии, хотя часовой пояс правильный и время синхронизируется

У меня есть 32-разрядный сервер Windows 2008, работающий в среде ESX.

Я могу вручную синхронизировать время с сервером времени (time.microsoft.com, tick.gatech.edu или любым другим сервером времени), и время будет правильно установлено и отображаться в часах на панели задач. Я также правильно устанавливаю часовой пояс на Восточное время - с поправкой на летнее время.

На данный момент все выглядит хорошо.

Однако, если я перезапущу систему, системные часы будут установлены на 4 часа раньше. (то есть 16:00 в реальном времени становится в системе 12:00).

Затем мне нужно либо принудительно выполнить повторную синхронизацию времени, либо вручную установить время на правильный час. На минуты это не влияет - но время устанавливается ровно на 4 часа назад.

Это сводит меня с ума, и я ищу решение. К сожалению, несколько ключевых задач на этом сервере зависят от времени, и это вызывает настоящую проблему.

Я дважды проверил, что VMtools не настроен на синхронизацию часов с сервером ESX.

Спасибо за любую помощь.

На прошлой неделе у нас была точная проблема. Оказывается, время хоста ESX действительно имеет значение, поскольку именно с него запускается сервер при его сбросе (что мы узнали после перезагрузки патча Microsoft). Что было действительно подозрительно, так это то, что после перезагрузки он продолжал сбрасываться до той же шкалы времени. В вашем случае это now-4h, в нашем случае это Now-42days. Как только мы выровняли время хоста ESX, он прекратил это делать, и обычная синхронизация времени Windows смогла сохранить его вовремя.

@ScottWarren - Вы правы, это долгосрочное решение. Однако я хотел найти время, чтобы полностью объяснить, почему это происходит в первую очередь, чтобы другие пользователи знали, почему это происходит с ними.

Помните - в инструментах VM в клиенте я выбрал, что клиент НЕ должен синхронизировать системное время с хостом ESX, однако это все еще происходило.

Причина этого объясняется в KB 1189 от VMWare.

Обычно есть два случая, когда виртуальная машина проигнорирует ваш запрос на запрет гостевой синхронизации с хостом ESX:

Когда вы приостанавливаете работу виртуальной машины, в следующий раз, когда вы возобновляете работу этой виртуальной машины, она синхронизирует время, чтобы настроить его на хост.
Время повторно синхронизируется, когда вы переносите виртуальную машину с помощью VMotion, выполняете контрольную точку, восстанавливаете контрольную точку, сжимаете виртуальный диск или перезапускаете службу инструментов на виртуальной машине (включая перезагрузку виртуальной машины).

Вот почему эта система сбрасывала время при каждой перезагрузке. Странно, что VMware игнорирует запрос пользователя о том, чтобы этого не произошло, но теперь у меня есть полное представление о том, как и почему это происходило.

В этом случае я видел разницу во времени из-за новой установки ESXi 4.1 в нашей среде. На новом сервере не было настроек NTP, поэтому он передавал клиентам неверную информацию о времени.

У меня тоже была такая же проблема несколько дней назад. Суть в том, что время ESX должно быть правильным, или BIOS (представленный хостом ESX) показывает неправильное время после каждой перезагрузки, что не соответствует времени в Windows. Если разница во времени слишком велика, w32tm не сможет синхронизироваться.

Лучше всего исправить время на хосте ESX, но если вы не можете этого сделать, вы всегда можете изменить максимальную коррекцию фазы (Статья в MS KB) на большее число (по умолчанию всего 5 минут), что позволит вам выполнить синхронизацию при условии, что вы находитесь ... хотя здесь есть потенциальные негативные последствия, если вы установите это большое число (прочтите примечания к статье kb для примеров)