Linux – the strategy for detecting time drift in a linux based data centre

The NTP algorithm includes information to allow you to calculate and fix the drift in your server's clock. NTPD includes the ability to use this to keep your clock in sync and will run more accurately than a clock on a computer not running NTPD. NTPD will also use several servers to improve accuracy.

ntpdate does not keep any state to perform this service for you so will not provide the same kind of accuracy. It will allow you to provide it with a list of servers which it will use to attempt to provide you with a better result but this is no substitute for the sophisticated algorithms provided in NTPD that track your drift from each of the servers over time.

NTPDATE corrects the system time instantaneously, which can cause problems with some software (e.g. destroying a session which now appears old). NTPD intentionally corrects the system time slowly, avoiding that problem. You can add the -g switch when starting NTPD to allow NTPD to make the first time update a big one which is more or less equivalent to running ntpdate once before starting NTPD, which at one time was recommended practice.

As for security concerns, ntp servers do not connect back on uninitiated connections, which means your firewall should be able to tell that you initiated the ntp request and allow return traffic. There should be no need to leave ports open for arbitrary connections in order to get NTPD to work.

From the ntpdate(8) man page:

ntpdate can be run manually as necessary to set the host clock, or it can be run from the host startup script to set the clock at boot time. This is useful in some cases to set the clock initially before starting the NTP daemon ntpd. It is also possible to run ntpdate from a cron script. However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited.

Using NTP intermittently (even as often as once per minute) is not going to help a lot. NTP is designed for constant updates/tweaks and is not intended for discrete clock jumps.

If you install a proper NTP daemon you will have better luck. I have found http://www.meinberg.de/english/sw/ntp.htm (a Windows build of the "standard" NTPd implementation) to be reliable in VMs running Windows Server 2003 and 2008.

Four things to note though:

1. Make sure the VMWare time sync methods or turned off for the guests NTP is running, or they and NTP will fight each other. The installer for the NTP build linked above will turn off common time sync software found in the guest, but it can not turn of VMWare's so you'll need to do that yourself.

2. Make sure you have tinker panic 0 specified at the top of your NTPd config file. This stops the NTP service giving up if there is a sudden change in clock drift, which is not uncommon in VMs due to differing loads on the host over time.

3. Use a local time source for the VMs for better local accuracy, and sync this local source with .pool.ntp.org or similar instead of syncing the VMs directly with the outside world. That way if your external network access goes down the VMs still have a clock source more reliable than there own to sync with (and you are being kinder to the public time servers). You could use the VMWare host machine as this local time source, though I tend to have a machine acting as external network gateway and have it perform this job also.

4. Make sure that you don't have the VM's local clock listed as a time source, even as a last-resort fall-back.