Stop your KVM guests from drifting into virtual time travel

Technical Briefing | 10/10/2026

You spend your time tuning CPU pinning and IO schedulers, but your biggest headache is often invisible. If your guests are reporting weird clock jitter or log entries that don’t match reality, you are dealing with clock synchronization issues. It bit me hard on a database cluster once, where heartbeat packets were arriving seemingly from the future, causing the whole stack to fence itself to death.

The tick rate problem

Guest OS kernels try to manage their own time, but KVM provides multiple clock sources. Most defaults are safe, but high-load workloads can cause the guest’s clock to drift significantly if the hypervisor can’t keep up with interrupt delivery. You really want to use KVM-clock for paravirtualized time, as it is designed specifically for this handshake.

virsh edit vm-name
<clock offset='utc'>
<clock name='kvmclock' present='yes'/>
</clock>

• Check that your guest is actually using kvm-clock by checking dmesg or clocksource sysfs files
• Avoid using hyper-v clocks unless you are explicitly running Windows guests on Linux
• Make sure the host NTP daemon is rock solid because the guest will only ever be as accurate as the metal underneath it

Keeping NTP out of the ring

A common mistake is running an aggressive NTP daemon inside the guest fighting against the hypervisor. If KVM-clock is exposed, the kernel handles the interpolation; don’t let chrony or ntpd battle it out by stepping the clock unnecessarily. You want the guest to treat the hypervisor as its hardware clock source.

Next time a developer complains about timestamps in your logs, don’t just add a log buffer. Check your clocksource configuration first. It is an easy win that fixes a class of bugs nobody likes to debug.