Ich bin erst kürzlich in diese Falle getappt, denn bei zeitkritischen VMs, wie beispielsweise Domain Controller, welche auf VMware vSphere betrieben werden, muss man eine kleine Besonderheit beachten. Da eine falsche Uhrzeit durchaus weitreichende Folgen haben kann, gibt es daher hier mal einen kleinen Artikel zu dem Thema. Folgendes Problem ist aufgetreten. Ein NTP Server auf Linux Basis (welcher auch als NTP Server für die Domain Controller zuständig war) hat zunächst ohne direkt erkenntliche Ursache die falsche Uhrzeit und weißt eine große Abweichung zu den konfigurierten NTP Servern im Internet auf:
In dem Screenshot ist zu erkennen, dass die lokale Systemzeit der VM um über 13 Sekunden von der Zeit der NTP Server im Internet abweicht. Die erste Vermutung war, dass die lokale Systemzeit mit der Zeit des ESXi Servers abgeglichen wurde, jedoch war diese Option in den Einstellungen der VM deaktiviert:
Tatsächlich wies der ESX Server aber die entsprechende Zeitdifferenz auf. Zusätzlich ist aufgefallen, dass die VM kürzlich per vMotion auf den ESX Host mit der entsprechenden Zeitdifferenz verschoben wurde. Die Nachforschungen haben dann den folgenden VMware KB Artikel zu Tage gefördert:
Hier ist dann folgendes zu lesen:
Es ist also folgendes passiert: Die VM wurde mit vMotion auf einen ESX Server mit abweichender Uhrzeit verschoben. Direkt nach dem vMotion Vorgang wird die Systemzeit der VM durch die VMware Tools mit der Uhrzeit des ESXi Servers synchronisiert, somit hat auch die VM die falsche Uhrzeit. Wenn die VM nun also als Zeitquelle für das Netzwerk dient, beispielsweise weil es sich um einen Domain Controller oder um einen Linux NTP Server handelt, wird nun die falsche Uhrzeit an die NTP Clients verteilt. Ein weiterer Fallstrick ist hier die Funktionsweise des NTP Protokolls selbst: Im ersten Screenshot ist zu erkennen, dass die Systemzeit der eine Abweichung zu den konfigurierten NTP Servern im Internet aufweist. Die Systemzeit wird aber im Falle einer größeren Abweichung nicht einfach wieder via NTP korrigiert, sondern langsam angeglichen, dies soll “Zeitsprünge” vermeiden. Konkret korrigiert NTP die Zeit bei einer Abweichung alle 60 Sekunden um 50ms. Es dauert also eine ganze Weile bis eine Differenz von 13 Sekunden ausgeglichen ist.
Die Auswirkungen einer falschen Uhrzeit im Netzwerk können sehr weitreichend sein (man glaubt kaum, was da alles so passieren kann, ich möchte nicht weiter drüber sprechen). Die Lösung aus dem VMware KB Artikel sollte also für alle zeitkritischen VMs umgesetzt werden, insbesondere für Domain Controller, Linux NTP Server, VoIP Telefonanlagen, OTP / 2FA Server.
In vSphere 7 kann diese Option übrigens direkt in den Einstellungen der VM abgeschaltet werden, während die VM läuft (VM auf ESXi 6.7 oder früher müssen runtergefahren werden, um die Zeitsynchronisation abzuschalten):
Auch ein Hinweis wurde hinzugefügt, welche die Beschreibung aus dem VMware KB Artikel enthält:
Vielleicht hilt es ja dem ein oder anderem.
Hallo,
ich nutze schon sehr lange die Firewall im RZ als Zeitserver im Netz. Bei allen Geräten NTP auf diese IP konfiguriert. Hilft es diesen Fehler zu vermeiden?
So 1-3 Mal im Jahr nutze ich VMotion für Wartungen, bis jetzt ohne Probleme, ich war mir aber auch nicht über Probleme bewusst.
Grüße und danke, Frank
Anstatt das Problem zu umgehen, sollte man lieber in den Einstellungen des VMWare Host, den NTP Client beim Start des Hosts aktivieren und einen NTP Server angeben. Am besten einen NTP Server, der nicht als VM läuft. z.B. die lokale Firewall. Alternativ einen der Zeitserver im Internet. Dann kann sich die VM beim verschieben gleich eine korrekte Zeit holen und Differenzen treten gar nicht erst auf.
Genau das ist der richtige Weg! Wird auch in unzähligen Artikeln zur ESXi Einrichtung als Best Practices hervorgehoben. Wer den NTP am Host nicht richtig oder gar nicht konfiguriert hat, hat da schon den Fehler begangen und sich nicht an Empfehlungen gehalten.
Genau DAS ist die einzig richtige Lösung. Die Ursache beheben – nicht den Folgefehler.
Ich stehe glaub ein wenig auf dem Schlauch.
Soll ich nun komplett deaktivieren oder Synchronize Time with Host abahaken?
– „Synchronize Time mit Host“ in jedem Fall abhaken, wenn die VM NTP Host ist. Besser wäre hier ein physikalischer Host oder verlässlicher Router (Firewall)
– Wenn doch die VM, dann vor einem vmotion, snapshot, … (wie oben beschrieben) prüfen, ob die Zeit am ESXi Host identisch ist.
Ich persönlich würde die VM eher abschalten…
#Wartungsfenster
Kurze Frage: Muss an der Konfiguration des NTP Servers oder den anderen Servern der Domain etwas angepasst werden am w32tm Dienst? Oder muss sonst etwas beachtet werden?
Zum Hintergrund: Unsere VMs befinden sich in einem großen Rechenzentrum und ich habe leider keinen Zugriff auf das vCenter.
Letzte Woche kam es zu massiven Problemen bei der Anmeldung. Ich hatte zuerst unseren RDCB im Verdacht, aber dieses Thema würde auch sehr gut passen. Laut den Jungs vom Rechenzentrum ist vMotion aktiviert und Sync für alle VMs deaktiviert.
Danke im Voraus für alle Antworten!
Kleiner Tipp von mir wen Zeitkritische System in betrieb sind wie AD, DB-Server etc. die DRS Migration auf das kleinste oder die zweite Stufe stellen damit nicht bei jedem kleinen anstieg der Last Migriert wird, aber falls es wirklich nötig wird die VM dennoch migriert wird.
Wen nämlich nicht permanent hin und her migriert wird passieren die Fehler eigentlich nicht oder nur sehr sehr selten.
Ich liebe diesen Fehler :D
Ich weiß nicht wie oft das schon bei uns passiert ist.