11 Replies Latest reply on Jan 15, 2008 4:31 AM by jarrufat

    Guest clock SuSe 10 too fast

    dcahill Novice

       

      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?

        • 1. Re: Guest clock SuSe 10 too fast
          markus_herbert@yahoo.de Hot Shot

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

          • 2. Re: Guest clock SuSe 10 too fast
            dcahill Novice

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

            • 3. Re: Guest clock SuSe 10 too fast
              markus_herbert@yahoo.de Hot Shot

              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.

              • 4. Re: Guest clock SuSe 10 too fast
                dcahill Novice

                 

                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

                 

                 

                 

                 

                 

                 

                • 5. Re: Guest clock SuSe 10 too fast
                  markus_herbert@yahoo.de Hot Shot

                  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.

                  1 person found this helpful
                  • 6. Re: Guest clock SuSe 10 too fast
                    dcahill Novice

                    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).

                    • 7. Re: Guest clock SuSe 10 too fast
                      AWo Guru

                      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

                      • 8. Re: Guest clock SuSe 10 too fast
                        dcahill Novice

                        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.

                        • 9. Re: Guest clock SuSe 10 too fast
                          AWo Guru

                          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

                          1 person found this helpful
                          • 10. Re: Guest clock SuSe 10 too fast
                            dcahill Novice

                             

                            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.

                             

                             

                             

                            • 11. Re: Guest clock SuSe 10 too fast
                              jarrufat Lurker

                               

                              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.