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

10

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!

MichaelGG
quelle

Antworten:

5

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

Sean Earp
quelle
OK, ich werde das ausprobieren.
MichaelGG
OK, ich habe die VM heruntergefahren (HyperV wurde nicht deaktiviert). Die Uhr ist jetzt viel besser. Nach ca. 3 Minuten ist es nur ca. 100ms verloren. Es verliert immer noch, aber viel weniger als zuvor. Sobald ich die VM einschalte, wird sie verrückt. Es dauert 1 Sekunde in wenigen Sekunden. Vielleicht, weil die VM keine Integrationsdienste hat?
MichaelGG
Michael: Dies scheint hier nicht im linken Feld zu sein, aber führen Sie irgendeine Art von Multimedia-Anwendung auf der übergeordneten Partition von S2 aus? -Sean
Sean Earp
Nee. Das Problem war schließlich Hyper-V. Hyper-V wurde entfernt, Vmware Server wurde gestartet und dieselbe VM wurde ausgeführt - keine Probleme. Die Zeitsynchronisation ist <100 ms.
MichaelGG
3

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.


quelle
2

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.

rmwetmore
quelle
Genau das habe ich getan. Die VM (AD1) hat die Integration deaktiviert und wird mit time.nist.gov synchronisiert. AD1 ist in Ordnung. Es ist die physische Maschine S1, die die Synchronisation mit AD1 verliert.
MichaelGG
Wie dieser Kerl sagt - um MaxAllowedPhaseOffset auf 1 zu setzen. Jaylee.org/post/2009/10/14/…
gbjbaanb
2

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.

Thomas Denton
quelle
Hmm, ich werde versuchen, eine manuelle Sekundärseite hinzuzufügen und zu sehen, ob das hilft. Aber alles andere funktioniert gut - nur diese eine physische Maschine driftet.
MichaelGG
Was ist das für eine Maschine? Dell / HP / IBM - Andere? Ich hatte Dell-Boxen, die einfach immer optimiert werden müssen.
Thomas Denton
Dell PowerEdge 850 mit einem Pentium D920 (oder etwas in der Nähe - 2,8 GHz, macht Intel VT.)
MichaelGG
Die PE 350 würden sehr schlecht driften. aber das war vor Jahren. Ich habe keinen 850 verwendet, aber die SC1435-Server, die analog zum 850 billiger sind, funktionieren einwandfrei. Vielleicht schauen Sie sich die Umgebung an, vibriert der Server und der cmos-Akku ist locker oder so etwas Verrücktes?
Thomas Denton
1

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.

sysadmin1138
quelle
Ich habe es mit einer Abfragezeit von 2 oder 4 (16 Sekunden) versucht. Driftet immer noch wahnsinnig.
MichaelGG
1

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.

Avery Payne
quelle
Auf dem Computer wird ein Pentium D930 ausgeführt, es handelt sich also um ein Multicore-Setup. Ich werde die VMs deaktivieren und sehen, was passiert.
MichaelGG
2
Das Beenden eines Kerns auf der VM half bei der Synchronisierung auf dem Host.
MichaelGG
1

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.

Skyhawk
quelle