Try to add notsc as a start parameter in /boot/grub/menu.lst if you are using grub for booting the OS.
I mentioned above that I have already applied that change. Does it matter where I place the option for notsc in the line?
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.
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:
Modified by YaST2. Last modification on Fri Aug 17 15:07:56 UTC 2007
##YaST - generic_mbr
##YaST - activate
###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE Linux Enterprise Server 10 SP1
kernel /boot/vmlinuz-18.104.22.168-0.12-smp root=/dev/sda2 resume=/dev/sda1 splash=silent showopts notsc
###Don't change this comment - YaST2 identifier: Original name: floppy###
###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- SUSE Linux Enterprise Server 10 SP1
kernel /boot/vmlinuz-22.214.171.124-0.12-smp root=/dev/sda2 showopts ide=nodma apm=off acpi=off noresume edd=off 3
1 person found this helpful
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.
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).
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.
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.
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.
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.