How can I resolve the drifting clock for my Virtual Machine?

Question

My Virtual Machine's clock drifts pretty significantly. There's documentation out there about dealing with this, but nothing seems to be working very well.

Anyone have any suggestions, things that worked well for them, ...

Supposedly updating regularly via ntp is not a good solution.

Solution 1

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.

Solution 2

1. 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.

Solution 3

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")

Solution 4

There is no definitive answer because several methods exist, each having its pros and cons. What one to chose depends on your tasks, server load, operating system, etc.

Read vmware_timekeeping.pdf for thorough understanding of the issue.

Quick recipes for Linux could be found in a separate KB article

Solution 5

The best solution to this problem is (if locally connected) Install Local NTP server and put "service ntp restart" in an infinite loop with sleep time 30 seconds approx. by writing a code in "/etc/init.d/rc.local" file. Reboot system and time will be synchronized with the server computer.

View more solutions

Comments

[Syed Sami Zia]

if i run ntpdate -u it'll update the clock... however, after 1 minute i'll already be off by 5 seconds, so i would have to run the update pretty often. i was unaware, however, of the slewing feature. all i've used is ntpdate -u which jumps.

[Paul Fisher]

As of late, many (most?) Linux kernels distributed are actually "tickless", a concept I can't explain but this thread can: kerneltrap.org/node/6750

[J-16 SDiZ]

This was true 10 years ago. According to the latest KB: "VMware recommends using NTP instead of VMware Tools periodic time synchronization.", see kb.vmware.com/selfservice/microsites/…

[J-16 SDiZ]

This was true 10 years ago. According to the latest KB: "VMware recommends using NTP instead of VMware Tools periodic time synchronization.", see kb.vmware.com/selfservice/microsites/…