Die neue vSphere ESXi Version bringt viele Neuerungen mit. Einige gut, andere sind neuen Herausforderungen für vmWare Admins
NTP never was synchronized.
Wir sehen es öfter, das frisch aktualisierte vsphere ESXi Hosts keine aktuelle Uhrzeit mehr von NTP Servern unter Windows abholen wollen. Es ist nicht nur eine Windows Server Zeitquelle betroffen, aber hier ist der Effekt am einfachsten nachzuvollziehen (und ja auch schon hinlänglich dokumentiert).
Hosts zeigen nach einer Weile den roten Fehler „Zeitsynchronisierung des Hosts wurde unterbrochen“ an.
Im Testprotokoll (Hosts > Konfigurieren > Uhrzeitkonfiguration > Dienste testen) sieht man leider nur den wenig hilfreichen Hinweis „NTP is not synced“ und „NTP never was synchronized.„. Nach der nett übersetzten Angabe „Die Konfiguration funtioniert nicht normal“.
Lösung
Standardmäßig erlaubt Windows NTP Server eine Dispersion („Jitter“) von (großzügigen) 10 Sekunden und fügt diese auch in NTP-Antworten im DISP-Feld bei jedem Abfrageintervall hinzu. ESXi/ESX-Hosts ab 7.0.3 akzeptieren standardmäßig aber keine NTP-Antworten mit einer Root-Dispersion von mehr als 1,5 Sekunden.
Man könnte den Windows-NTP entsprechend anpassen, geht damit aber das Risiko fehlerhaft konfigurierter Domänenmitglieder ein. Oder man ermöglich dem NTP Client von vSphere ESXi einfach eine größere Dispersion. Letzteres machen wir hier.
Wichitg: Unter ESXi 7.0.3 kann man die /etc/ntp.conf nicht mehr manuell bearbeiten, denn sie wird durch das Webinterface (vSphere Client oder vCenter) überschrieben. Das hier ist die „richtige“ Lösung dazu.
NTP-Client auf ESXi-Hosts anpassen
- SSH auf Host aktivieren (Konfigurieren > Dienste > SSH > starten)
- Via SSH zum Host Verbinden und anmelden
- Eine NTP-Konfigurationsvorlagendatei erstellen und diese via
esxclisetzen
# config-Datei mit Inhalt erstellen
printf "server pool.ntp.org\ntos maxdist 30\n" > /tmp/ntphack.txt
# Datei als NTP-Config "anhängen"
esxcli system ntp set -f /tmp/ntphack.txt
# NTP Client neu starten
esxcli system ntp set -e 1Ein paar Sekunden (~20 Sekunden) später hat sich der Fehler selbst behoben und der Hoststatus ist wieder Normal.
