Короткий ответ

У доменной Windows-VM два потенциальных источника времени: иерархия AD (PDC emulator) и Hyper-V Time Synchronization Integration Service (vmictimesync). Если оба тянут в разные стороны, получите скачки часов, мёртвый Kerberos и «нет DC». Для рядового VM-APP01 обычно: IC time sync включён как запас (хост подтягивает большие дельты), Windows Time смотрит в домен. Для DC в VM действуйте по актуальной рекомендации Microsoft: не оставляйте бесконтрольный sync с хостом, который сам не в иерархии леса.

Не выключайте Windows Time и не ставьте time.windows.com единственным источником у членов домена.

Симптомы и как отличить

Типичная картина:

  • вход в домен периодически «неверное имя или пароль» при верном пароле;
  • w32tm /query /status : Source = VM IC Time Synchronization Provider или неожиданный NTP;
  • хост HV01 сам отстаёт (BIOS/NTP), все гости скачут вместе;
  • Kerberos Event про clock skew.

Отличия:

Что видноКуда
IC в целом сломаныIntegration Services
Хост сам не знает времяhealth хоста
Replica/backup «не из‑за часов»другие статьи; но SKU сертификатов HTTPS Replica чувствительны к времени

Возможные причины

  1. Хост без NTP, IC включён — гости наследуют враньё CMOS.
  2. IC выключен, гость не доменный и без NTP — drift.
  3. DC-VM синхронизируется с хостом, а хост — с этим же DC: петля.
  4. GPO NTP конфликтует с IC.
  5. Saved State/checkpoint вернули старые часы.
  6. Dual boot / пауза VM надолго.

Диагностика

Хост:

Get-VMIntegrationService -VMName 'VM-APP01' | Format-Table Name, Enabled, PrimaryStatusDescription
w32tm /query /status
w32tm /query /source
w32tm /query /configuration

Гость VM-APP01:

Get-Service W32Time, vmictimesync | Format-Table Name, Status, StartType
w32tm /query /status
w32tm /query /source
w32tm /query /peers
Get-Date

Сравните с PDC:

nltest /dsgetdc:contoso.example /pdc

На PDC — свой w32tm /query /source (внешний NTP, не гость). Журнал System: служба времени Event (в т.ч. известный 36 — не удаётся синхронизироваться). Не выдумывайте ID, читайте Message.

Проверьте, не восстановлен ли недавно checkpoint (снимки).

Решение

Сценарий A. Рядовой сервер в домене

  1. Хост HV01 синхронизируется с корпоративным NTP/PDC, не «как получится».
  2. В Hyper-V Time Synchronization Enabled.
  3. В госте Windows Time: тип NTP NT5DS (домен), не NTP на 8.8.time.
# в госте, если сбили тип
w32tm /resync /force
w32tm /query /source

Если Source надолго застрял на IC, а домен недоступен — сначала сеть, не disable IC.

Сценарий B. Контроллер домена в VM

Следуйте текущей документации Microsoft для virtualized DC: иерархия леса, PDC — внешние NTP; избегайте циклов host↔DC. Часто рекомендуют частично отключать IC time sync на DC (через Integration Service в настройках VM или параметры провайдера), оставляя хостовый sync выключенным как полный авторитет. Не копируйте реестр с форума 2008 года без сверки с docs вашей ОС.

Хосты Hyper-V, на которых крутятся DC, сами должны брать время из иерархии/внешнего NTP, не из этих DC как единственного источника в петле.

Сценарий C. Хост врёт

Почините w32tm на HV01 (GPO, NTP). Гости с IC подтянутся. Не «синхронизировать вручную все VM».

Сценарий D. После Saved State / снимка

Время в госте старое. w32tm /resync /force, для больших дельт IC как раз помогает, если включён. Затем проверьте Kerberos (повторный вход).

На HV01 не используйте VM-APP01 как NTP-источник, если этот гость сам берёт IC с хоста. Разомкните петлю: хосты → корпоративный NTP или PDC (который не на этом же хосте как единственный источник в круге). Запишите в runbook: кто stratum для гипервизоров.

После паузы VM на часы Windows Time может отказаться прыгать слишком далеко без /resync /force и без IC. Именно поэтому IC time sync полезен рядовым гостям: он умеет крупные коррекции, w32tm в домене — мелкие. Оба канала должны смотреть согласованную вселенную, не два NTP с расхождением в минуты.

Запишите Source до и после исправления: хост, гость, PDC. Без трёх цифр через неделю не докажете, что петля разомкнута.

Как проверить, что проблема устранена

На госте и PDC Get-Date в пределах политики skew (обычно секунды, не минуты). w32tm /query /source ожидаемый. Вход на VM-APP01 с доменной учётки. Нет новых жалоб Kerberos. После reboot гостя и после Live Migration источник времени тот же.

w32tm /stripchart /computer:DC01.contoso.example /samples:5 /dataonly

Если не помогло

  • Только Linux-гость: chrony/systemd-timesyncd vs hv_utils; не эта же служба vmictimesync Windows.
  • Replica на другую площадку с другим timezone — timezone не есть NTP offset; проверьте TZ отдельно.
  • Приложения с собственным NTP (редко).
  • IC красные: статья Integration Services.

Профилактика

  • NTP на всех гипервизорах мониторится.
  • Стандарт: кто источник у DC, у члена, у хоста — в runbook.
  • Запрет долгих checkpoint на DC.
  • Алерт расхождения часов (Zabbix/другие) > 2–3 секунд для DC, чуть мягче для рядовых.
  • Не Saved State DC «на выходные».

FAQ

Выключить time sync IC всем VM?

Нет. Для рядовых полезен как коррекция больших дельт после паузы. Выключение без NTP = drift.

Почему Source = Local CMOS?

Windows Time не с кем синхронизироваться. Сеть/служба/тип NTP, не «поставить BIOS».

Два NTP в GPO и IC — конфликт?

Может давать осцилляции. Политика должна быть согласована. Не три внешних NTP плюс IC плюс net time.

VM Generation 2 меняет время иначе?

Нет принципиально: IC те же. Проблема в политике, не в UEFI часах.

Нужен ли /syncfromflags:domhier всегда?

Для членов домена обычно да (NT5DS). Для изолированной lab-VM — NTP. Не применяйте domhier к хосту вне домена.

Live Migration сбрасывает часы?

Краткий дрейф возможен, IC/w32tm догоняют. Если после каждой LM минуты разницы — хосты сами в разных эпохах.