Hyper-V Машина переносить час всюди, навіть з NTP

Вирішено Проблема Hyper-V на цій машині. Я вилучив Hyper-V, встановив сервер VMware, запустив той же VM. Проблеми синхронізації з часом пішли (<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 секунд. За ніч він пройшов від ~ 2s до ~ 5s. Linux VM всередині 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.

Оновлення Отже, схоже, проблема запуску VM. Годинник повільно ковзає, коли VM вимкнено. Увімкнувшись, він негайно починає втрачати секунди. Я замахнувся на ВМ використовувати лише половину ресурсів, і це, здається, трохи пом'якшило це. Дякую!

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

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

Якщо ви хочете виключити Hyper-V як причину помилки на S2, створіть запис завантаження "немає Hypervisor", перезавантажте його без Hyper-V і подивіться, чи зберігається затримка часу. Інструкції тут: http://blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

-Сейн

Проблема полягає у віртуальній реалізації різних тактових джерел (tsc, jiffies, acpi_pm, cmos_trc). Найкращий спосіб вирішити цю проблему з 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 повинен мати змогу тримати його синхронізовано, оскільки він більше не повинен дрейфувати.

Це, мабуть, є дуже поширеною проблемою для VM. Дивіться наступні веб-сайти:

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, маршрутизатор, Windows, Novell.

Ви, можливо, не матимете Novell зараз, але поводьтеся зі мною.

Кожен "головний" сервер синхронізується з маршрутизатором. Маршрутизатор в прошарок. Тоді кожен сервер-член має свій головний сервер ОС і вторинний один з інших майстрів.

• Linux до маршрутизатора, потім до Novell
• Novell до маршрутизатора, потім до Windows
• Windows для маршрутизатора, потім до Linux
• Маршрутизатор до Stratum, потім до перемикача Core
• Основний перехід до Stratum, потім до маршрутизатора

Останній фрагмент цієї стратегії ... У ВСІМ є сервер часу. Якщо у нього немає сервера часу, то він не збирається підключатися до мережі. З тостера для переходу на телефонну АТС до серверів.

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

Час переміщається всюди у вітринах. Ви дійсно хочете переконатися, що NTP-сервер не використовує локальний годинник у жодних висловлюваннях "сервера", оскільки локальний годинник занадто ненадійний. Одне, що я зробив, щоб допомогти - це встановити атрибут "maxpoll" для серверів на машинах VMed. Це змушує службу ntp перевіряти свої годинники вище за течією набагато частіше, ніж налаштований за замовчуванням, що допомагає зберегти його правдою.

server [timeserver] maxpoll 12

Спробуйте кілька налаштувань, щоб побачити, як далеко вам потрібно дістатися, щоб тримати час відносно надійним. Для мене працює 12, але кожне середовище різне.

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

Що варто, я віддаю перевагу пропозиціям AMD над Intel, тому не сприймайте це як удар проти них.

Якщо припустити, що AD1 був контролером домену, я думаю, що тут проблема може бути пов’язана з тим, що ваш сервер Hyper-V встановив свій час від однієї з власних гостьових віртуальних машин. Ось чому проблема пішла, коли ви перейшли на VMware: сервер VMware не відчуває вимушеності синхронізувати свій годинник з контролером домену Windows.