Domain Time off for some members
-
I think I may have found the cause. I looked into event 4616 under the security log. I can see a consistent pattern of three records repeating over and over again. The first thing is that VMWare tools was setting the clock ahead 6 minutes. Then a little later, svchost was setting it back, and then resetting it again. Then a little later VMWare tools would set it ahead again and the pattern repeats.
-
Ah yes, competing time sources.
-
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
-
If your hardware supports it (Dell PE gear with IDRAC for instance) you could have it syncing with an NTP source as well.
-
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
Any mention of a bug in VMWare tools about this?
-
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
How do you know the VMware tools was doing the sync?. As I said in my earlier post if windows goes and tries to get the hardware clock no matter what your tool says for heartbeat or times are pretty station it’s going to get the Clock from the host.
-
@Dashrender said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
Any mention of a bug in VMWare tools about this?
Not much https://kb.vmware.com/s/article/1318?srcvmw_so_vex_pgrev_242=
-
@JaredBusch said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
How do you know the VMware tools was doing the sync?. As I said in my earlier post if windows goes and tries to get the hardware clock no matter what your tool says for heartbeat or times are pretty station it’s going to get the Clock from the host.
I didn't think Windows ever did that in a domain environment? I thought it always got it from the PDC emulator.....
-
@Dashrender said in Domain Time off for some members:
@JaredBusch said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
How do you know the VMware tools was doing the sync?. As I said in my earlier post if windows goes and tries to get the hardware clock no matter what your tool says for heartbeat or times are pretty station it’s going to get the Clock from the host.
I didn't think Windows ever did that in a domain environment? I thought it always got it from the PDC emulator.....
In a VM it does get overwritten a lot by the hypervisor Host Clock.
-
@dbeato said in Domain Time off for some members:
@Dashrender said in Domain Time off for some members:
@JaredBusch said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
How do you know the VMware tools was doing the sync?. As I said in my earlier post if windows goes and tries to get the hardware clock no matter what your tool says for heartbeat or times are pretty station it’s going to get the Clock from the host.
I didn't think Windows ever did that in a domain environment? I thought it always got it from the PDC emulator.....
In a VM it does get overwritten a lot by the hypervisor Host Clock.
Why would that be? I ask this especially in the case where the integration software has been specifically set to disable time syncing with the host.
-
@Dashrender said in Domain Time off for some members:
k this especially in the case where the integration software has been specifically set to disable time syncing with the host.
https://blogs.msdn.microsoft.com/virtual_pc_guy/2010/11/19/time-synchronization-in-hyper-v/
-
@JaredBusch said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
How do you know the VMware tools was doing the sync?. As I said in my earlier post if windows goes and tries to get the hardware clock no matter what your tool says for heartbeat or times are pretty station it’s going to get the Clock from the host.
look at the picture I posted above. It was vmtoolsd.exe that was causing it to jump forward and svchost.exe that was correcting it. I found this under event 4616
