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.

Answer 1

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

Answer 2

You can use the cmd and

net time \\computer_name /set

to set the clock remotly (or in a script for example)

Answer 3

Supposedly updating regularly via ntp is not a good solution

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

Answer 4

Install NTP if you don't already have it.

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

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

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

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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" drift's away by X number of seconds in a day, then instead of jumping ahead/forward like a forced command as in "ntpdate " NTPD tries to add/remove some cicles to the clock so that in time, normally within 15 minutes, the clock runs accuratly enough and the compensation overcomes this X numbers of seconds that the servers gains/losses in a day. This has te advantage that you wont see any time in the day repeated, wich is a MUST for for transacctional sistems.

But to be able to do this, NTPD requires that the local clock does a reasonable good joob, wich normally means that the local clock wont drift appart 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 syncronize the CLIENT clock with the HOST's clock (normally refered as the "wall clock")