You spend all morning debugging a database inconsistency only to realize the guest OS clock is drifting by a few hundred milliseconds every hour. It is a classic KVM headache. The host kernel is busy, the guest is idle, and the virtual clock source starts guessing. Most tutorials tell you to just install chrony and move on, but that only masks the underlying problem instead of fixing the frequency mismatch between the hardware clock and the hypervisor.

Why the default clocksource is rarely the right choice

Most VMs default to the kvm-clock source. It is meant to be the fastest, but if your host CPU frequency scaling is aggressive or your TSC is unstable, the guest sees a reality that simply does not exist. I have seen production workloads experience jumpy time because the hypervisor failed to present a consistent reference. Before you tweak ntp settings, check what your kernel is actually pinning its hopes on.

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

• Check if acpi_pm is forcing a slow but stable fallback
• Verify your host CPU has invariant TSC support via lscpu
• Adjust your libvirt domain XML to explicitly set the clock timer if kvm-clock behaves poorly

If you are running older guests, you might need to force the TSC as the clocksource within the boot parameters, provided your host hardware is reliable. If you see high jitter in your logs, stop blaming the guest applications. Check the host side first, because a guest clock is only as honest as the hypervisor allows it to be.