2 Replies Latest reply on Sep 1, 2011 12:37 AM by jmedd

    vCenter Time Sync Issues

    jmedd Enthusiast

      vCenter 4.1 U1.


      Since migrating from a physical to a virtual vCenter earlier this year, three times we have experienced the below issue where all hosts in vCenter disconnect then instantly re-connect. This always coincides with an event in the vCenter System Log showing a time syncronisation correction, always with around a 1 minute shift.





      vCenter does not use VMware Tools to get its time, rather it is an AD domain member so gets it's time from the Domain Controllers. These DCs and the ESXi hosts use the same internal time source, so I don't think the issue lies there. The Domain Controllers are also not showing that they are having issues with the internal time source or even that they have needed to adjust their own time.


      One element that I think may not be helping is that vCenter is scaled with 4 vCPUs based on the recommendation for 50 - 200 hosts. However, looking at typical CPU use of the vCenter VM it is very low, typically averaging 5% usage. So I am wondering if this idle CPU time is causing vCenter's time to drift more than it should?


      Anyone else have experience of this or can suggest what could be done to help prevent the issue?

        • 1. Re: vCenter Time Sync Issues
          Chris Wahl Master

          Any drift noticed on vCenter when you run w32tm /stripchart /computer:<NTP server>?


          Perhaps ensure that the domhier server that vCenter is using for NTP sync is the same as the ESXi servers and analyze to see if the NTP daemons are running automatically on the hosts.

          VCDX #104 (DCV, NV) ஃ WahlNetwork.com ஃ @ChrisWahl ஃ Author, Networking for VMware Administrators
          1 person found this helpful
          • 2. Re: vCenter Time Sync Issues
            jmedd Enthusiast

            Thanks for the reply. I think we have finally resolved it.


            The PDC emulator is using the same NTP server as the ESXi hosts and there appear to be no issues there.


            In the end I went with my theory that vCenter was configured with too many vCPUs, reduced it to 2 x vCPUs to reduce the likelyhood of CPU inactivity timing issues and since then we have not experienced the initial problem.