/var/log/step2k

If your Linux 2.6 guest’s clock is running too quickly, it indicates a problem with lost tick correction. Apply one of the workarounds in the section “Preventing the Clock from Running Too Quickly.”

Note: The overcorrection for lost ticks has been fixed in Linux kernel 2.6.18. Upgrading to 2.6.18 or later also solves this problem.

If your guest’s clock is running too slowly, it indicates that the host’s real timer interrupt rate can’t keep up with the guest’s virtual timer interrupt rate. There are two approaches to dealing with the problem: either decrease the guest’s rate or increase the host’s rate. Apply one of the workarounds in the section “Preventing the Clock from Running Too Slowly.” Also apply one of the workarounds for running too quickly, because correcting the first problem often reveals the second one.

In both cases, also make sure that VMware Tools is installed in your guest, that time synchronization is enabled and that you are not running any other clock synchronization software in the guest at the same time (such as ntpd).
If your host uses power management features (such as Intel SpeedStep, or AMD PowerNow or Cool’n'Quiet) that vary the processor speed, see http://kb.vmware.com/kb/1591.
Preventing the Clock from Running Too Quickly
32-bit Systems
For 32-bit systems, there are two kernel options that help with the guest kernel’s over-correction for lost ticks:

* Add the clock=pit boot option to your guest’s kernel command line in the /etc/lilo.conf or /boot/grub/grub.conf file.

The following example shows the syntax for LILO:
image=/boot/vmlinuz
label=”linux”
root=/dev/hda1
initrd=/boot/initrd.img
append=”resume=/dev/hda6 splash=silent clock=pit”
read-only

(Remember to run /sbin/lilo after editing lilo.conf, so that your edits take effect.)

Here is an example of the syntax for GRUB:
title Fedora Core (2.6.9-1.667)
root (hd0,0)
kernel /vmlinuz-2.6.9-1.667 ro root=/dev/hda2 clock=pit
(more…)