时间服务检测到900秒的时间差大于5000毫秒.时间差可能是由与低精度时间源的同步或次优的网络条件引起的.时间服务不再同步,无法为其他客户端提供时间或更新系统时钟.当从时间服务提供商收到有效时间戳时,时间服务将自行纠正.
如果有人与虚拟化DC具有类似的设置,并且已经在域中的所有服务器上实现了高度准确的时间同步,那么您的输入将会受到赞赏.
谢谢.
解决方法
这是对问题的伪解释(自从我看到这个以来已经很长时间了)：
当机器(工作站,服务器,VM)启动时,它会从RTC(主板/ BIOS上的电池供电的时钟芯片)读取时间,并计算每个cpu滴答的持续时间.然后,OS计算自初始读取以来发生的时钟滴答数,并将该时间与读取时的原始时间读数相加.这给你当前时间.
问题是,主机模糊了VM发生的真实时钟周期.当主机上实际发生500个时钟周期时,VM可能已经看到100个时钟周期.因此,这种计算时间的方法会中断,并且时间会从VM上消失.
通过vSphere和Hyper-V上安装的虚拟机工具/增强功能包进行主机 – 访客时间同步可以解决这个问题,但它们并不完美(在某些设置中,如果虚拟机实时漂移,它们可以将虚拟机向前拉,但是如果它在实时之前漂移,则不要跳转VM.)
进一步复杂的是时钟周期计入多核设置(定时计数器基本上模拟在每个内核上)以及可以动态改变时钟速度的设置(我不知道如何维护它).考虑到VM可以在一个内核上执行一个时钟周期,然后在下一个周期跳转到不同cpu上的不同内核,这真的太可怕了.
回到原点：默认情况下,域时间从PDC开始,然后逐渐下降到其他DC,然后从那里流向成员服务器和工作站.因此,如果您确保PDC是真正可靠的时间源(通过保持物理),并禁用所有其他域成员上的主机 – 客户同步,您将确保稳定且相对准确的时间基础架构.
请注意,将PDC作为物理服务器运行然后在该服务器上启用Hyper-V并向其添加一些guest虚拟机也可能不合适,因为我相信当您启用Hyper-V时,“基本”操作系统实际上变为虚拟化操作系统(静默).因此,将一台物理服务器保留为PDC,并保持Hyper-V不受限制.
有趣的一点需要注意：微软对Windows时间同步的官方立场,即使使用自XP / 2003以来内置于Windows中的兼容NTP服务,也是15秒.在实践中,你可以将它降低到100毫秒以下,但他们所支持的只是在15秒内同步. Kinda有道理,大多数MS环境核心唯一对时间敏感的关键组件是Kerberos,默认情况下,只要你在5分钟的容差范围内,它就会愉快地运行.
