Отключил tools.syncTime, а после vMotion часы ВМ снова уехали: где в vSphere выключается разовая коррекция времени

Классическая ловушка: администратор снимает в свойствах ВМ галочку «Synchronize Time Periodically», убеждается, что в VMX стоит tools.syncTime = FALSE, и считает вопрос закрытым. А через двое суток контроллер домена после ночного переезда DRS приезжает с часами, ушедшими на несколько минут, журналы перестают сходиться, Kerberos начинает ругаться на skew. Дело в том, что VMware Tools правит время гостя двумя разными механизмами, и tools.syncTime гасит только один из них. Ниже — что за второй механизм, на каких событиях он срабатывает, каким именно параметром (и в UI, и в API, и в govc) он выключается в vSphere 7.0 U1 и новее, чем это отличается от старых версий, и разбор фермы мебельной фабрики на 22 ВМ, где эта разница стоила клиенту трёх месяцев непонятных инцидентов.

Это два разных выключателя, а не один

У VMware Tools внутри две независимые подсистемы работы с часами гостя. Первая — периодическая синхронизация: демон Tools регулярно (по умолчанию раз в минуту) сравнивает время гостевой ОС со временем хоста ESXi и подтягивает гостя к хосту: отстающие часы переводит вперёд, а спешащие не отматывает назад, а замедляет, пока они не сойдутся. Именно ей соответствует параметр VMX tools.syncTime и галочка «Synchronize Time Periodically» в клиенте vSphere. Вторая — разовая коррекция (в документации Broadcom это «one-off time sync», step correction): Tools одномоментно выставляет время гостя по хосту в момент определённых событий жизненного цикла виртуальной машины. У неё свой выключатель, и он совершенно другой.

Исторически логика была осмысленной. Когда ВМ уходит в suspend, её виртуальный процессор физически не тикает: машину сняли с паузы через шесть часов — часы гостя отстают ровно на шесть часов, и никакой NTP-клиент такой разрыв быстро не закроет, а chrony без makestep вообще откажется его закрывать. Поэтому разовая коррекция включена по умолчанию и живёт отдельно от периодической: считалось, что «починить очевидно сломанное» надо всегда, даже если постоянную подтяжку админ выключил осознанно.

До vSphere 7.0 U1 отдельного человеческого выключателя для этого не было — только россыпь из семи недокументированных в UI параметров VMX, о которых знали единицы. Начиная с 7.0 U1 Broadcom свёл всё к одному ключу: time.synchronize.allow в VMX, syncTimeWithHostAllowed в API (структура ToolsConfigInfo), «Synchronize at startup and resume» в клиенте vSphere. Так это работает и в 8.x, и в 9.0 — механика с тех пор не менялась, менялись только обёртки в интерфейсе.

Ключевая асимметрия, из-за которой все и попадаются: syncTimeWithHostAllowed = false гасит и разовые коррекции, и периодическую синхронизацию — это мастер-выключатель. А syncTimeWithHost = false (он же tools.syncTime = FALSE) гасит только периодику и на разовые коррекции не влияет никак. В документации Broadcom это сформулировано прямо: периодическая синхронизация разрешена только тогда, когда syncTimeWithHostAllowed не выставлен в false.

• «Synchronize Time Periodically» (UI) = `tools.syncTime` (VMX) = `syncTimeWithHost` (API) — только периодика, раз в минуту.
• «Synchronize at startup and resume» (UI) = `time.synchronize.allow` (VMX) = `syncTimeWithHostAllowed` (API) — мастер-выключатель, гасит и разовые коррекции, и периодику.
• До vSphere 7.0 U1 второго пункта в UI нет — только семь отдельных `time.synchronize.*` в Advanced Parameters.
• Значение по умолчанию у `syncTimeWithHostAllowed` — true, и в vmx-файле оно не пишется. Отсутствие строки ≠ выключено.

На каких событиях Tools правит часы разово

Список событий, при которых срабатывает одномоментная коррекция, у Broadcom описан в KB про отключение синхронизации времени. Он короткий, но покрывает почти всё, что происходит с ВМ в живой ферме — и главное, туда входит vMotion, то есть событие, которое в кластере с включённым DRS случается само, без участия человека, посреди ночи.

Именно поэтому симптом выглядит мистически: администратор ничего не делал, ВМ никто не трогал, а часы съехали. Смотришь в журнал задач vCenter — там миграция в 03:40. Смотришь в журнал гостя — там ровно в 03:40 скачок времени. Никакой мистики: DRS перевёз машину на хост, у которого своё представление о времени, и Tools честно синхронизировал гостя по новому хосту.

Насколько это больно — зависит от того, что на ВМ. Скачок в пару секунд обычно не заметит никто. Скачок в минуты ломает вполне конкретные вещи: Kerberos по умолчанию терпит расхождение в 5 минут и дальше выдаёт KRB_AP_ERR_SKEW, TSDB вроде Zabbix и VictoriaMetrics не любят точки «из будущего», журнал регистрации 1С и любые расследования инцидентов превращаются в гадание, а на сертификатах с коротким сроком (ACME, внутренние 24-часовые) время «вперёд» даёт NotYetValid.

И сразу успокою: если ваши хосты ESXi нормально ходят по NTP и стоят на той же страте, что и гости, разовая коррекция вам не вредит вообще. Она вредит ровно в двух сценариях. Первый: хост врёт — потерял NTP-конфиг, живёт на дрейфующем RTC, стоит в изолированном сегменте без доступа к пулу. Второй: гость намеренно живёт на другом источнике времени — доменная иерархия W32Time, PTP, внешний GPS-стратум, — и любое вмешательство хоста для него откат назад.

• Возобновление ВМ из suspend (resume).
• Миграция vMotion — в том числе автоматическая, инициированная DRS.
• Создание снапшота.
• Откат к снапшоту (revert).
• Сжатие виртуального диска (shrink).
• Перезапуск службы VMware Tools внутри гостя или перезагрузка гостевой ОС с работающими Tools.

Как выключить правильно: UI, PowerCLI, govc

В клиенте vSphere 7.0 U1 и новее путь такой: Edit Settings → VM Options → VMware Tools → блок Time. Снимаете «Synchronize at startup and resume» — и вторая галочка, «Synchronize Time Periodically», становится недоступной, потому что она подчинённая. Это ровно то поведение, которое описано в API: периодика разрешена, только пока разрешены разовые коррекции.

Руками через UI по одной машине — занятие для стенда на три ВМ. На парке я это делаю скриптом. PowerCLI не имеет отдельного параметра у Set-VM под эти свойства, поэтому идём через VirtualMachineConfigSpec и ToolsConfigInfo — конструкция древняя, но рабочая и в 13.x, и в 14.x:

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.tools = New-Object VMware.Vim.ToolsConfigInfo
$spec.tools.syncTimeWithHostAllowed = $false
$spec.tools.syncTimeWithHost        = $false

# сузьте выборку под себя: -Location, -Tag, имя по маске
Get-VM -Name 'DC0*','SQL*' | ForEach-Object {
    Write-Host "reconfig: $($_.Name)"
    $_.ExtensionData.ReconfigVM($spec)
}

Если PowerCLI в контуре нет (а у меня на половине площадок его нет — управляю с Linux-джампа), то же самое делает govc: периодика — штатным флагом -sync-time-with-host, мастер-выключатель — через ExtraConfig с VMX-именем параметра. Записать конфигурацию можно и на включённой машине, но вступает она в силу не сразу: по KB Broadcom — только после перезапуска ВМ или службы VMware Tools в госте. Поэтому перезапуск Tools я делаю сразу после раскатки, но строго после того, как починен NTP на хостах, — сам рестарт Tools тоже событие разовой коррекции:

export GOVC_URL='https://vcenter.corp.example.com'
export GOVC_USERNAME='svc-govc@vsphere.local'
export GOVC_INSECURE=false

# мастер-выключатель + периодика
govc vm.change -vm DC01 \
  -sync-time-with-host=false \
  -e time.synchronize.allow=FALSE

# проверить, что реально записалось
govc vm.info -e DC01 | grep -Ei 'syncTime|time.synchronize'

Если ферма старая — ESXi 6.7 или 7.0 без U1, а такие в продакшене у клиентов ещё встречаются, — единого ключа нет, и придётся выставлять в FALSE все семь параметров по списку ниже. Пропустите один — останется одна дырка, и она обязательно выстрелит именно на том событии, которое вы не закрыли. Это, кстати, отдельный аргумент за обновление: в 7.0 U1 и выше одна строка вместо семи.

Есть ещё третий путь — изнутри гостя. vmware-toolbox-cmd timesync disable из гостевой ОС правит именно tools.syncTime, то есть периодику. Разовые коррекции им не выключить: это свойство конфигурации ВМ, а не гостевого агента. Команда удобна для быстрой проверки состояния (vmware-toolbox-cmd timesync status), но как средство «выключить всё» она не годится.

• time.synchronize.continue = FALSE
• time.synchronize.restore = FALSE
• time.synchronize.resume.disk = FALSE
• time.synchronize.shrink = FALSE
• time.synchronize.tools.startup = FALSE
• time.synchronize.tools.enable = FALSE
• time.synchronize.resume.host = FALSE

Разбор из практики: мебельная фабрика «Дубрава-Мебель», 22 ВМ и уезжающий контроллер домена

Мебельная фабрика «Дубрава-Мебель», 48 рабочих мест: офис, конструкторский отдел и склад с цехом. Ферма — два хоста HPE DL360 Gen10 под ESXi 8.0 U3, vCenter 8.0 U3, кластер с DRS в полностью автоматическом режиме, 22 виртуальные машины: два контроллера домена, MS SQL под 1С, сервер 1С, терминальник, Zabbix, файловый сервер с чертежами и раскроем, остальное — по мелочи. Пришли с формулировкой «раз в несколько дней у людей отваливаются сетевые диски и просят пароль, само проходит».

Первое, что я нашёл в System-логе DC01, — записи Kerberos-KDC и W32Time с жалобами на резкий сдвиг локальных часов. Второе — что сдвиги ложатся ровно на события миграции в журнале задач vCenter. Третье — что предыдущий подрядчик синхронизацию честно «выключал»: в vmx у DC01 стояло tools.syncTime = "FALSE", а строки time.synchronize.allow не было вовсе. Значит, разовая коррекция работала со значением по умолчанию, то есть была разрешена.

Дальше — источник вранья. У хоста esxi-02 полгода назад меняли системную плату по гарантии, конфиг NTP при этом не восстановили: esxcli system ntp get показывал выключенный сервис, часы хоста жили на дрейфующем аппаратном RTC и на момент разбора ушли вперёд на 6 минут 41 секунду. DRS перевозил DC01 на esxi-02 примерно раз в двое-трое суток. В момент vMotion Tools одномоментно двигал часы гостя на эти +6:41 — а это уже больше пятиминутного окна Kerberos, отсюда и «просит пароль». Потом W32Time медленно, плавной подстройкой, затягивал время обратно, и через 20–40 минут всё «проходило само». Классическая картина «мигает и само чинится», в которой никто не виноват и никто не ищет.

Чинили в три шага, и порядок здесь важен. Сначала — время на хостах: NTP на обоих ESXi на два внутренних сервера плюс внешний пул, старт сервиса и автозапуск, брандмауэрное правило ntpClient. Это само по себе убрало 6 минут расхождения и сняло острую боль за 15 минут работы. Затем — мастер-выключатель на машины, у которых есть собственный источник времени: оба DC, SQL, сервер 1С, Zabbix, терминальник, файловый сервер и доменные служебные машины — 14 ВМ из 22, с последующим перезапуском службы VMware Tools на каждой, чтобы настройка реально вступила в силу. Затем — иерархия W32Time: PDC-эмулятор на внешние источники, остальные члены домена на домен, ручные peer-list с рядовых серверов вычищены.

# на каждом хосте ESXi, через SSH
esxcli system ntp set --enabled=false
esxcli system ntp set --server=10.10.10.10 --server=10.10.10.11 --server=ru.pool.ntp.org
esxcli system ntp set --enabled=true
esxcli network firewall ruleset set --ruleset-id ntpClient --enabled=true
esxcli system ntp get

Что осталось не выключено — 8 ВМ. Это appliance-образы (в том числе Veeam-прокси и пара вендорских «чёрных ящиков»), где нормального NTP-клиента либо нет, либо он не поддаётся настройке снаружи. Для них синхронизация с хостом — единственный источник времени, и после починки NTP на хостах это стало вполне корректным источником. Осознанное решение, а не забывчивость: я всегда фиксирую такой список в паспорте площадки, иначе через год следующий инженер решит, что тут недоделали, и выключит всё подряд.

Итог за четыре месяца наблюдения: ни одного KRB_AP_ERR_SKEW, ни одной жалобы на диски, максимальное расхождение по парку по данным Zabbix — 12 мс между гостем и внутренним NTP. Общее время работ — около трёх часов, из которых два ушло на разбор, а не на исправление.

• Симптом: раз в 2–3 суток отваливаются сетевые диски, «само проходит» за полчаса.
• Причина 1: хост esxi-02 без NTP ушёл вперёд на 6 мин 41 с.
• Причина 2: у ВМ выключена только периодика (tools.syncTime=FALSE), разовая коррекция разрешена по умолчанию.
• Триггер: автоматический vMotion от DRS раз в 2–3 суток.
• Лечение: NTP на хостах → syncTimeWithHostAllowed=false на 14 ВМ + рестарт Tools → иерархия W32Time.
• Результат: 0 инцидентов за 4 месяца, разброс времени по парку 12 мс.

Чем заменить: правильная схема времени в виртуальной ферме

Выключить синхронизацию с хостом — это половина работы. Вторая половина — дать гостю нормальный источник, иначе вы поменяете «часы прыгают» на «часы плавно уезжают», что диагностируется ещё хуже. Схема, которую я разворачиваю у себя и у клиентов, простая и трёхэтажная: хосты ESXi берут время по NTP (в 8.0 и 9.0 есть и PTP, но он оправдан только там, где реально нужны микросекунды — в офисе на 50 мест это переусложнение); PDC-эмулятор домена берёт время с внешних источников; все остальные доменные машины берут время у домена и ни у кого больше.

Для Windows-части — три команды и один запрет. На PDC-эмуляторе прописываем внешние источники и объявляем сервер надёжным; на всех остальных доменных машинах возвращаем режим NT5DS (домен) и вычищаем ручные peer-list, которые кто-то когда-то прописал «чтобы точно работало»:

# на PDC-эмуляторе
w32tm /config /manualpeerlist:"ru.pool.ntp.org,0x8 time.windows.com,0x8" `
      /syncfromflags:manual /reliable:yes /update
Restart-Service w32time
w32tm /query /status

# на рядовом сервере или рабочей станции домена
w32tm /config /syncfromflags:domhier /update
Restart-Service w32time
w32tm /query /source   # должно быть FQDN контроллера домена

Для Linux-гостей — chrony, и обязательно с makestep. Без него после длинного простоя или восстановления из снапшота chrony откажется двигать часы скачком и будет годами подтягивать их смещением частоты. Именно ради этого случая когда-то и придумали разовую коррекцию от Tools; если вы её выключаете, makestep берёт эту функцию на себя, но делает это по нормальному источнику, а не по случайному хосту, на который вас переехал DRS:

# /etc/chrony/chrony.conf
server 10.10.10.10 iburst
server 10.10.10.11 iburst
pool ru.pool.ntp.org iburst maxsources 3

# скачком поправить смещение >1 с, но только для первых 3 обновлений после старта
makestep 1.0 3
rtcsync
driftfile /var/lib/chrony/chrony.drift

И главное правило, которое нарушают чаще всего: у гостя должен быть ровно один хозяин времени. Оставленные одновременно работающий chrony и включённая синхронизация Tools дают самое противное поведение из возможных — часы дёргаются туда-сюда с периодом в минуту, chrony пишет в лог «System clock was stepped» пачками, а причину ищут месяцами.

• ESXi → внутренний NTP + внешний пул, сервис включён, автозапуск, ruleset ntpClient открыт.
• PDC-эмулятор → внешние источники, /reliable:yes.
• Члены домена → только домен (/syncfromflags:domhier), никаких ручных peer-list.
• Linux → chrony с makestep, синхронизация Tools выключена мастер-ключом.
• Appliance без своего NTP → оставляем синхронизацию с хостом, но фиксируем список в документации.

Как проверить весь парк одной командой

Верить галочке в UI я перестал давно: в разных версиях клиента блок Time отрисовывается по-разному, а подчинённая галочка периодики в выключенном состоянии может выглядеть как «включена, но серая». Проверять надо свойства объекта, а не картинку. По всему vCenter это делается одним отчётом — я держу его в еженедельной выгрузке вместе с проверкой NTP на хостах.

Get-VM | Select-Object Name,
  @{N='Periodic';   E={$_.ExtensionData.Config.Tools.SyncTimeWithHost}},
  @{N='OneOffAllowed'; E={$_.ExtensionData.Config.Tools.SyncTimeWithHostAllowed}},
  @{N='ToolsStatus'; E={$_.ExtensionData.Guest.ToolsVersionStatus}} |
  Sort-Object OneOffAllowed, Name |
  Export-Csv -NoTypeInformation -Encoding UTF8 .\vm-timesync.csv

Читать результат надо аккуратно: пустое значение в колонке OneOffAllowed означает не «выключено», а «свойство не задано», то есть действует значение по умолчанию — разрешено. Это ровно та ошибка, на которой я поймал предыдущего подрядчика в «Дубраве-Мебель»: он смотрел в vmx, не находил там строки time.synchronize.allow и делал вывод, что коррекции нет. Её нет в файле, но она есть в поведении.

Хосты проверяю тем же заходом — расхождение между хостами кластера важнее абсолютной точности. Если хосты согласованы между собой и с внутренним NTP в пределах десятков миллисекунд, разовая коррекция при vMotion физически не может ничего испортить, даже если где-то забыли её выключить:

for h in esxi-01 esxi-02; do
  echo "== $h"
  ssh root@$h 'esxcli system ntp get; date -u'
done

• Periodic = False, OneOffAllowed = False — корректно выключено полностью.
• Periodic = False, OneOffAllowed пусто или True — та самая половинчатая настройка, чинить.
• Periodic = True, OneOffAllowed = False — невозможная комбинация по смыслу: мастер-ключ всё равно главнее.
• ToolsStatus в колонке рядом не для красоты: на ВМ с неработающими Tools синхронизации нет вообще, и это тоже надо знать.

Где я бы не выключал и чего не надо бояться

Не выключайте синхронизацию на машинах, у которых нет другого источника времени. Изолированные тестовые стенды без выхода к NTP, вендорские appliance с закрытой консолью, временные ВМ из шаблонов, живущие неделю, — для них хост это единственный ориентир, и он вполне сгодится, если сам хост честно ходит по NTP. Выключать «на всякий случай везде» — это ритуал, а не инженерное решение.

И развею пару преувеличенных страхов. Отключение синхронизации с хостом никак не мешает vMotion, не влияет на снапшоты, не ломает резервное копирование и не требует перезагрузки гостевой ОС — достаточно перезапустить службу VMware Tools (или дождаться ближайшего выключения-включения ВМ), чтобы изменённая конфигурация вступила в силу. Часы у вас никуда «навсегда» не уедут: дрейф виртуального таймера в современных ESXi на процессорах с инвариантным TSC исчисляется миллисекундами в сутки, и любой нормально настроенный NTP-клиент его закрывает не напрягаясь. Единственный реальный риск — выключить синхронизацию и не настроить замену, и это риск не технический, а организационный.

Спорный момент, где единого мнения нет: надо ли трогать MaxPosPhaseCorrection и MaxNegPhaseCorrection у W32Time на виртуальных контроллерах домена. Часть коллег их ужесточает, чтобы служба вообще отказывалась принимать неадекватный сдвиг. Я так не делаю: жёсткие лимиты превращают редкий скачок в тихий отказ синхронизации, о котором вы узнаете через полгода. Мне важнее, чтобы часы сошлись, а факт скачка был виден в мониторинге — и я лучше повешу триггер на offset, чем запрещу службе работать.

Приоритеты, если времени мало. Первое и обязательное — NTP на всех хостах ESXi и контроль расхождения между ними; это пятнадцать минут работы и это закрывает большую часть подобных инцидентов. Второе — мастер-выключатель syncTimeWithHostAllowed = false на контроллерах домена, серверах СУБД, серверах 1С и системах мониторинга. Третье — иерархия W32Time и chrony с makestep. На остальной парк можно спокойно забить до ближайшей плановой ревизии: если хосты не врут, разовая коррекция там безобидна.

• Приоритет 1 — NTP на хостах ESXi, контроль расхождения внутри кластера.
• Приоритет 2 — syncTimeWithHostAllowed = false на DC, SQL, 1С, мониторинге.
• Приоритет 3 — иерархия W32Time и chrony с makestep в гостях.
• Приоритет 4 — остальной парк, плановой ревизией.
• Не трогать — appliance и изолированные стенды без собственного источника времени.

Частые вопросы