I don't believe ntpdate has ever been a recommendation. They started out telling people to use the time sync through vmware tools (which is similar to ntpdate and makes sense in a VMware Workstation environment), then went to using ntpd running as a daemon, potentially with the kernel tuning parameters.
Both vmware tools and ntpdate have the huge problems of jolting the clock to the correct time and the possibility of time going backwards. An ntp daemon, on the other hand, slows down and speeds up the clock to keep it in sync. Anything sensitive to time is going to have a problem with methods that jolt the time around. Using ntpdate in cron is a duct tape solution and doesn't actually fix the problem, it just covers it up. The only real solution is to follow that VMware KB article and get ntpd tuned correctly. If that doesn't work, open a VMware support ticket? However, all of this is really a discussion about clients. Running an ntp server from a VM will be a lot more problematic. You're best bet there is to get a dedicated hardware time source, like a GPS or something. Otherwise, the global ntp pool (http://www.pool.ntp.org) is not a bad solution. It's relatively secure since you're querying a giant pool of servers and it would be pretty amazing if all of them were compromised at once to serve bad time. ❧ Brian Mathis @orev On Tue, Nov 18, 2014 at 4:55 PM, Matt Simmons <[email protected]> wrote: > As of a major version ago on ESXi, it was considered best practice to run > ntpdate in a cron rather than ntpd on VMs, particularly if you weren't > using the most up-to-date VMware tools (and I believe they recommended the > VMware version, rather than open-vm tools). > > I've also seen that behavior when a VM Host had a screwed up NTP config. > > I haven't noticed any significant clock skew during a vmotion, but I've > never checked it. I can give it a shot if you'd like. > > --Matt > > > On Tue, Nov 18, 2014 at 4:50 PM, Mathew Snyder <[email protected]> > wrote: > >> We are currently in a situation where we are being pressured to >> re-engineer our NTP service. We currently host it, along with other >> services, on Windows DCs. Our initial plan is to move NTP off of those >> servers and host it on dedicated Linux servers. >> >> We likely won't get approval for hardware to host NTP and will thus have >> to rely on VMs. This poses a few concerns such as: How will a Vmotion >> affect the service? What happens if access to the sources that we use is >> lost (for whatever reason)? >> >> In the past, all of our VMs would run ntpd normally. That is, as a >> constantly running daemon.. However, we found that time was drifting >> significantly to the tune of several seconds a day on several servers. We >> never figured out why it was happening. Instead, we found that using a cron >> job which runs /usr/sbin/ntpd every five minutes kept time synced up >> nicely. We haven't had any issues since. >> >> However, now Red Hat is telling us we should (need) to be running ntpd as >> a daemon because they are seeing timing issues. Interestingly, this was >> never brought to the attention of us platform engineers so I don't know how >> bad the problem is or how many servers are affected. >> >> The problem could be VMware Tools conflicting with ntpd. But again, we >> don't know what the problem is. Only that we have a workaround-type >> solution that we're being told we have to replace. >> >> This leads to my question to the list: those of you who have cloud >> environments based on VMware solutions, how do you keep time in sync? What >> issues have you encountered and how did you solve those problems? What can >> you recommend for a virtualized NTP solution? >> >> >> -Mathew >> >> "When you do things right, people won't be sure you've done anything at >> all." - God; Futurama >> >> "We'll get along much better once you accept that you're wrong and >> neither am I." - Me >> >> _______________________________________________ >> Tech mailing list >> [email protected] >> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech >> This list provided by the League of Professional System Administrators >> http://lopsa.org/ >> >> > > _______________________________________________ > Tech mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > >
_______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
