Stop your KVM guest time from drifting when the host gets busy

Technical Briefing | 11/8/2026

You probably think your virtual machines have a reliable clock because the host is running NTP. But the moment your host load spikes, KVM interrupts get delayed, and the guest kernel starts hallucinating. I have seen production database nodes lose seconds of real time during a heavy backup window because the hypervisor couldn’t process timer interrupts fast enough. It is a silent killer for logs, application timeouts, and distributed consensus algorithms.

Why the guest thinks time is optional

When a guest kernel uses the TSC clocksource, it assumes it can track time by reading the CPU cycle counter. In a virtualized environment, this cycle counter is virtualized and can jump around if the vCPU gets descheduled. If you don’t explicitly tell KVM to provide a stable clock reference, you are asking for trouble. Most defaults are safe for generic web servers, but for anything latency-sensitive, you need to pin the clocksource.

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

• The kvmclock provides a paravirtualized clock that survives vCPU preemption
• Adding hypervclock improves time synchronization for Windows guests significantly
• Set present to no for the rtc timer if it causes excessive vmexit overhead

After you update the XML and trigger a cold boot, verify what the guest actually sees by checking sysfs. If your guest shows hpet or acpi_pm as the current clocksource, it is working way too hard for every tick. Ideally, you want to see kvm-clock as the active source. Don’t rely on NTP to fix underlying virtualization timing issues because the jumps will still mess up your application logic before the daemon can catch up.

Check your guest clocksource with cat /sys/devices/system/clocksource/clocksource0/current_clocksource. If you are still seeing drift after enforcing the hypervisor timers, it is time to look at cpu-pinning to ensure your vCPUs aren’t bouncing across physical cores.