How can I resolve the drifting clock for my Virtual Machine?
- Read you vmware documentation carefully before you listen to anyone. We are running ESX5.
Timekeeping best practices for Linux guests among other things says: Ref: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427
NTP Recommendations Note: VMware recommends you to use NTP instead of VMware Tools periodic time synchronization. NTP is an industry standard and ensures accurate time keeping in your guest. You may have to open the firewall (UDP 123) to allow NTP traffic.
This is a sample /etc/ntp.conf:
tinker panic 0
restrict 127.0.0.1
restrict default kod nomodify notrap
server 0.vmware.pool.ntp.org
server 1.vmware.pool.ntp.org
server 2.vmware.pool.ntp.org
driftfile /var/lib/ntp/drift
This is a sample (RedHat specific) /etc/ntp/step-tickers:
0.vmware.pool.ntp.org
1.vmware.pool.ntp.org
The configuration directive tinker panic 0 instructs NTP not to give up if it sees a large jump in time. This is important for coping with large time drifts and also resuming virtual machines from their suspended state.
Note: The directive tinker panic 0 must be at the top of the ntp.conf file.
It is also important not to use the local clock as a time source, often referred to as the Undisciplined Local Clock. NTP has a tendency to fall back to this in preference to the remote servers when there is a large amount of time drift.
An example of such a configuration is:
server 127.127.1.0
fudge 127.127.1.0 stratum 10
Comment out both lines.
After making changes to NTP configuration, the NTP daemon must be restarted. Refer to your operating system vendor’s documentation.
Just to add some data about why NTPD is not a good solution. NTPD is a daemon that tries to compensate for the local clock drift; if the "internal clock" drifts away by X number of seconds in a day, then instead of jumping ahead/back like a forced command as in "ntpdate " NTPD tries to add/remove some cycles to the clock so that in time, normally within 15 minutes, the clock runs accurately enough and the compensation overcomes this X numbers of seconds that the servers gains/losses in a day. This has the advantage that you won't see any time in the day repeated, which is a MUST for for transactional systems.
But to be able to do this, NTPD requires that the local clock does a reasonably good job, which normally means that the local clock won't drift apart more than 42 seconds a day (more or less; I am not sure of the exact number). This normally is a problem in Virtual Machines, since the the clock is software controlled, so if the HOST has too much overload, you could see that the CLIENT's clock will run more slowly, and if it doesn't then the clock could run too fast. The problem here for NTPD is that the local clock is not reliable and doesn't have a constant drift in time; it may be more or less depending on the overload of the HOST system.
So in this case it's better to install the client tools as has been suggested, and synchronize the CLIENT clock with the HOST's clock (normally referred as the "wall clock")
vmware have a really good PDF doc on this problem.
Basically, the host will slew the ticks delivered to your guests as it can. Don't run NTP or timed or junk like that. Just install vmware-guestd and let the host slew your ticks. If you still lose ticks, then any other solution will have major drift too.
If you can, use a guest OS that has a low frequency tick rate. Newer versions of Linux come with 1000Hz ticks, but it used only to be 100Hz. That seems easier for the host to deliver. A kernel rebuild is usually needed to change the HZ value.