Why NTP still runs inside virtual machines despite guest agents and paravirtual clocks

What it is

A guest's sense of time inside a VM is affected by more than one mechanism. On KVM, the kernel's timekeeping documentation describes kvmclock (kvmclock/kvm-clock) as a paravirtualized clocksource the guest kernel can use instead of emulating a hardware clock in software, which reduces the drift and overhead that come from trapping and emulating timer hardware. QEMU separately offers the QEMU Guest Agent (qemu-ga), a daemon installed inside the guest that lets the host issue commands to it over a virtio-serial channel — a management channel, not a clock source, although it can set the guest clock once on request (virsh domtime <domain> --sync, which reads the time from the guest's RTC). Hyper-V provides its own integration services, which include a Time Synchronization service (vmictimesync) that synchronizes the guest clock with the host's.

Why it matters

None of these mechanisms is a substitute for running a time-sync client (chronyd, systemd-timesyncd, or Windows Time service) inside the guest:

• kvmclock improves the quality and stability of the clock source available to the guest kernel; it does not synchronize the guest to true time, and it can still drift, particularly across host migrations, host suspend/resume, or heavy host CPU contention that delays when the guest's virtual CPU actually runs.
• The QEMU guest agent can step the clock once when told to (for example after a resume), but it does not discipline the clock continuously.
• Hyper-V's time synchronization component follows the host's clock, so the guest is only as accurate as the host; the host itself still needs a good time source, and the guest still benefits from its own time service (Windows Time, chronyd or systemd-timesyncd).

How to apply

• Keep an NTP/chrony (or Windows Time) client active and correctly configured inside every guest, regardless of hypervisor or guest tools installed.
• After host migrations, snapshot restores, or resuming a paused/suspended VM, expect a jump in guest time until the in-guest client corrects it; check service status (chronyc tracking, w32tm /query /status) after such events rather than assuming continuity.
• Confirm which clocksource a Linux guest is actually using: cat /sys/devices/system/clocksource/clocksource0/current_clocksource (typically kvm-clock on KVM guests; newer guest kernels may prefer tsc when the host exposes a stable invariant TSC). cat /sys/devices/system/clocksource/clocksource0/available_clocksource lists the alternatives.
• Treat host-provided time hints (Hyper-V's time synchronization integration service, VMware's equivalent) as a coarse correction layer next to the guest's own time service, and check the hypervisor vendor's guidance for special roles such as virtualized domain controllers, where the two sources can conflict.

Pitfalls

• Disabling the in-guest NTP client because "the hypervisor handles time," then seeing certificate validation, Kerberos, or log-correlation failures after a migration or resume event.
• Assuming kvmclock alone keeps wall-clock time accurate; it is a clocksource property, not a synchronization protocol.