Машина 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.

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

7 ответов

Из вашего описания звучит так, как будто существует реальная аппаратная проблема с 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

The problem is with the virtual implementation of the various clock sources (tsc, jiffies, acpi_pm, cmos_trc). The best way I have found to fix this problem with HyperV is to turn off the HyperV provided clock sync for your guest machine, then use adjtimex to adjust the time. On an Ubuntu guest OS do this...

# 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

and answer No to both questions

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

leave that to run for a few hours to calibrate, hit Ctrl-C to exit it.

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

this will do a least squares analysis of your clock and will find the right adjustment

# 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
  • Маршрутизатор до уровня, затем до основного коммутатора
  • Основной коммутатор на уровень, затем на маршрутизатор

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

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

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

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

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

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

server [timeserver] maxpoll 12

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

Другие вопросы по тегам