Oh, you should have mask in there, not netmask.mshafiuddin wrote: ↑2019/03/10 19:38:29Mar 10 17:57:11 prod1 ntpd[23030]: line 18 column 23 syntax error, unexpected T_String, expecting T_EOC
Mar 10 17:57:11 prod1 ntpd[23030]: syntax error in /etc/ntp.conf line 18, column 23
But I think that is probably irrelevant. I think your problem is more of an ESXi problem than a CentOS problem.
The "reach 377" means your CentOS ntpd was able to connect to the upstream time source without issues. 11111111 = 377 in octal, and 377 is the maximum reachability value. And because you have the "iburst" keyword in your config for the upstream time server, ntpd will send a burst of requests at startup and will typically be able to synchronize in a few seconds.
You ran ntpdate twice, but the offset in the second invocation was higher than what I would have expected. The first invocation should have set the clock close to the upstream's clock, and the offset during the 2nd invocation should be really small, a few milliseconds max. Yours was 59 milliseconds. I think this means your guest's clock is locked to your ESXi host's clock, and attempts to change the clock won't succeed. Luckily for you the host's clock seems to be close to your upstream clock, so there's not much of a difference.
I don't have access to ESXi myself, but I think there might be a setting in VM Options -> Time. If the "Synchronize guest time with host" option is checked, ntpd won't be able to set the clock by itself. If that option is checked and you want to let ntpd take care of the time, consider unchecking that option. An alternative would be to make sure your ESXi host's clock is synchronized and let it take care of the clock. In this situation you would not need to run ntpd at all.
And yes, you should arrange that the NTP server's clock is correct. You don't need a GPS clock for it, pointing it to pool.ntp.org is sufficient for the vast majority of use cases. Using the pool will give you a correct time within a few milliseconds, especially if you use multiple upstream servers. If the clock of your organization's time server is correct, you can (and probably should) use that as the time source for the other machines in your network.
