Stop your VM’s clock from drifting into another dimension

Technical Briefing | 11/1/2026

You spend weeks tuning your guest OS, optimizing kernel parameters and network buffers, only to realize your database logs have timestamps that seem to hallucinate time. It’s a classic KVM headache. If your guest doesn’t have a reliable time source, your cron jobs drift, TLS handshakes fail, and your application logs become a meaningless sequence of events. Most people just throw chrony at the problem and hope it sticks, but that doesn’t actually fix the underlying issue.

Why your VM hates the hardware clock

The kernel in your VM sees a virtualized clock source. If the host kernel is busy or the vCPU scheduling is fighting for time, that virtual clock starts to skew. You end up with a guest system that thinks time is moving faster or slower than reality. Libvirt’s default clock setup is often not enough for production workloads where sub-millisecond precision actually matters. You need to tell the hypervisor to inject a stable clock source directly into the guest.

virsh edit my-vm-name
<clock offset='utc'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='kvmclock' present='yes'/>
</clock>

• Use kvmclock as your primary timer to allow the host kernel to sync time directly
• Set the tickpolicy for the RTC to catchup to prevent drift during host-side latency spikes
• Avoid using hpet if you can help it because it adds unnecessary emulation overhead

Once you update the XML and perform a clean shutdown, the next boot will expose these timers to the guest kernel. You’ll see the guest automatically pick up kvm-clock as the high-resolution source. Check /sys/devices/system/clocksource/clocksource0/current_clocksource inside the VM after a reboot to verify it actually took. If you see kvm-clock there, you’ve saved yourself hours of fighting with ntp log offsets and random auth failures.

Don’t just ignore a drifting clock because the guest appears to function. It usually starts with a few dropped logs and ends with a distributed cluster losing its mind during leader election. Fix it at the hypervisor level before your application starts making bad decisions based on a distorted reality.