我有一个在 HyperV 下运行的 CentOS VM（6.2 版）。我已经安装了集成服务（现在是 base 的一部分），CentOS 显示当前时钟源是 hyperv_clocksource，但是在正常运行一周后，我在 VM 中的时间快了大约 10 分钟。我对新 IC 和可插拔时钟源的理解是，这种情况不应再发生。是否需要任何额外的配置才能使可插入时钟源“工作”？
我知道有很多关于将内核选项设置为 PIT 和类似内容的链接，但这些链接似乎都早于集成时钟源支持，据我所知，不再需要它了。ntpd 或 adjtimex 也不应该。
编辑：正在运行 3.2 的 IC（附带 Centos 6.2），今天升级到 3.3，机器已经运行了 1 小时 22 分，时钟已经快了 5 秒。所以我现在正在运行最新的 IC 并且仍然有同样的问题。
我只是偶然地注意到，我的一台 Cisco 4500 交换机的时钟出错了：尽管 ntp 看似正常，但它还是落后了 2 分钟以上。在我看来，对于所涉及的系统来说，即使是一秒钟也不应该被认为是可以接受的。此外，如果我没有将它与简单的挂钟进行比较，我就不会注意到与诊断的区别。
这是我的一些主机（10.0.99.1、10.0.99.2、10.0.1.119、10.0.99.241）的 ntp 信息，它们部分地相互引用以进行后备，但主要最终都应该通过与 10.0.0.1 同步，这再次拉动时间从外面。所以时间差异不可能是由不同的原始时间源造成的。由于观察结果使我有些偏执，因此“具有正确的时间”的方式如下show clock：（或date）产生与我的挂钟和本地系统时钟（根据http://time.is很好）匹配的输出肯定低于 1 秒的错误（我在观看本地时钟时按 ENTER 的准确性）
$ ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
+10.0.99.1 10.0.0.1 3 u 855 1024 377 0.904 -2.658 0.113
*10.0.0.1 130.149.17.8 2 u 266 1024 377 0.253 0.909 0.127
#sho ntp associations
address ref clock st when poll reach delay offset …已解决 问题是那台机器上的 Hyper-V。我删除了 Hyper-V，安装了 VMware Server，运行了相同的 VM。时间同步问题消失了（一天后相差 < 100 毫秒）。
我的设置是这样的：
HYV1 - HyperV machine (non domain) - sync irrelevant
AD1 - VM AD server on HYV1, sync'd to time.nist.gov. HyperV time sync off.
S1 - Physical machine, sync'd to domain.
S2 - Physical machine running HyperV, sync'd to domain.
V1 - Linux VM machine on S2, sync'd to AD1. No HyperV integration.
AD1 和 S1 具有良好的同步性——条形图显示的差异小于 100 毫秒。
S2像疯了一样漂移。这是 AD1 的一些带状图：
18:33:22 d:+00.0010138s o:+05.4101899s
18:33:24 d:+00.0010138s o:+05.4319765s
18:33:26 d:+00.0000000s …windows windows-server-2008 hyper-v ntp time-synchronization
在域中，我想将 DC 设置为时间服务器。
为此，我使用以下命令：
w32tm /config /manualpeerlist:europe.pool.ntp.org /syncfromflags:manual /reliable:yes /update
和
w32tm /resync /rediscover
在我使用的客户端服务器中
net time \\<comp.name.of.ad> /set /y
但一些客户端仍然使用本地 CMS 时钟。
我能做什么？
提前致谢。
编辑：
我也跑
w32tm /resync [/computer:<computer>] [/nowait] [/rediscover]
在客户端，但时间服务器仍然是客户端的本地 CMOS 时钟。
AD源是我设置的。(nist.expertssmi.com)
在客户端，源是本地 CMOS 时钟
active-directory ntp w32time time-synchronization windows-server-2008-r2
您能想到哪些问题可能由错误的系统时钟设置引起？
主要对影响服务器和 Linux 或类 UNIX 系统的潜在问题特别感兴趣。
这些后果有多严重，取决于系统时间关闭了多少？例如，5 分钟、30 分钟、1 小时、1 天。
我的 ubuntu 11.10 服务器在过去的 3 - 4 个月里一直很高兴地坐在那里，然后突然时间开始不同步一小时。我不知道为什么，服务器的配置没有任何改变，我读到它可能归结为系统资源使用情况。
无论如何，为了抵消这一点，我看到很多人建议安装 NTP 和 NTP 守护进程 (ntpd)，以便自动同步时间。我已经安装了 NTPD，它似乎可以工作一天，然后突然停止工作。
在我做的大约一天之后
ntpq -q
列出连接的对等点，我收到错误
ntpq: read: Connection refused
如果我然后尝试重新启动服务
sudo service ntp restart
我收到以下消息
* Stopping NTP server ntpd
start-stop-daemon: warning: failed to kill 26915: No such process
* Starting NTP server ntpd
一旦我在大约 5 分钟内完成此操作，时间就会再次同步。如果我再次重新启动服务，我不会收到上述消息，我只是收到
* Stopping NTP server ntpd
* Starting NTP server ntpd
如果我再次尝试 ntpq -p 我得到
remote refid st t when poll reach delay offset jitter
==============================================================================
noc.be.it2go.eu 193.190.230.66 2 u …我在某些（硬件）服务器中看到了一种奇怪的系统时间更改行为：在 /var/logs/syslog 中，每条日志消息之前的日期时间有时会更改为随机时间并在下一条消息中恢复正常，如下所示：
2018 年 2 月 22 日 09:09:30 ... 2018 年 2 月 22 日 09:09:32 ... 2610 年 1 月 13 日 15:37:42 ... 2018 年 2 月 22 日 09:09:33 ... 2018 年 2 月 22 日 09:09:34 ...
如示例中所示，日期时间的突然变化可能长达数百年。
我可以确认具有奇怪时间戳的日志消息不是来自任何特定进程 - 它可能对每个进程随机发生。
并且两次异常时间更改之间的持续时间从几分钟到几小时不等（但是，我怀疑异常时间更改可能会更频繁地发生，但其中许多未在系统日志中显示，因为它不是每秒写入日志）。
此外，由于它发生在不止一台服务器上，我认为这不是硬件问题。
关于服务器的更多信息：它们是一个带有一个控制器和几个计算节点的 openstack 安装。每个服务器都有运行的 ntp 服务。控制器配置为从其自己的硬件时钟中获取时间，并且计算节点服务器从控制器同步时间。请注意，每个服务器都有自己的异常时间变化 - 看起来“错误的时间”不是从控制器通过 ntp 同步的。
我怀疑计算节点上的来宾系统（虚拟机）可能会影响它们的主机系统时间。但这并不能解释为什么控制器在没有运行任何虚拟机的情况下会出现同样的问题。
我需要一种方法来检测：谁更改了系统时间以及它是如何发生的？
我有一个本地网络，微控制器 ARM 作为 NTP 服务器，我有一台运行 ubuntu 16.04 LTS 作为 NTP 客户端的台式计算机。
一旦我从ntpd -g -c /etc/ntp.conf以下 ntp 配置文件开始
server 192.168.0.11 minpoll 4 maxpoll 4
ntpd 设置时间后的第一个偏移显示了非常好的结果，即低于 1ms。我通过ntpq -p.
然而，偏移量在大约 55ms 后缓慢上升。1000 秒。对于我的应用程序来说，这种高偏移是不可接受的。但是在偏移量达到 55 ms 后，ntpd似乎再次设置时间并且偏移量变得足够小且稳定（< 1ms）。似乎ntpd让时钟漂移了一段时间，在（太）长的时间之后，守护进程对 NTP 客户端和 NTP 服务器之间的时钟漂移采取对策。
使用ntpd -g -c /etc/ntp.conf -f /etc/ntp.driftwherentp.drift由 生成ntpd，偏移量将始终保持在 1ms 以下，即没有时钟漂移引起的偏移量线性上升；期望的行为。
现在我的问题：在我的应用程序中，我们不能让ntpd运行一段时间来计算很长一段时间后的时钟漂移，同步必须在启动 NTP 客户端后几秒钟后进行，并且偏移量必须保持不变稳定的。
如何ntpd在不确切知道时钟漂移的情况下获得稳定且小的偏移量？
鉴于 Windows Server 2003 域服务器，我想将时间同步到（任何）外部时间服务（关闭几分钟）。如何做到这一点 1、手动；2、每周自动执行一次？
我已经尝试了几个关于如何在 ubuntu 上设置本地 ntp 服务器的指南，但似乎没有一个可以正常工作。由于某种原因，我的服务器在时间上严重漂移，我必须将它们的时间保持在一起，因为我运行的数据库需要这样做。
目前，我的服务器（ip .24）运行这个 /etc/ntp.conf：
server 127.127.1.0 prefer
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
# Give localhost full access rights
restrict 127.0.0.1
# Give machines on our network access to query us
restrict 192.168.178.0 mask 255.255.255.0 nomodify notrap
broadcast 192.168.178.0
而在“客户”上：
# Point to our network's master time server
server 192.168.178.24 iburst
fudge 192.168.178.24 stratum 10
restrict default ignore
restrict ::1
restrict 127.0.0.1 …