NTP: Why will my host NOT sync time to the NTP source

[JDMils_Interact]

I have 3 V6.0 ESXi hosts in a V6.0 vCenter:

VMware ESXi 6.0.0 build-3380124
VMware ESXi 6.0.0 Update 1

I noticed the time on each host was out by varying amounts, in one case it was out by 15 minutes, so I checked the NTP settings via the GUI and they are set this way:

* Date & Time (in RED): 17:50 1/02/2021
* NTP Client: Running
* NTP Servers: 10.0.0.225, 10.0.0.226

I ran the command NTPQ in the ESXI shell and here's what I see:

remote refid st t when poll reach delay offset jitter
==============================================================================
DCadc03.bs 10.0.0.80 2 u 20 64 377 0.219 740086. 6.986
DCadc04.bs 10.0.0.80 2 u 20 64 377 0.318 740070. 11.974

So it seems to me that the NTP service on the host is set correctly (DCadc03 = 10.0.0.225, DCadc04 = 10.0.0.226) and from the offset, it looks like the time is 12.33 minutes slow.

So how do I force my hosts to sync to the time sources AND set their time to the same? NTPQ is showing a time difference!

I've tried restarting the NTP servers from the host's GUI a few times and it does not sync its time to the DCs. I checked the DCs and their time is correct.

[Lalegre]

Hey @JDMils_Interact,

First confirm that the traffic over port 123 UDP is enabled between your ESXi MGMT interface and the DCs. Without this connectivity it will simply not work.

For more details over NTPQ ran the next commands:

• ntpq -c assoc
• as

With those two commands you will receive more insight about the conditions. Do not modify the ntp.conf file as no changes should be needed.

[berndweyand]

 the value 377 for reach shows that connection to ntp server is succesful.

Are the hosts member of the AD?

sometimes it helps me to switch over to ntp v3: change the entries in /etc/ntp.conf to "server x.x.x.x version 3"

[JDMils_Interact]

The fact that the REACH value is 377 indicates that communications is working fine. Plus, I confirmed with the network team that the port 123 is open.

I ran ntp1 -c assoc with the following results:

[root@Host01:~] ntpq -c assoc

ind assid status conf reach auth condition last_event cnt
===========================================================
1 9258 9024 yes yes none reject reachable 2
2 9259 9024 yes yes none reject reachable 2
[root@Host01:~]

As for the command 'as', that command does not exist on the hosts.

[JDMils_Interact]

The hosts are not members of the domain as Authentication Services Type is set to "Local Authentication".

[berndweyand · Accepted solution]

do a "ntpq -c as" and look whether a condition shows "reject"

note the assid

open ntpq

at the prompt type rv <assid>

look at the value for flash

if flash=400 then insert a "tos maxdist 30" to /etc/ntp.conf and restart ntp

[JDMils_Interact]

Thanks for the help Berndweyand. Here's what I found:

ntpq -c as

ind assid status conf reach auth condition last_event cnt
===========================================================
1 9258 9024 yes yes none reject reachable 2
2 9259 9024 yes yes none reject reachable 2

ntpq
ntpq> rv 9258
associd=9258 status=9024 conf, reach, sel_reject, 2 events, reachable,
srcadr=DCadc03.mydonaim.local, srcport=123, dstadr=172.0.0.1,
dstport=123, leap=00, stratum=2, precision=-6, rootdelay=31.250,
rootdisp=10739.105, refid=10.0.0.80,
reftime=e3c4744e.a574b5b4 Wed, Feb 3 2021 1:01:02.646,
rec=e3c4767a.c86eb1c7 Wed, Feb 3 2021 1:10:18.782, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=0,
flash=400 peer_dist, keyid=0, offset=180144.541, delay=0.337,
dispersion=16.509, jitter=1.416, xleave=0.025,
filtdelay= 0.34 0.28 0.26 0.28 0.32 0.27 0.30 0.31,
filtoffset= 180144. 180142. 180144. 180144. 180144. 180143. 180143. 180141.,
filtdisp= 15.63 16.60 17.59 18.55 19.56 20.52 21.51 22.48
ntpq>

ntpq
ntpq> rv 9259
associd=9259 status=9024 conf, reach, sel_reject, 2 events, reachable,
srcadr=DCadc04.mydonaim.local, srcport=123, dstadr=172.0.0.1,
dstport=123, leap=00, stratum=2, precision=-6, rootdelay=31.250,
rootdisp=10742.462, refid=10.0.0.80,
reftime=e3c47472.994dc809 Wed, Feb 3 2021 1:01:38.598,
rec=e3c47744.c7e923db Wed, Feb 3 2021 1:13:40.780, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=3,
flash=400 peer_dist, keyid=0, offset=180146.158, delay=0.433,
dispersion=16.510, jitter=7.705, xleave=0.021,
filtdelay= 0.43 0.37 0.40 0.35 0.25 0.38 0.32 0.39,
filtoffset= 180146. 180134. 180136. 180136. 180139. 180140. 180143. 180146.,
filtdisp= 15.63 16.60 17.59 18.57 19.56 20.52 21.52 22.48
ntpq>

Previous contents of /etc/ntp.conf:
restrict default kod nomodify notrap nopeer
restrict 127.0.0.1
server 10.0.0.225
server 10.0.0.226
driftfile /etc/ntp.drift

I added:
tos maxdist 30

I then restarted the ntpd service:

/etc/init.d/ntpd restart

------------------------------------------------------------------------------

Looks like it's working now!

Here are the new values.

ntpq -p

remote refid st t when poll reach delay offset jitter
==============================================================================
*DCadc03.myd 10.0.0.80 2 u 9 64 377 0.276 0.147 6.203
+DCadc04.myd 10.0.0.80 2 u 30 64 377 0.369 -14.097 9.219

ntpq -c as

ind assid status conf reach auth condition last_event cnt
===========================================================
1 59031 961a yes yes none sys.peer sys_peer 1
2 59032 946a yes yes none candidate sys_peer 6

Based on your proposed soltion of "tos maxdist 30", I Googled this and found this link:

https://kb.vmware.com/s/article/1035833

Does this mean that we have to modify every Windows DC which is acting as an NTP time source AND every host connecting to these DCs?

[berndweyand]

did you modify your dc ? note that this kb  handles also old windows server versions. i had never changed my dc

[JDMils_Interact]

The KB says to modify the DCs acting as NTP sources, and I could initiate that via Group Policy, however it's working now so I think I will leave it as is. Thank you again for the solution!

[Compboy]

From esxi 7.0 and up you need do to edit an other way here is described how:

https://kb.vmware.com/s/article/87488

I was search for this a long time

[PatrickDLong]

Anybody know how to REMOVE a line from ntp.conf in ESXi 7.0 U3?  I saw conflicting guidance about which tos maxdist value to use (KB 86255 indicates to use a maxdist of 15 while KB 87488 and 1035833 both indicate a maxdist value of 30)  and I ended up accidentally running the process twice and injecting two lines with different values.  Now my ntp.conf file includes TWO tos maxdist lines as shown:

[root@hostname:~] cat /etc/ntp.conf
# Do not edit this file, config store overwites it
restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
driftfile /etc/ntp.drift
server xx.xx.xx.xx
server xx.xx.xx.xx
tos maxdist 15
tos maxdist 30
logconfig +clockstatus +peerstatus +sysstatus +syncstatus

and just FYI, the KB 86255 ending statement " Note: Please note that the "tos maxdist" config will not persist across reboot ." does not appear to be correct.  I have rebooted multiple times and these settings remain in my ntp.conf file after every reboot.

[Kinnison]

@PatrickDLong,

As far as I know what is injected into an object contained in the so-called "configstore" is always persistent on reboot (or so it seems).

So, either one starts manipulating objects using the "configstorecli" interface, in my opinion it is better to avoid if you do not know exactly what you are doing or, in the case of NTP settings, it is easier to set a file that contains all the necessary settings (a bit like once you manually edited the ntp.conf file) and then import it with the command:

esxcli system ntp set --file your_full_NTP_configurationfile_includingpath
esxcli system ntp set --enabled 1

Why do I need to explicitly re-enable the NTP service? Because I realized that by injecting a new NTP configuration file into the "configstore" the service had been set as disabled (in my specific case, your mileage may vary) and so it remains at a subsequent restart, so I suggest you to check the status of the changes made with the command:

esxcli system ntp get

Then you may edit the ntp.conf file and restart the service to avoid a reboot that might be inconvenient at the moment. The reason why I used the method I described to you is because I wanted to set my time source as preferred over the other time sources configured and reachable via the internet.

Regards,
Ferdinando

A note: In case of doubts and before acting, besides asking I suggest you consult the online help which (my personal opinion) is quite well done.