Stop Time Drift From Sneaking Up On Your KVM Guests

Technical Briefing | 9/2/2026

You’ve got your KVM guests running, `chronyd` installed inside, and you probably think time is handled. Right? Mostly. But I’ve seen situations where even with `chronyd` pulling from a good upstream, guest clocks still drift enough to cause havoc. Think database replication errors, Kerberos tickets expiring too soon, or distributed transaction failures that are an absolute nightmare to track down. It’s not always obvious either; sometimes it’s just a few milliseconds, just enough to break assumptions. This bit me hard once when a whole distributed messaging system went sideways on a heavily loaded host, and nobody could figure out why things were out of order. Turns out, it was clock drift.

The Subtle Killer: Virtual CPU Scheduling and TSC Drift

The problem fundamentally boils down to how your guest’s virtual CPU (vCPU) perceives time, especially the Time Stamp Counter (TSC) on the underlying host CPU. A physical CPU’s TSC typically increments at a constant rate, but a vCPU isn’t running continuously on a single physical core. It gets scheduled, preempted, migrated between cores, or even paused. Each time this happens, the vCPU’s internal TSC can get out of sync with the *actual* wall clock time. Modern CPUs usually have a “constant TSC” feature, which helps a lot, but not all hosts have it, and even then, guest-specific issues can crop up, especially under high host load or with older QEMU versions. And QEMU, by default, tries to abstract this away, but sometimes its best efforts aren’t quite good enough.

Checking Your Guest’s Current Clock Configuration

virsh dumpxml myguestname | grep -E 'clock|timer'

The output from `virsh dumpxml` is where you’ll find the specific clock and timer configurations KVM is providing your guest. You’ll often see something like `<clock offset=’utc’>` which is almost always the right starting point for any OS. But the real devil is in the `<timer>` elements. QEMU and KVM offer various timer types: `kvmclock`, `hypervclock` (if using Windows guests, but helpful for Linux too), `hpet`, `tsc`, `rtc`. For Linux guests, `kvmclock` is usually the go-to, as it’s specifically designed for KVM environments and should handle vCPU scheduling gracefully. You might see `hpet` or `tsc` active by default, and those are often the culprits for drift.

The Right Approach: Explicitly Hardening Your VM Timers

• Always set `<clock offset=’utc’/>`. Let your operating system handle timezone conversions, not the hypervisor.
• For modern Linux guests, always include `<timer name=’kvmclock’ present=’yes’/>`. This is the most accurate, purpose-built source for KVM.
• Also include `<timer name=’hypervclock’ present=’yes’/>` for additional stability; modern Linux kernels have robust Hyper-V enlightenment drivers.
• Explicitly disable problematic legacy timers: `<timer name=’hpet’ present=’no’/>` is usually a good idea.
• If you find you absolutely need `tsc` (rare with `kvmclock` present), ensure it’s configured safely: `<timer name=’tsc’ present=’yes’ mode=’apic’/>`. But prefer `kvmclock`.
• Don’t forget `chronyd` or `ntpd` inside the guest – these settings just give it a stable, accurate baseline to work from, making their job much easier.

Getting these timer settings explicitly right means your guests start with a much more stable time base. It won’t solve every single time issue (especially if your host itself is drifting or overloaded), but it eliminates a huge class of subtle, hard-to-diagnose problems that originate deep in the hypervisor-guest interaction. This knowledge really pays off when you’re debugging a “why the heck did that transaction fail” moment at 3 AM and the application logs show wildly out-of-sync timestamps.