VMware Cloud Community
dcahill
Contributor
Contributor

Guest clock SuSe 10 too fast

I'm having some troubles getting the clock working correctly on a SuSe 10 64-bit guest host running on a ESX 3 environment. I've configured all my ESX 3 servers with NTP and their clock is tracking time perfectly. I've installed the vmware tools on SuSe 10 and confirmed the "guestd" process is running. I've altered the /boot/grub/menu.lst to add the option for "notsc" as suggested by the documentation I've read online and rebooted. The amount of time the clock drifts forward has slowed from about a half a day ahead to only a couple minutes, but it's still too fast.

title SUSE Linux Enterprise Server 10 SP1

root (hd0,1)

kernel /boot/vmlinuz-2.6.16.46-0.12-smp root=/dev/sda2 resume=/dev/sda1 splash=silent showopts notsc

initrd /boot/initrd-2.6.16.46-0.12-smp

I also confirmed that inside my vmx file that the line 'tools.syncTime = "TRUE"' is in there. Is there anything else I can try to keep the clock working correctly?

Tags (3)
Reply
0 Kudos
11 Replies
markus_herbert
Enthusiast
Enthusiast

Try to add notsc as a start parameter in /boot/grub/menu.lst if you are using grub for booting the OS.

Reply
0 Kudos
dcahill
Contributor
Contributor

I mentioned above that I have already applied that change. Does it matter where I place the option for notsc in the line?

Reply
0 Kudos
markus_herbert
Enthusiast
Enthusiast

Use that line, which will start your SuSE Linux System; e.g if DEFAULT=0 than use the first statement.

Also disable ntpd, because that gives you problem with the timesync of vmware-tools.

Reply
0 Kudos
dcahill
Contributor
Contributor

I verified that NTP is not running on the guest OS. It is only running on the actual ESX server so that the tools can synch with it. Other than this I'm out of ideas to try to make the clock work correctly. This guest host is using 4 vCPU's in case that matters.

Here is the contents of my grub:

  1. Modified by YaST2. Last modification on Fri Aug 17 15:07:56 UTC 2007

default 0

timeout 8

##YaST - generic_mbr

gfxmenu (hd0,1)/boot/message

##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###

title SUSE Linux Enterprise Server 10 SP1

root (hd0,1)

kernel /boot/vmlinuz-2.6.16.46-0.12-smp root=/dev/sda2 resume=/dev/sda1 splash=silent showopts notsc

initrd /boot/initrd-2.6.16.46-0.12-smp

###Don't change this comment - YaST2 identifier: Original name: floppy###

title Floppy

rootnoverify (hd0,0)

chainloader (fd0)+1

###Don't change this comment - YaST2 identifier: Original name: failsafe###

title Failsafe -- SUSE Linux Enterprise Server 10 SP1

root (hd0,1)

kernel /boot/vmlinuz-2.6.16.46-0.12-smp root=/dev/sda2 showopts ide=nodma apm=off acpi=off noresume edd=off 3

initrd /boot/initrd-2.6.16.46-0.12-smp

Reply
0 Kudos
markus_herbert
Enthusiast
Enthusiast

Novell wrote in there documentation:

Use the "clock=pit" kernel parameter for 32bit or "clock=notsc" for 64bit machines. You add the parameter to /boot/grub/menu.lst or the Boot Options line at the grub prompt when the system boots.

So try to use clock=notsc instead of only notsc. The line you wrote it is ok.

Hope this will help you.

dcahill
Contributor
Contributor

I tried making the change from "notsc" to "clock=notsc" as you suggested and there was no difference in tracking time. This host sat idle from mid day yesterday until this morning and the clock is 5 minutes fast as of this morning. I'm out of ideas on how to make a clock track time correctly in vmware. Is there anything else I can try to get this working? I also confirmed the ESX server hosting this vmware has an accurate date/time and the guest has the guestd service running (though the vmware tools supposedly do nothing for fixing a fast clock).

Reply
0 Kudos
AWo
Immortal
Immortal

If not already done read this for background information and some hints to get this fixed:

http://www.vmware.com/pdf/vmware_timekeeping.pdf

Pages 11-ff

Pages 22-ff

AWo

vExpert 2009/10/11 [:o]===[o:] [: ]o=o[ :] = Save forests! rent firewood! =
Reply
0 Kudos
dcahill
Contributor
Contributor

Thanks AWo. I've seen that doc in the past and I've read about the different options to try. The problem it seems is those tips are geared for 32-bit OS's (clock=pit is for 32 bit from what I've read). My guest VM is also using multiple CPU's which increases the number of interrupts. Other suggestions I've read said to recompile the kernel to revert back to 100Hz vs 1000Hz in the 2.6 kernel. I've never done that nor have I seen adequate documentation to figure out what needs to be done to make that change.

Reply
0 Kudos
AWo
Immortal
Immortal

Do you reference KB article 1420? There are hints for 64 bit,as well. There's a description what to change and were to change it to set it to 100 Hz before re-compiling the kernel. As you're using SuSE rely on the SuSE internal help, which describes the kernel compilation quite well. Install the kernel-source package beforehand. Clone (copy) your guest and test the procedure with the clone first.

Do you already have a 2.6.18 kernel? Timing issues should be fixed with this one.

AWo

vExpert 2009/10/11 [:o]===[o:] [: ]o=o[ :] = Save forests! rent firewood! =
dcahill
Contributor
Contributor

Yes, the changes I've tried have come from KB 1420. That's where I read about the "notsc" option among the other interrupt values.

I'm not at the 2.6.18 kernel (I'm at 2.6.16), so I will try upgrading that first to see if it solves my issue before I move on to the interrupt frequency. Thanks for the suggestions.

Reply
0 Kudos
jarrufat
Contributor
Contributor

Hi dcahill, I was in a very similar situation, with sles 10 64bits 4 vCPU and after try different options i booted the guest with the kernel parameters clock=pit and notsc. Surprisingly the guest is running on time since yesterday.

Could you test this option?

How about the kernel upgrade? this was a solution that i discarded because Suse only supports up to 2.6.16.

Reply
0 Kudos