## 概念是什么
物理机靠专用时钟硬件计数，虚拟机的时钟要经过虚拟化层的转换与分发，中断调度受宿主机负载影响，计数会规律性地漂移，负载越重漂得越快。表现为虚拟机时间慢慢偏差，长了几秒或慢了几秒，证书校验、分布式锁、日志排序全部遭殃。
## 背后原理
内核从多个候选时钟源里选一个当前源，x86 虚拟机常见的候选是 tsc 与 kvm-clock：前者直接读 CPU 计数器，开销最小，但在虚拟机里可能因迁移与频率调整不可靠；后者是专为虚拟化设计的稳定源，由宿主机维护，读取开销略高但单调可靠。选择的依据是内核的稳定性检测，tsc 通过检测时优先用 tsc，否则退到 kvm-clock。
cat /sys/devices/system/clocksource/clocksource0/available_clocksource cat /sys/devices/system/clocksource/clocksource0/current_clocksource chronyc tracking
时钟源的漂移只解释偏差趋势，纠正要靠 NTP：chrony 持续测量偏差，小偏差用渐进调整把频率拉回来，大偏差按策略直接跳变，两者配合既保精度又保平滑。
## 最小实操
先看状态再动手：chronyc tracking 输出里 System time 偏差行给出当前快慢，Leap 与同步源状态说明是否已锁定上游。偏差长期存在的机器检查时钟源与上游配置，sources 加 v 参数看每个上游的 reachable 与偏差测量。顺云云服务器默认已配置时间同步，确认 chrony 在跑、上游可达即可，无需手工硬调时间。
## 常见错误
用 date 手工设时看似立竿见影，随后又被同步服务拉回，反复拉锯。让虚拟机休眠或快照回滚后不检查时间，回滚机器的时间停在快照时刻，证书类业务立刻报错，恢复后先确认时间已重新锁定再放回业务。
容器环境的时间还有一层细节：容器默认共享宿主内核时钟，宿主漂移容器跟着漂，容器内改时间没有意义，时间敏感的服务要同时盯宿主与容器的偏差。日志时间戳的时区也常添乱：多机协作排查时先统一时区，或至少在日志里带上时区标记，跨时区团队更要把这一条写进规范，时间对齐是所有协同排查的第一步。证书与令牌类故障的排查清单里，把时间核对放在第一项，能少走大量弯路。