Машина Hyper-V дрейфует время, даже с NTP

Решенный Проблема заключалась в Hyper-V на этой машине. Я удалил Hyper-V, установил VMware Server, запустил ту же виртуальную машину. Проблемы с синхронизацией времени исчезли (разница <100 мс после дня).

Моя установка такая:

HYV1 - HyperV machine (non domain) - sync irrelevant
AD1  - VM AD server on HYV1, sync'd to time.nist.gov. HyperV time sync off.
S1   - Physical machine, sync'd to domain. 
S2   - Physical machine running HyperV, sync'd to domain.
V1   - Linux VM machine on S2, sync'd to AD1. No HyperV integration.

AD1 и S1 имеют точную синхронизацию - полосовая диаграмма показывает разницу менее 100 мс.

S2 дрейфует как сумасшедший. Вот немного стрипчарта против AD1:

18:33:22 d:+00.0010138s o:+05.4101899s 
18:33:24 d:+00.0010138s o:+05.4319765s 
18:33:26 d:+00.0000000s o:+05.4788429s 
18:33:28 d:+00.0000000s o:+05.6089942s 
18:33:30 d:+00.0010138s o:+05.7240269s 
18:33:32 d:+00.0000000s o:+06.0421911s 
18:33:34 d:+00.0081104s o:+06.5613708s 
18:33:37 d:+00.0000000s o:+06.9096594s 
18:33:39 d:+00.0000000s o:+06.8867838s 
18:33:41 d:+00.0010127s o:+06.8936401s 

Через 20 секунд он дрейфовал за секунду. Если я переустановлю его вручную в течение 1 с, через несколько минут он вернется примерно на 2 секунды. Ночь прошла от ~ 2 с до ~ 5 с. Виртуальная машина Linux внутри S2 прекрасно синхронизируется с AD1.

Вот конфиг:

C:\Users\mgg>w32tm /dumpreg /subkey:Parameters

Value Name                 Value Type          Value Data
------------------------------------------------------------

ServiceDll                 REG_EXPAND_SZ       %systemroot%\system32\w32time.dll
ServiceMain                REG_SZ              SvchostEntry_W32Time
ServiceDllUnloadOnStop     REG_DWORD           1
Type                       REG_SZ              NT5DS
NtpServer                  REG_SZ              ad01.mydomain ad02.mydomain


C:\Users\mgg>w32tm /dumpreg /subkey:Config

Value Name                Value Type          Value Data
-----------------------------------------------------------

FrequencyCorrectRate      REG_DWORD           4
PollAdjustFactor          REG_DWORD           5
LargePhaseOffset          REG_DWORD           50000000
SpikeWatchPeriod          REG_DWORD           900
LocalClockDispersion      REG_DWORD           9
HoldPeriod                REG_DWORD           5
PhaseCorrectRate          REG_DWORD           1
UpdateInterval            REG_DWORD           30000
EventLogFlags             REG_DWORD           2
AnnounceFlags             REG_DWORD           5
TimeJumpAuditOffset       REG_DWORD           28800
MinPollInterval           REG_DWORD           2
MaxPollInterval           REG_DWORD           8
MaxNegPhaseCorrection     REG_DWORD           -1
MaxPosPhaseCorrection     REG_DWORD           -1
MaxAllowedPhaseOffset     REG_DWORD           300

Я посмотрел журнал событий, и кроме предупреждений о синхронизации (после того, как он вышел из-под контроля), других предупреждений нет.

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

Изменить: Чтобы уточнить: Виртуальная машина (AD1) отключена интеграция и синхронизируется с time.nist.gov. AD1 в порядке. Это физическая машина S1, которая не может синхронизироваться с AD1 и дрейфует повсюду. Все остальные физические серверы могут нормально синхронизироваться с AD1.

Обновление Итак, похоже, проблема запуска виртуальной машины. Часы медленно скользят при выключенной ВМ. Включено, сразу начинает терять секунды. Я включил виртуальную машину, чтобы использовать только половину ресурсов, и это, кажется, немного смягчило ее, на данный момент. Спасибо!

Из вашего описания звучит так, как будто существует реальная аппаратная проблема с RTC ( http://en.wikipedia.org/wiki/Real-time_clock ) на материнской плате сервера S2.

Гость Hyper-V изначально получает свои часы от хоста (HYV1), но, поскольку у вас отключена синхронизация времени Hyper-V, он получает все последующие обновления часов из NIST (что работает нормально). Ваша виртуальная машина Linux не интегрирована с Hyper-V, поэтому она получает время от домена, что также работает нормально. Ваши другие физические машины работают нормально, это всего лишь один физический сервер, который имеет 1 секунду дрейфа каждые 20 секунд (что является сумасшедшим количеством дрейфа). Время дрейфует намного быстрее, чем синхронизация времени в сети может вернуть часы в нужное время (что, если я правильно помню, происходит каждые 8 ​​часов).

Если вы хотите исключить Hyper-V как причину ошибки на S2, создайте загрузочную запись «no Hypervisor», перезагрузитесь без Hyper-V и посмотрите, сохраняется ли смещение времени. Инструкции здесь: http://blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

-Sean

Проблема заключается в виртуальной реализации различных источников синхронизации (tsc, jiffies, acpi_pm, cmos_trc). Лучший способ, который я нашел, чтобы решить эту проблему с HyperV, - отключить синхронизацию часов, предоставляемую HyperV для вашей гостевой машины, а затем использовать adjtimex для настройки времени. На гостевой ОС Ubuntu сделайте это ...

# rm /var/log/clocks.log
# /etc/init.d/ntp-server stop
# ntpdate ntp.ubuntu.com
# hwclock -u --systohc
# adjtimex -l -u -h ntp.ubuntu.com

и ответьте нет на оба вопроса

# while [ /bin/true ] ; do yes | adjtimex -l -u -h ntp.ubuntu.com ; sleep 60 ; done

оставьте его на несколько часов для калибровки, нажмите Ctrl-C, чтобы выйти из него.

# adjtimex -r -a -u -h ntp.ubuntu.com

это сделает анализ ваших часов методом наименьших квадратов и найдет правильную настройку

# ntpdate ntp.ubuntu.com
# hwclock -u --systohc
# /etc/init.d/ntp-server start

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

Кажется, это очень распространенная проблема с виртуальными машинами. Смотрите следующие сайты:

http://www.vmwareinfo.com/2008/04/enabling-ntp-on-esx-servers.html

http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/6fff3eef-1b5b-4059-8618-22ab3f5c293c

Мое предложение будет синхронизироваться только с внешним сервером времени и отключить любую интеграцию синхронизации времени

Надеюсь, это поможет.

Некоторое время мы работали с Hyper-v на Core. Сначала у нас были проблемы с синхронизацией времени ... Я вернулся к лучшей практике из моих старых дней Windows NT.

Я смотрю на серверы по ОС. Я создаю Linux, Router, Windows, Novell master.

Возможно, у вас сейчас нет Novell, но терпите меня.

Каждый «главный» сервер синхронизируется с маршрутизатором. Роутер в стратум. Затем каждый рядовой сервер имеет свой главный сервер ОС и вторичный сервер одного из других мастеров.

• Linux на маршрутизатор, затем на Novell
• Novell для маршрутизатора, затем для Windows
• Windows к маршрутизатору, затем к Linux
• Маршрутизатор до уровня, затем до основного коммутатора
• Основной коммутатор на уровень, затем на маршрутизатор

Последний кусок этой стратегии ... ВСЕ имеет сервер времени. Если у него нет сервера времени, он не будет подключен к сети. От тостера до телефонной АТС перейти на серверы.

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

Время дрейфует повсюду в виртуальных машинах. Вы действительно хотите убедиться, что NTP-сервер не использует локальные часы ни в каких операторах 'сервера', поскольку локальные часы слишком ненадежны. Одна вещь, которую я сделал, чтобы помочь, - установить атрибут «maxpoll» для серверов на машинах с виртуальной машиной. Это вынуждает службу ntp проверять свои часы восходящего потока намного чаще, чем настроенные значения по умолчанию, что помогает сохранять его истинным.

server [timeserver] maxpoll 12

Попробуйте несколько настроек, чтобы увидеть, как далеко вы должны пройти, чтобы сохранить время относительно надежным. 12 работает для меня, но каждая среда отличается.

Это может звучать смешно, но я уверен, что вы используете многопроцессорную установку? Есть известные проблемы , часы дрейфа с некоторыми производителями кашля AMD кашлем , которые случаются с материнскими платами многоядерным / мульти-сокетов. Активная работа с прерываниями - например, запуск виртуальной машины или двух - усугубляет дрейф. Дрейф, который вы испытываете, звучит очень подозрительно .

Что бы это ни стоило, я предпочитаю предложения AMD, а не Intel, поэтому не воспринимайте это как удар по ним.

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