运行在青云私有云上的 Ubuntu 22.04 虚拟机，通过 systemd-timesyncd 采用 ntp.ubuntu.com 服务器进行 NTP 同步。在 /var/log/syslog 中每隔大约半小时就会产生两条来自 systemd-resolved 的日志提示系统时间更改。
一台虚拟机 xxx 时间突然向过去跳变，再恢复正常：
May 31 17:18:44 xxx systemd-resolved[724]: Clock change detected. Flushing caches.
May 31 17:18:51 xxx systemd-resolved[724]: Clock change detected. Flushing caches.
May 31 17:48:48 xxx systemd-resolved[724]: Clock change detected. Flushing caches.
May 31 17:48:54 xxx systemd-resolved[724]: Clock change detected. Flushing caches.
另一台虚拟机时间 yyy 突然向将来跳变，再恢复正常：
May 31 17:53:58 yyy systemd-resolved[690]: Clock change detected. Flushing caches.
May 31 17:52:22 yyy systemd-resolved[690]: Clock change detected. Flushing caches.
May 31 18:24:03 yyy systemd-resolved[690]: Clock change detected. Flushing caches.
May 31 18:22:27 yyy systemd-resolved[690]: Clock change detected. Flushing caches.
在服务器上通过 top （间隔设为 0.1 秒）现场观测观察到的时间跳变现象与日志中的记录相符。
虚拟机上 /sys/devices/syste/clocksource/clocksource0/current_clocksource 为 kvm-clock 。
以上现象是什么原因造成的？是否说明虚拟机所在主机的时间不准，或者主机上的时间同步与虚拟机存在冲突？有没有什么办法可以缓解或解决时间上的跳变？
如果禁用虚拟机 xxx 上的 systemd-timesyncd 服务，日志中发生时间变化的间隔变长（ 1.5 小时或 2 小时），且每次只有一行，不再出现跳变。但是这会导致系统时间始终比北京时间慢 6~7 秒（可能刚好与启用时间同步时跳变的时间差相等？）。
6 条回复 • 2025-06-01 19:39:16 +08:00
 |
1
lcdtyph 5 天前 via iPhone
加个内核参数换 clocksource
clocksource=tsc 具体换成什么可以看看 available_clocksource |
 |
2
druggo 5 天前
关掉 systemd-timesyncd ，换 ntpd 试试
|
 |
3
billlee 5 天前
嗯，看 clocksource. 另外如果你依赖时间的单调性，就不要用 systemd-timesyncd, 用 chrony.
|
 |
4
fangjue OP @billlee 还有一台虚拟机上用的 chrony ，但日志中总是时不时出现 chronyd: Can't synchronise: no majority ，尝试过配置多种不同的 NTP 服务器。日志中的时间变动也是半小时一次，只出现一条，系统时间比较准。
之前查阅过各种文档，clocksource 一般都推荐使用 kvm-clock ； tsc 性能有一些优势，但虚拟机在不同物理 CPU 之间迁移可能会出现偏差。 |
|
5
fangjue OP 虚拟机 yyy 使用 chrony 同步后，每隔半小时时间突然向将来跳变 90 多秒（比标准时间快 90 多秒），接下来一段时间由 chrony 逐步拨回正常时间，整个过程持续 22 分钟。相比 systemd-timesyncd 时间保持单调，但是相当长的一段时间内系统时间偏差大。
还有一台虚拟机 zzz 禁用了 systemd-timesyncd 也未使用 ntpd 或 chrony 等其他同步服务，自上次物理机停机维护至今时间差大致以线性规律逐渐增长，现在比标准时间慢 80 多秒。虚拟机 yyy 的时间差也是这样的线性增长规律。 看起来像是 kvm-clock 的计算上存在偏差，不同虚拟机的偏差还不一样，并且随着运行时间增长逐渐累加？ |
|
6
fangjue OP clocksource 更换为 tsc 没有任何变化。想到用 auditd 检测是什么进程修改了系统时间，结果发现是这么一个进程：
date -u --set=2025-06-01 xx:xx:xx.xxxxxx 进一步记录所有运行的进程后发现，上述命令来自 gapd （ QingCloud Guest Agent ），看来只能找厂商解决了。 |
Select Language