Die Hyper-V-Maschine verschiebt die Zeit, selbst mit NTP

Behoben Das Problem war Hyper-V auf diesem Computer. Ich habe Hyper-V entfernt, VMware Server installiert und dieselbe VM ausgeführt. Zeitsynchronisationsprobleme verschwanden (<100 ms Unterschied nach einem Tag).

Mein Setup ist wie folgt:

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 und S1 haben eine feine Synchronisation - das Streifendiagramm zeigt einen Unterschied von weniger als 100 ms.

S2 driftet wie verrückt. Hier ist ein Teil des Stripcharts gegen 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 

In 20 Sekunden driftete es über eine Sekunde. Wenn ich es manuell auf 1s zurücksetze, driftet es innerhalb weniger Minuten etwa 2 Sekunden zurück. Über Nacht ging es von ~ 2s bis ~ 5s. Die Linux-VM in S2 ist perfekt mit AD1 synchronisiert.

Hier ist die Konfiguration:

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

Ich habe mir das Ereignisprotokoll angesehen und abgesehen von Warnungen bezüglich der Synchronisierung (nachdem es nicht mehr synchron ist) gibt es keine weiteren Warnungen.

Wie kann ich dieses Problem beheben? Es ist die einzige Maschine, die dieses Problem hat. Allen anderen Maschinen (physisch und virtuell) geht es gut.

Bearbeiten: Zur Verdeutlichung: Die Integration der VM (AD1) ist deaktiviert und wird mit time.nist.gov synchronisiert. AD1 ist in Ordnung. Es ist die physische Maschine S1, die nicht mit AD1 synchronisiert werden kann und überall hin driftet. Alle anderen physischen Server können problemlos mit AD1 synchronisiert werden.

Update Es scheint also ein Problem beim Ausführen der VM zu sein. Die Uhr rutscht bei ausgeschalteter VM langsam ab. Beim Einschalten verliert es sofort Sekunden. Ich habe die VM so eingestellt, dass sie nur die Hälfte der Ressourcen verwendet, und das scheint sie vorerst leicht gemildert zu haben. Vielen Dank!

Aus Ihrer Beschreibung geht hervor, dass auf der Hauptplatine des Servers S2 ein tatsächliches Hardwareproblem mit der RTC ( http://en.wikipedia.org/wiki/Real-time_clock ) vorliegt.

Der Hyper-V-Gast erhält seine Uhr zunächst vom Host (HYV1). Da Sie jedoch die Hyper-V-Zeitsynchronisierung deaktiviert haben, werden alle weiteren Uhraktualisierungen von NIST abgerufen (was einwandfrei funktioniert). Ihre Linux-VM ist nicht in Hyper-V integriert, daher wird die Zeit von der Domäne abgerufen, was ebenfalls einwandfrei funktioniert. Ihre anderen physischen Maschinen funktionieren einwandfrei. Es handelt sich nur um einen einzelnen physischen Server, der alle 20 Sekunden eine Drift von 1 Sekunde aufweist (was eine verrückte Drift ist). Die Zeit driftet viel schneller, als die Netzwerkzeitsynchronisierung die Uhr auf die richtige Zeit zurücksetzen kann (was, wenn ich mich richtig erinnere, alle 8 Stunden erfolgt).

Wenn Sie Hyper-V als Ursache für den Fehler in S2 ausschließen möchten, erstellen Sie einen Starteintrag "kein Hypervisor", starten Sie ohne Hyper-V neu und prüfen Sie, ob die Zeitverschiebung weiterhin besteht. Anweisungen hier: http://blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

-Sean

Das Problem liegt in der virtuellen Implementierung der verschiedenen Taktquellen (tsc, jiffies, acpi_pm, cmos_trc). Der beste Weg, um dieses Problem mit HyperV zu beheben, besteht darin , die von HyperV bereitgestellte Uhrensynchronisierung für Ihren Gastcomputer zu deaktivieren und dann die Zeit mit adjtimex anzupassen. Auf einem Ubuntu-Gastbetriebssystem tun Sie dies ...

# 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

und beantworte beide Fragen mit Nein

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

Lassen Sie das einige Stunden laufen, um es zu kalibrieren, und drücken Sie Strg-C, um es zu beenden.

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

Dadurch wird eine Analyse der kleinsten Quadrate Ihrer Uhr durchgeführt und die richtige Einstellung gefunden

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

Dadurch wird die Zeit auf Ihrem Computer neu synchronisiert und ntp sollte dann in der Lage sein, sie synchron zu halten, da sie nicht mehr zu stark driften sollte.

Dies scheint ein sehr häufiges Problem bei VMs zu sein. Siehe die folgenden Websites:

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

Mein Vorschlag wäre, nur mit einem externen Zeitserver zu synchronisieren und die Synchronisierung der Integrationszeit zu deaktivieren

Hoffentlich hilft das.

Wir führen Hyper-v seit einiger Zeit auf Core aus. Zuerst hatten wir Probleme mit der Zeitsynchronisierung ..... Ich kehrte zu einer bewährten Methode aus meinen alten Windows NT-Tagen zurück.

Ich schaue mir die Server nach Betriebssystem an. Ich erstelle einen Linux-, Router-, Windows- und Novell-Master.

Vielleicht haben Sie Novell jetzt nicht, aber tragen Sie es mit mir.

Jeder "Master" -Server wird mit dem Router synchronisiert. Der Router zur Schicht. Dann hat jeder Mitgliedsserver seinen Master-Betriebssystemserver und einen sekundären eines der anderen Master.

• Linux zu Router, dann zu Novell
• Novell zu Router, dann zu Windows
• Windows zum Router, dann zu Linux
• Router zu Stratum, dann zu Core Switch
• Core Wechseln Sie zu Stratum und dann zu Router

Das letzte Stück dieser Strategie ist ... ALLES hat einen Zeitserver. Wenn es keinen Zeitserver hat, wird es nicht an das Netzwerk angeschlossen. Vom Toaster zum Wechsel zur Telefonanlage zu Servern.

Dies ist eines der ersten Dinge, die ich tue, wenn ich zu einem neuen Job komme. Ich verbringe die Zeit damit, das Netzwerk zuzuordnen und die Zeit festzulegen. Ich kann es dann einfach hier und da überprüfen und die Zeitsynchronisation von diesem Punkt an als Problem beseitigen.

In VMs vergeht die Zeit überall. Sie möchten wirklich sicherstellen, dass der NTP-Server die lokale Uhr in keiner 'Server'-Anweisung verwendet, da die lokale Uhr zu unzuverlässig ist. Eine Sache, die ich getan habe, um zu helfen, ist das Festlegen des Attributs "maxpoll" für Server auf VMed-Computern. Dies zwingt den NTP-Dienst dazu, viel häufiger als die konfigurierten Standardeinstellungen mit seinen Upstream-Uhren zu überprüfen, was dazu beiträgt, dass dies wahr bleibt.

server [timeserver] maxpoll 12

Probieren Sie einige Einstellungen aus, um festzustellen, wie weit Sie nach unten müssen, um die Zeit relativ zuverlässig zu halten. 12 funktioniert für mich, aber jede Umgebung ist anders.

Das mag lustig klingen, aber ich wette, Sie führen ein Multiprozessor-Setup aus? Es gibt bekannte Taktdriftprobleme mit bestimmten Herstellern Husten AMD Husten , die mit Multi-Core / Multi-Sockel - Mainboards passieren. Starke Interrupt-Aktivitäten - wie zum Beispiel das Ausführen einer oder zweier virtueller Maschinen - verschlimmern die Drift. Die Drift, die Sie erleben, klingt sehr verdächtig .

Für das, was es wert ist, bevorzuge ich AMDs Angebote gegenüber Intel, also nimm das nicht als Schlag gegen sie.

Angenommen, AD1 war ein Domänencontroller, liegt das Problem möglicherweise daran, dass Ihr Hyper-V-Server seine Zeit von einer seiner eigenen Gast-VMs aus eingestellt hat. Aus diesem Grund ist das Problem beim Wechsel zu VMware behoben: Der VMware-Server ist nicht gezwungen, seine Uhr mit einem Windows-Domänencontroller zu synchronisieren.