Maszyna Hyper-V dryfuje przez cały czas, nawet z NTP

Rozwiązane Problemem była Hyper-V na tym komputerze. Usunąłem Hyper-V, zainstalowałem VMware Server, uruchomiłem tę samą maszynę wirtualną. Problemy z synchronizacją czasu zniknęły (różnica <100 ms po dniu).

Moja konfiguracja wygląda następująco:

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 i S1 mają dokładną synchronizację - stripchart pokazuje różnicę mniejszą niż 100 ms.

S2 dryfuje jak szalony. Oto niektóre informacje na temat 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 

W ciągu 20 sekund dryfował przez sekundę. Jeśli ręcznie zresetuję go w ciągu 1s, w ciągu kilku minut wróci dryfując około 2 sekund. W ciągu nocy było to od ~ 2s do ~ 5s. Linux VM w S2 ma doskonałą synchronizację z AD1.

Oto konfiguracja:

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

Spojrzałem na dziennik zdarzeń i oprócz ostrzeżeń o synchronizacji (po tym, jak zejdzie z synchronizacji), nie ma innych ostrzeżeń.

Jak mogę rozwiązać ten problem? To jedyna maszyna, która ma ten problem. Wszystkie inne maszyny (fizyczne i wirtualne) mają się dobrze.

Edycja: Aby wyjaśnić: VM (AD1) ma wyłączoną integrację i synchronizuje się z time.nist.gov. AD1 jest w porządku. To fizyczna maszyna S1, która nie może zsynchronizować się z AD1 i dryfuje dookoła. Wszystkie pozostałe serwery fizyczne są w stanie zsynchronizować się z AD1 w porządku.

Aktualizacja Wydaje się, że jest to problem z uruchomieniem maszyny wirtualnej. Zegar przesuwa się powoli przy wyłączonej maszynie wirtualnej. Po włączeniu natychmiast traci sekundę. Przekręciłem maszynę wirtualną, aby używała tylko połowy zasobów, i wydaje się, że na razie nieco ją złagodziła. Dzięki!

Z twojego opisu wygląda na to, że istnieje rzeczywisty problem sprzętowy z RTC ( http://en.wikipedia.org/wiki/Real-time_clock ) na płycie głównej serwera S2.

Gość Hyper-V otrzymuje początkowo swój zegar od hosta (HYV1), ale ponieważ masz wyłączoną synchronizację czasu Hyper-V, otrzymuje wszystkie dalsze aktualizacje zegara od NIST (który działa dobrze). Twoja maszyna wirtualna z systemem Linux nie jest zintegrowana z funkcją Hyper-V, więc dostaje czas z domeny, która również działa dobrze. Twoje inne maszyny fizyczne działają dobrze, to tylko jeden serwer fizyczny, który ma 1 sekundę dryfu co 20 sekund (co jest szaloną ilością dryfu). Czas płynie znacznie szybciej niż synchronizacja czasu sieciowego może zresetować zegar do właściwego czasu (co, jeśli dobrze pamiętam, odbywa się co 8 godzin).

Jeśli chcesz wykluczyć funkcję Hyper-V jako przyczynę błędu na S2, utwórz pozycję rozruchową „brak hiperwizora”, uruchom ponownie bez Hyper-V i sprawdź, czy czas się utrzymuje. Instrukcje tutaj: http://blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

-Sean

Problem polega na wirtualnej implementacji różnych źródeł zegara (tsc, jiffies, acpi_pm, cmos_trc). Najlepszym sposobem, jaki znalazłem, aby rozwiązać ten problem z HyperV, jest wyłączenie synchronizacji zegara dostarczonej przez HyperV dla twojego komputera-gościa, a następnie skorzystanie z adjtimex w celu dostosowania czasu. W systemie-gościu Ubuntu wykonaj to ...

# 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

i odpowiedz Nie na oba pytania

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

pozostaw to na kilka godzin do kalibracji, naciśnij Ctrl-C, aby wyjść.

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

to przeprowadzi analizę zegara pod kątem najmniejszych kwadratów i znajdzie właściwą korektę

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

Spowoduje to ponowne zsynchronizowanie czasu na twoim komputerze, a ntp powinien wtedy móc go zsynchronizować, ponieważ nie powinien już więcej dryfować.

To wydaje się być bardzo częstym problemem w maszynach wirtualnych. Zobacz następujące strony internetowe:

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

Moją sugestią byłoby zsynchronizowanie z zewnętrznym serwerem czasu i wyłączenie synchronizacji czasu integracji

Mam nadzieję, że to pomaga.

Od jakiegoś czasu korzystamy z Hyper-v na Core. Na początku mieliśmy problemy z synchronizacją czasu ... Powróciłem do najlepszej praktyki z moich starych dni Windows NT.

Patrzę na serwery według systemu operacyjnego. Tworzę Linux, Router, Windows, Novell master.

Być może nie masz teraz Novella, ale wytrzymaj ze mną.

Każdy serwer „master” synchronizuje się z routerem. Router do warstwy. Następnie każdy serwer członkowski ma swój główny serwer systemu operacyjnego i serwer pomocniczy jednego z pozostałych serwerów głównych.

• Linux na router, a następnie na Novell
• Novell do routera, a następnie do systemu Windows
• Windows do routera, a następnie do Linuksa
• Router do warstwy, a następnie do przełącznika rdzenia
• Przełącz rdzeń do warstwy, a następnie do routera

Ostatnim elementem tej strategii jest ... WSZYSTKO ma serwer czasu. Jeśli nie ma serwera czasu, nie będzie on podłączony do sieci. Od tostera, aby przełączyć na telefon PBX na serwery.

Jest to jedna z pierwszych rzeczy, które robię, kiedy dostaję się do nowej pracy, to poświęcić czas na zmapowanie sieci i ustawienie czasu. Następnie mogę to sprawdzić tu i tam i od tego momentu wyeliminować synchronizację czasu.

W maszynach wirtualnych czas płynie wszędzie. Naprawdę chcesz się upewnić, że serwer NTP nie używa zegara lokalnego w żadnej instrukcji „server”, ponieważ zegar lokalny jest zbyt zawodny. Jedną rzeczą, którą zrobiłem, aby pomóc, jest ustawienie atrybutu „maxpoll” dla serwerów na maszynach VMed. Zmusza to usługę NTTP do sprawdzania za pomocą swoich zegarów nadrzędnych znacznie częściej niż skonfigurowane ustawienia domyślne, co pomaga w utrzymaniu jej prawdziwości.

server [timeserver] maxpoll 12

Wypróbuj kilka ustawień, aby zobaczyć, jak daleko trzeba się dostać, aby czas był względnie niezawodny. 12 działa dla mnie, ale każde środowisko jest inne.

Może to zabrzmieć zabawnie, ale założę się, że korzystasz z konfiguracji wieloprocesorowej? Znane są problemy zegar drift niektórzy producenci kaszel AMD kaszlu , które zdarzają się z płytami wielordzeniowych / wieloprocesorowych. Duża aktywność przerwań - jak powiedzmy uruchamianie maszyny wirtualnej lub dwóch - pogarsza dryf. Dryf, którego doświadczasz, brzmi bardzo podejrzanie .

Jeśli chodzi o to, co warto, wolę oferty AMD od Intela, więc nie traktuj tego jako powalenie.

Zakładając, że AD1 był kontrolerem domeny, myślę, że problem mógł być związany z ustawieniem czasu przez serwer Hyper-V na jednej z maszyn wirtualnych gości. Dlatego problem zniknął po przejściu na VMware: serwer VMware nie czuje się zmuszony do synchronizacji swojego zegara z kontrolerem domeny Windows.