KVM guests clock synchronisation

The recommended method to keep KVM guests clock in sync is a controversial topic: the solution seems to depend on many factors including available clock sources and host processor type.

Adjust host clock

To begin, adjust the host's clock and keep it accurate by running the NTP daemon.

Verify clock source

Use the following on the guest to check the currently used clock source:

dmesg | grep kvm-clock

It should print something like

kvm-clock: cpu 0, msr 0:14f1701, boot clock
kvm-clock: cpu 0, msr 0:8c15701, primary cpu clock
kvm-clock: cpu 1, msr 0:8c95701, secondary cpu clock
kvm-clock: cpu 2, msr 0:8d15701, secondary cpu clock
kvm-clock: cpu 3, msr 0:8d95701, secondary cpu clock
Switching to clocksource kvm-clock

Another check can be done by running

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

which should print kvm-clock. Warning: RHEL/CentOS 5.x x86_64 will always return "jiffies", no matter what[1]; on these guests rely on the previous method.

Check available clock sources

Check which clock sources are available to the guest by running

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

If you are running a 2.6.27 kernel and above, you should see kvm-clock in the output. If it is not there, you can try the additional guest kernel parameters suggested by RedHat[2]:

Red Hat Enterprise LinuxAdditional guest kernel parameters
6.0 AMD64/Intel 64 with the para-virtualized clockAdditional parameters are not required
6.0 AMD64/Intel 64 without the para-virtualized clocknotsc lpj=n
5.5 AMD64/Intel 64 with the para-virtualized clockAdditional parameters are not required*
5.5 AMD64/Intel 64 without the para-virtualized clockdivider=10 notsc lpj=n
5.5 x86 with the para-virtualized clockAdditional parameters are not required
5.5 x86 without the para-virtualized clockdivider=10 clocksource=acpi_pm lpj=n
5.4 AMD64/Intel 64divider=10 notsc
5.4 x86divider=10 clocksource=acpi_pm
5.3 AMD64/Intel 64divider=10 notsc
5.3 x86divider=10 clocksource=acpi_pm
4.8 AMD64/Intel 64notsc divider=10
4.8 x86clock=pmtmr divider=10
3.9 AMD64/Intel 64 Additional parameters are not required
3.9 x86Additional parameters are not required
* Although additional parameters are not required, the divider=10 parameter can still be used. Guests with this parameter will produce less CPU load in the host, but will use more coarse-grained timer expiration.

Use CPU affinity (pinning)

A support document from Novell[3] presents one more attempt to mitigate the clock drift which consists in specifying which CPUs should be used by the guest; the operation is easier if a virtualization management framework like libvirt is in use.

Use NTP on guests?

Different distributions have opposed opinions on running a NTP daemon inside the guests. Ubuntu's Community Documentation suggests:

Guests should not use ntp to synchronize the clock, so be sure to remove/disable ntpd.

On the contrary, the RHEL 6 Virtualization guide states:

The Network Time Protocol (NTP) daemon should be running on the host and the guests.

Finally, the SLES Virtualization with KVM manual states:

When using kvm-clock, it is not recommended to use NTP in the VM Guest, as well. Using NTP on the VM Host Server, however, is still recommended.

Test case

The following combination of software versions does not show any appreciable clock drift:


  1. [^] Linux-KVM documentation
  2. [^] RHEL 6 Virtualization Guide, KVM guest timing management
  3. [^] Clock drifts in KVM virtual machines for SUSE Linux Enterprise Server 11 Service Pack 1
  4. KVM pvclock, KVM's paravirtualized clock source internals
  5. Qemu-devel list thread on ntp and kvm-clock


Major content re-organization and update.

Comments are welcome at mailbox@s19n.net.
If this article was valuable to you, you may consider donating.