Keeping Your VMware Linux Guest’s Clock Accurate
As the price of rack space goes up and fast hardware goes down more and more companies are moving towards virtual servers. VMware is a popular choice, especially with their free VMware Server application. Due to the hardware being virtualized one of the main issues is keeping the time clock accurate. After spending some time using VMware Server I found that my linux guest’s clock would be off by 5 sometimes 10 minutes.
Depending on the distro you’ll want to edit either your lilo or grub config. Append “clock=pit nosmp noapic nolapic” without the quotes to the kernel line. The end result show look similar to below.
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Fedora Core (2.6.17-1.2187_FC5) root (hd0,0) kernel /vmlinuz-2.6.17-1.2187_FC5 ro root=/dev/VolGroup00/LogVol00 clock=pit nosmp noapic nolapic initrd /initrd-2.6.17-1.2187_FC5.img |
The “clock=pit” prevents the clock from running too quickly and “nosmp noapic nolapic” prevents the clock from running too slowly. Remember you must reboot your machine for this change to take effect.
If you haven’t already you’ll want to install VMware Tools. Consult the help documentation in VMware for the correct steps for your distribution. Most likely your not running a window manager on the virtual machine, but if you are open up the vmware-toolbox and check sync time with host. Otherwise you will have to stop the virtual machine and edite the vmx file by hand.
tools.syncTime = "TRUE" |
If your running an 64-bit guest you clock might still be out of sync. However there is a solution. Install the ntp package. The following instructions were based off Fedora Core 5 but with slight modifications should work for any distribution.
yum install ntp |
Make sure cpuspeed is disabled as this can play havoc with timekeeping.
chkconfig --level 12345 cpuspeed off |
Since the vmware’s guest timeclock is not reliable we have to disable ntp from using it as a backup. If you do not do this ntp will not function. Comment out the below lines in /etc/ntp.conf
#server 127.127.1.0 # local clock #fudge 127.127.1.0 stratum 10 |
Before starting the ntp service we need to get the system clock within 1 second of the ntp time source. Run ntpdate a few times until the offset settles.
ntpdate pool.ntp.org |
Start ntpd and configure it to run at system startup.
service ntpd start chkconfig ntpd on |
Wait 10-15 min and check the server reach which should be 377.
ntpq -p |
Also check the stratum this should be 5 or below.
ntpq -c rv | grep stratum |
Thanks very much for sharing this. I had been pulling my hair out in solving this problem on a Ubuntu 7.10 server running VMWare 1.0.4 on an AMD64 server. All appliance clocks were off: with 2 active processors the appliance clock advanced 6 seconds in every 60 seconds (10 times slow), on 1 processor it advanced 32 seconds in a minute (twice as slow). Problems with apache log based statistics using AWstats, etc.
For me, the advice to add the kernel startup parameters “nosmp noapic nolapic” did the trick. After rebooting and an initial clock synchronization the clocks on all appliances now run more or less equal to the base server; too short a time to be certain of the effects in the long run. On 2 appliances I added ntp server to synchronize with the base server, which in turn synchronizes with time servers on the internet, to see if there is a gain in that strategy.
At least on my “server farm” all clocks are now in sync.
Thanks again,
Erik.
As Erik, I was also pulling my hair out and I’m kind of bald, so you can picture the rest… hehe…
I have a Fedora Core 4 (2.6.11-1.1369_FC4smp) on a VMWare 1.0.3 and I’ve been suffering from the same problem…
I added “nosmp noapic nolapic” to the grub parameters file and now it’s working fine… I cannot believe it, this thing was driving me crazy.
Many thanks!!
German.
“nosmp noapic nolapic” prevents the clock from running too slowly.
Yeah and ends all power management on the PC, its not JUST for clock issues. Its for PCI issues too but you should warn people the consequences of turning off apic
VMware recommends to add those kernel arguments as well in their knowledge base. Power management isn’t the same in a virtual enviroment.
Power management is ACPI not APIC….
With kernel 2.6+ I experienced only time gains. I found out it is enough to only add clock=pit.