Bei der Virtualisierung von Computern ticken die Uhren etwas anders. Diese Aussage kann durchaus wörtlich genommen werden und zeigt bereits ein grundlegendes Problem auf.

Virtualisiert man Computer, so sollte sichergestellt werden, das diese virtuellen Maschinen oder Gäste regelmäßig ihre Systemzeit überprüfen und ggf. anpassen. Gesetzt den Fall das die Systemzeit einer virtuellen Maschine nicht mit dem Rest des Netzwerkes übereinstimmt, so können Probleme bei der Kommunikation auftreten. Beispielsweise kann bei zu großer Differenz eine Anmeldung verweigert werden.

Windows versucht per Standard mittels NTP einen Abgleich mit dem Server “time.windows.com” einmal pro Woche. In einem Domänen-Netzwerk übernimmt das der Domänencontroller, der die FSMO-Rolle “PDC-Emulator” inne hat und gilt als Zeitgeber für alle Domänen-Mitglieder.

Unter Hyper-V wird per Standard über die Integrationsdienste die Zeit mit dem Host-System synchronisiert. Zu erkennen ist das unter anderem an dem gestarteten Dienst “Hyper-V-Dienst für Zeitsynchronisation”, als auch im Hyper-V-Manager in den Einstellungen des virtuellen Computers unter “Integrationsdienste” als auch in der Eingabeaufforderung mit dem Befehl

w32tm /query /source

Dieser Befehl gibt unter Windows Server 2008 R2 als Ergebnis

Local CMOS Clock

aus, sofern die interne Uhr verwendet wird oder eine entsprechend konfigurierte andere Zeitquelle. So sieht sie Ausgabe bei einem virtualisierten Windows Server 2012 R2 wie folgt aus:

VM IC Time Synchronization Provider

Unter VMware ist per Standard die Zeitsynchronisation über die VMware Tools deaktiviert, so das eine Abfrage “Local CMOS Clock” ergibt und Windows wiederum per NTP die Zeit abgleicht.

Ein sofortiges Aktualisieren lässt sich mit folgenden Befehl auslösen:

w32tm /resync /nowait

Dies kann notwendig sein, wenn man die Zeitquelle geändert hat oder im Fehlerfall möglichst schnell die Zeit wieder synchron haben möchte.

Hilfreiche Links

Faq-O-Matic: Virtuelle DCs – Zeitprobleme vermeiden

Faq-O-Matic: Zeitsynchronisation in virtuellen Umgebungen

TechNet: Ausführen von Domänencontrollern in Hyper-V (Abschnitt “Zeitdienst”)

TechNet: Konfigurieren des Windows-Zeitdiensts

TechNet: Time Services for a Domain Controller on Hyper-V

TechNet: W32tm

Synchronize time with external NTP server on Windows Server 2008 (R2)

TecChannel: Windows Server 2008 R2 mit einer externen Zeitquelle synchronisieren

SBS2011 Zeit in Virtueller Maschine

Persönliche Erfahrungen

Bislang sind an uns Zeit-Synchronisations-Probleme weitestgehend vorübergegangen. Aktuell kam es kurz vor Weihnachten bei einem Kunden zu der Situation, das die Integrationsdienste eines unter Hyper-V virtualisierten Windows Server 2008 R2 die Systemzeit nicht mehr abglichen und damit nicht nur die Uhrzeit dieses Servers, sondern auch der gesamten Arbeitsplätze (es handelte sich um den einzigen Domänencontroller im gesamten Netzwerk) um exakt 30 Minuten vorgingen.

Abhilfe schaffte das Neustarten des Dienstes “Hyper-V-Dienst für Zeitsynchronisation” im betroffenen virtuellen Computer als auch das De-/Aktivieren von “Zeitsynchronisation” in den Einstellungen des betroffenen virtuellen Computers im Hyper-V Manager.

Die einzige sonst falsch laufende Uhr an die ich mich entsinnen kann, war vor längerer Zeit mal unter ArchivistaVM, aber das ist schon lange her.

Update 07.01.2014

Kleiner Tipp am Rande: Server-Eye bietet einen Sensor zur Überwachung der Systemzeit inkl. Korrektur bei zu großer Abweichung an:

Update 11.02.2014

Beim gleichen Kunden war die Zeit nun wieder ca. 20 Minuten voraus. Diesmal genügte das Neustarten des Dienstes “Hyper-V-Dienst für Zeitsynchronisation”. Da uns die Sache aber nun (in diesem Fall) zu instabil schien, haben wir die Zeit-Synchronisation dieses virtuellen Computers deaktiviert (sowohl in den Einstellungen des virtuellen Computers, als auch den entsprechenden Dienst deaktiviert) und eine externe Zeitquelle konfiguriert.

Update 21.03.2014

Gestern war’s bei besagtem Kunden wieder so weit und wieder waren es 20 Minuten. Diesmal war der Windows Server der Meinung, er akzeptiere eine Securepoint UTM nicht mehr als Zeitquelle. Ironischerweise erhält man bei folgender Abfrage eine positive Antwort:

C:\Windows\system32>w32tm /query /status

Sprungindikator: 0(keine Warnung)
Stratum: 5 (Sekundärreferenz - synchr. über (S)NTP)
Präzision: -6 (15.625ms pro Tick)
Stammverzögerung: 0.0689392s
Stammabweichung: 0.0819944s
Referenz-ID: 0x0A000001 (Quell-IP:  IP-DER-SECUREPOINT-UTM)
Letzte erfolgr. Synchronisierungszeit: 19.03.2014 16:32:31
Quelle: 10.0.0.1
Abrufintervall: 10 (1024s)

Im Ereignisprotokoll findet man dann aber wieder den Hinweis, dass das Peer nicht erreichbar wäre und als Zeitquelle verworfen wird. Nun ja, jetzt (mal wieder) “ptbtime1.ptb.de” als Quelle gesetzt und plötzlich war’s wieder synchron. Als workaround wurde nun als Skript bzw. Aufgabe folgendes hinterlegt und dies wird einmal täglich ausgeführt:

@echo off

w32tm /config /manualpeerlist:ptbtime1.ptb.de /syncfromflags:manual /reliable:yes

w32tm /config /update

net stop w32time && net start w32time

w32tm /resync /rediscover

Mal sehen, wie lange es diesmal gut geht. Und so ganz nebenbei: Der Kunde hat aktuell kein Server-Eye (Wartungsvereinbarung ist ausgelaufen und wurde bis dato nicht verlängert), von daher konnten wir das nicht “proaktiv” mitbekommen.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.