ESXi host has lost time synchronization error prior to version ESXi 7.0 Update 3c

Products

• VMware vSphere ESXi 7.0

Issue/Introduction

To synchronizing NTP when the root dispersion has a large value

• ESXi host has lost time synchronization error prior to version ESXi 7.0 Update 3c

• In  var/log/syslog.log we see similar to below

syslog.1:9829:yyyy-mm-ddThh:mm:ss.msZ ntpd[2157160]: no peer for too long, server running free now
 

• In var/log/vmkwarning.log we see similar to below

vmkwarning.log:2229:yyyy-mm-ddThh:mm:ss.msZ cpu28:2157160)WARNING: NTPClock: 1764: system clock synchronized to upstream time servers
vmkwarning.log:2230:yyyy-mm-ddThh:mm:ss.msZ cpu34:2157160)WARNING: NTPClock: 1457: system clock stepped to 1633649230.381665000, no longer synchronized to upstream time servers
vmkwarning.log:2231:yyyy-mm-ddThh:mm:ss.msZ cpu34:2157160)WARNING: NTPClock: 1764: system clock synchronized to upstream time servers
vmkwarning.log:2239:yyyy-mm-ddThh:mm:ss.msZ cpu28:2157160)WARNING: NTPClock: 1457: system clock stepped to 1633652786.527106000, no longer synchronized to upstream time servers
vmkwarning.log:2240:yyyy-mm-ddThh:mm:ss.msZ cpu28:2157160)WARNING: NTPClock: 1764: system clock synchronized to upstream time servers
vmkwarning.log:2254:yyyy-mm-ddThh:mm:ss.msZ cpu39:2157160)WARNING: NTPClock: 1457: system clock stepped to 1633656212.693259000, no longer synchronized to upstream time servers
vmkwarning.log:2255:yyyy-mm-ddThh:mm:ss.msZ cpu39:2157160)WARNING: NTPClock: 1764: system clock synchronized to upstream time servers

 

• If NTP configuration is correct, but the NTP daemon does not synchronize to the listed NTP server.
  For example
  [root@esxi]: ntpq -p
       remote refid st t when poll reach delay offset jitter
  ==============================================================================
   <domain controller> 1 u 35 64 377 0.696 -83.934 3.527

 

•  The list of NTP associations
  [root@esxi]:/tmp] ntpq -c associations

ind assid status conf reach auth condition last_event cnt
===========================================================
  1 7023 9014 yes yes none reject reachable 1

 

• Next, look at NTP variables associated with this host:

[root@esxi]:/tmp] ntpq -c "rv 7023"
associd=7023 status=9014 conf, reach, sel_reject, 1 event, reachable,
srcadr= <domain controller>, srcport=123, dstadr=<ipaddress>,
dstport=123, leap=00, stratum=1, precision=-6, rootdelay=0.000,
rootdisp=10682.327, refid=xyz,
reftime=e520d4c8.50147e3c <Day, Month date year Time>,
rec=e521b5cc.076edf15 <Day, Month date year Time>, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=59,
flash=400 peer_dist, keyid=0, offset=-90.556, delay=1.333,
dispersion=16.515, jitter=5.877, xleave=0.031,
filtdelay= 1.33 0.63 0.60 0.70 0.64 0.55 0.64 0.56,
filtoffset= -90.56 -84.03 -84.60 -83.93 -83.91 -83.85 -89.81 -85.07,
filtdisp= 15.63 16.62 17.61 18.58 19.54 20.50 21.48 22.47

The output indicates that the NTP server has been rejected, although it's reachable

 

Cause

This occurs when the root dispersion value is high due to time servers not syncing

Resolution

This issue is resolved in VMware vSphere ESXi 7.0 Update 3c. To download go to - Download Broadcom products and software

ESXi NTP can be forced to accept time from  AD time sources root dispersion has a large value . This is described here Synchronizing ESXi/ESX time with a Microsoft Domain Controller

Note: For "tos maxdist" config to be persistent across reboot, ESXi version should be running at  version 7.0U3c

 

Additional Information

Impact/Risks:
None