VMware — отклонение времени при миграции виртуальной машины

Олег

15 сентября 2026

Миграция виртуальной машины может привести к отставанию часов гостевой операционной системы от реального времени.

При миграции виртуальной машины её механизм отсчёта времени временно замораживается, поскольку она приостанавливается, копируется и возобновляется на целевом хосте. Это приводит к отставанию часов гостевой операционной системы от реального времени, часто на десятки или даже сотни миллисекунд.

Вручную можно пнуть синхронизацию времени, используя опцию конфигурации iburst (ntp.conf) гостевой ОС. Это отправляет серию сообщений NTP, обрабатывая данные гораздо быстрее, чтобы сократить начальную задержку при установке часов.

server ntp-1.example.com iburst

Можно уменьшить интервал опроса сообщений NTP для корректировки системных часов (опции minpoll и maxpoll). Хотя использование этих опций с общей инфраструктурой NTP (например, с NTP-серверами в интернете) считается не лучшей практикой, они полезны, если у вас есть выделенные внутренние серверы времени.

server ntp-1.example.com minpoll 4 maxpoll 4

Если корректировки NTP окажутся недостаточными для смягчения последствий разницы во времени из-за миграции виртуальной машины, настройте одноразовую синхронизацию времени VMware Tools с более низким пороговым значением.

Например, если вы хотите, чтобы гостевые часы синхронизировались с хостом всякий раз, когда время отстаёт более чем на 100 миллисекунд после миграции, добавьте это в ваш vmx-файл:

pref.timeLagInMilliseconds = 100

По умолчанию стоит 1000. В случае внешнего решения PTP рекомендуется добавить Precision Clock на виртуальную машину.

Если в гостевой ОС настроен NTP, рассинхрон после миграции обычно лечится сам. Но не всегда быстро.

NTP не любит резких движений. Поэтому он действует по-разному в зависимости от величины отставания:

До 128 мс (порог stepthreshold) — часы подкручиваются плавно: NTP понемногу меняет скорость хода часов, корректируя их раз в секунду. Резких скачков нет, для приложений всё проходит незаметно.
Больше 128 мс — тут уже нужен скачок: часы резко переводятся вперёд к согласованному времени. Но NTP не торопится — он сделает это только после того, как убедится, что часы стабильно отстают более 900 секунд (это называется stepout threshold).

Звучит разумно, но 900 секунд ожидания — это 15 минут. Согласитесь, долго.

Тут на сцену выходят VMware Tools. Если смещение оказалось больше 1 секунды, они не ждут милостей от NTP, а сразу переводят гостевые часы вперёд при возобновлении ВМ — под часы хоста ESXi. Это называется одноразовой синхронизацией времени (one-time time synchronization). Она срабатывает каждый раз при возобновлении ВМ из checkpoint и только если гостевые часы отстают больше чем на порог, который по умолчанию равен 1000 мс.

Этот механизм доверяет часам хоста ESXi как эталону. А значит, сам хост должен быть синхронизирован по NTP — это официальная рекомендация VMware по хронометрированию.

Эти механизмы коррекции времени достаточны для большинства гостевых приложений. Однако некоторые приложения (например, распределённые по сети) могут быть крайне чувствительны к внезапным различиям во времени, а алгоритмы дисциплины часов NTP слишком медленны, чтобы смягчить их последствия. Например, в конфигурации по умолчанию NTP может потребоваться до 200 секунд, чтобы плавно скорректировать разницу во времени в 100 миллисекунд.

Итог: если ваши приложения чувствительны ко времени, одних стандартных настроек NTP может не хватить — нужно либо ускорять NTP (через iburst, minpoll/maxpoll), либо снижать порог срабатывания VMware Tools, либо подключать более точные решения вроде PTP.