[ACCEPTED]-How can I resolve the drifting clock for my Virtual Machine?-drift

1. Read you vmware documentation carefully before you listen to anyone. We are running ESX5.

Timekeeping best practices for Linux guests 24 among other things says: Ref: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427

NTP Recommendations Note: VMware 23 recommends you to use NTP instead of VMware 22 Tools periodic time synchronization. NTP 21 is an industry standard and ensures accurate 20 time keeping in your guest. You may have 19 to open the firewall (UDP 123) to allow 18 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 17 is a sample (RedHat specific) /etc/ntp/step-tickers:

0.vmware.pool.ntp.org
1.vmware.pool.ntp.org

The 16 configuration directive tinker panic 0 instructs 15 NTP not to give up if it sees a large jump 14 in time. This is important for coping with 13 large time drifts and also resuming virtual 12 machines from their suspended state.

Note: The 11 directive tinker panic 0 must be at the 10 top of the ntp.conf file.

It is also important 9 not to use the local clock as a time source, often 8 referred to as the Undisciplined Local Clock. NTP 7 has a tendency to fall back to this in preference 6 to the remote servers when there is a large 5 amount of time drift.

An example of such 4 a configuration is:

server 127.127.1.0
fudge 127.127.1.0 stratum 10

Comment out both lines.

After 3 making changes to NTP configuration, the 2 NTP daemon must be restarted. Refer to your 1 operating system vendor’s documentation.

vmware have a really good PDF doc on this problem.

Basically, the 12 host will slew the ticks delivered to your 11 guests as it can. Don't run NTP or timed or 10 junk like that. Just install vmware-guestd 9 and let the host slew your ticks. If you 8 still lose ticks, then any other solution 7 will have major drift too.

If you can, use 6 a guest OS that has a low frequency tick 5 rate. Newer versions of Linux come with 4 1000Hz ticks, but it used only to be 100Hz. That 3 seems easier for the host to deliver. A 2 kernel rebuild is usually needed to change 1 the HZ value.

Just to add some data about why NTPD is 32 not a good solution. NTPD is a daemon that 31 tries to compensate for the local clock 30 drift; if the "internal clock" drifts away 29 by X number of seconds in a day, then instead 28 of jumping ahead/back like a forced command 27 as in "ntpdate " NTPD tries to add/remove 26 some cycles to the clock so that in time, normally 25 within 15 minutes, the clock runs accurately 24 enough and the compensation overcomes this 23 X numbers of seconds that the servers gains/losses 22 in a day. This has the advantage that you 21 won't see any time in the day repeated, which 20 is a MUST for for transactional systems.

But 19 to be able to do this, NTPD requires that 18 the local clock does a reasonably good job, which 17 normally means that the local clock won't 16 drift apart more than 42 seconds a day (more 15 or less; I am not sure of the exact number). This 14 normally is a problem in Virtual Machines, since 13 the the clock is software controlled, so 12 if the HOST has too much overload, you could 11 see that the CLIENT's clock will run more 10 slowly, and if it doesn't then the clock 9 could run too fast. The problem here for 8 NTPD is that the local clock is not reliable 7 and doesn't have a constant drift in time; it 6 may be more or less depending on the overload 5 of the HOST system.

So in this case it's 4 better to install the client tools as has 3 been suggested, and synchronize the CLIENT 2 clock with the HOST's clock (normally referred 1 as the "wall clock")

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

Read 3 vmware_timekeeping.pdf for thorough understanding of the issue.

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

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

Doesn't installing the virtual machine additions 2 (tools) synchronize the clock between the 1 guest and host OS?

Supposedly updating regularly via ntp is 3 not a good solution

That's the solution I 2 would recommend, though. Why is it not 1 considered good at your location?

Install NTP if you don't already have it.

ntpdate 11 will set the clock correctly, then ntpd 10 can keep the clock accurate.

The NTP pool project provides 9 a large pool of NTP servers to pick from.

Edit just 8 noticed you said you think NTP is not a 7 good solution - why? If you're worried 6 about the effect of the clock changing, NTP 5 is the ideal, as ntpd does not jump the 4 clock forwards or backwards, instead it 3 "slews" the clock by speeding 2 it up/down slightly until it's back in line 1 with the correct time.

I had the same problem and solved it by

1. installing vmware-guestd
2. sending the kernel an option clocksource=acpi_pm
3. running hwclock -s hourly as root.

0

This is an old issue but one that was affecting 10 us recently. What I found was that any of 9 our vm's that were running vmware tools 8 were affected by the issue.

More recently 7 we had started using open-vm-tools and on 6 those vm's the option was not set. Since 5 open-vm-tools is fully supported and recommended 4 by Vmware I would suggest using it over 3 vmware tools: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2073803

If open-vm-tools is in a repository 2 that you use it is also simple to install 1 via yum install or apt-get install etc.