Нужно ли запускать NTP-сервер на каждой виртуальной машине?

Не могли ли гости каким-то образом унаследовать системное время хоста?

Кажется бессмысленным запускать один и тот же демон для получения одинаковых результатов на одной и той же машине несколько раз, но я не нашел ничего связанного со временем при чтении статей KVM или Xen. Насколько я понимаю, гость получает время хоста при загрузке, но затем оно может разойтись. Это верно ?

Это верно. Следует отметить, что время не только «может» уходить, но и будет уходить из-за того, что интервалы между прерываниями таймера (на которых часто основывается хронометраж в ОС) растягиваются и сжимаются так, как гипервизор посчитает нужным.

Общеизвестным решением для большинства платформ виртуализации (сервисы интеграции Hyper-V, инструменты VMWare) является запуск на госте демона, который периодически синхронизирует часы с хостом виртуальной машины. Как отметил Хауке в комментарии к вашему вопросу, KVM дополнительно предоставляет паравиртуализированные часы, для работы которых требуется соответствующий драйвер, загруженный в гостевую ОС.

Хронометраж в виртуальных машинах VMWare (vmware.com)
Синхронизация часов гостей KVM (s19n.net)

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

Основываясь на моем опыте работы практически с каждым гипервизором, известным человеку, я всегда запускаю NTP-клиента на виртуальных машинах без исключения. Моя обычная настройка - это ntpd с опцией -g или ntpdate, запускаемый прямо перед старыми системами, чтобы переключать тактовую частоту (которая может сильно не синхронизироваться при загрузке системы).

KVM имеет почти идеальную настройку с его паравиртуализированными часами реального времени ; Гости с соответствующим драйвером (по крайней мере, все последние версии Linux) будут следить за временем и хозяином. Но все же здесь что-то идет не так: например, на хосте может не работать NTP, на хосте может быть установлен неправильный часовой пояс, часы хоста могут быть просто неправильными и т. Д.

VMware и Hyper-V падают в середине. У каждого есть инструмент, предназначенный для запуска на гостевой машине, который периодически синхронизирует часы с хостом, но, опять же, это уязвимо для любых существующих проблем с часами хоста.

Гости на моем тестовом сервере Hyper-V также продемонстрировали странное поведение: даже при использовании сервисов интеграции гостевые часы будут дрейфовать быстрее, чем 500 ppm, не давая работать ntpd ( он считает часы безумными, если он дрейфует быстрее, чем этот ). Мне пришлось переключить этих гостей на хронологию , что позволяет корректировать это значение .

Ксен худший в этом отношении; он не имеет абсолютно никакой синхронизации и запуск NTP в гостях в значительной степени требуется. (Мне сказали, что в самых последних версиях Xen есть какая-то синхронизация, но лично я еще не работал с ней.)

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

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

Я бы порекомендовал использовать NTP, потому что он хорошо известен и существует уже давно. Настройка часов не тривиальна. NTP решил эту проблему.

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

Однако на практике мы запускаем оба одновременно, и я еще не видел проблемы.

$ ntpq   
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
something.org  172.2.1.5          2 u   57   64  377    1.597   -2.409   5.952


$  vmware-toolbox-cmd  timesync status
Enabled


$ vmware-toolbox-cmd help timesync
timesync: functions for controlling time synchronization on the guest OS
Usage: vmware-toolbox-cmd timesync <subcommand>

Subcommands:
  enable: enable time synchronization
  disable: disable time synchronization
  status: print the time synchronization status