Domain Time off for some members
-
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
