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
which should print
kvm-clock. Warning: RHEL/CentOS 5.x x86_64 will always return "jiffies", no matter what; on these guests rely on the previous method.
Check available clock sources
Check which clock sources are available to the guest by running
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:
|Red Hat Enterprise Linux||Additional guest kernel parameters|
|6.0 AMD64/Intel 64 with the para-virtualized clock||Additional parameters are not required|
|6.0 AMD64/Intel 64 without the para-virtualized clock||notsc lpj=n|
|5.5 AMD64/Intel 64 with the para-virtualized clock||Additional parameters are not required*|
|5.5 AMD64/Intel 64 without the para-virtualized clock||divider=10 notsc lpj=n|
|5.5 x86 with the para-virtualized clock||Additional parameters are not required|
|5.5 x86 without the para-virtualized clock||divider=10 clocksource=acpi_pm lpj=n|
|5.4 AMD64/Intel 64||divider=10 notsc|
|5.4 x86||divider=10 clocksource=acpi_pm|
|5.3 AMD64/Intel 64||divider=10 notsc|
|5.3 x86||divider=10 clocksource=acpi_pm|
|4.8 AMD64/Intel 64||notsc divider=10|
|4.8 x86||clock=pmtmr divider=10|
|3.9 AMD64/Intel 64||Additional parameters are not required|
|3.9 x86||Additional 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 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.
The following combination of software versions does not show any appreciable clock drift:
- Linux kernel 2.6.32 amd64 from Debian 6.0.3 on host and guest
- ntp 4.2.6 on host only
- qemu-kvm 0.12.5
- [^] Linux-KVM documentation
- [^] RHEL 6 Virtualization Guide, KVM guest timing management
- [^] Clock drifts in KVM virtual machines for SUSE Linux Enterprise Server 11 Service Pack 1
- KVM pvclock, KVM's paravirtualized clock source internals
- Qemu-devel list thread on ntp and kvm-clock
- Major content re-organization and update.
Comments are welcome at email@example.com.
If this article was valuable to you, you may consider donating.