[ntp:questions] three questions about ntpd, kvm-clock and clock speeds

Jochen Bern Jochen.Bern at LINworks.de
Fri Oct 31 18:14:16 UTC 2014

On -10.01.-28163 20:59, Marco Marongiu wrote:
> On the web many (supposedly) authoritative sources disagree about how
> clocks should be synced on KVM hosts and VMs. You can find both those
> who say that ntpd should run on both sides and others that advise for
> having ntpd just on the host and have the VMs use the kvm-clock
> clocksource to "follow" the host's clock (but they don't say what
> "follow" exactly means).

Indeed they don't. (Warning, half-rant following.)

While one of the web pages you already read states:

"Keeping time in virtual machine is acknowledged as a hard problem."
-- https://lkml.org/lkml/2010/4/15/355

those providing us with the building blocks for virtualized computer
platforms fail to realize that keeping a network of distributed clocks
synchronized is hardly a *new* problem, and has an existing vocabulary.
Namely, those clocks can provide each other: An initialization value,
frequency (be it as a delta or as interrupts, and it can be either a raw
not-quite-known but hopefully stable frequency from an independent
oscillator, or a somewhat less stable but true frequency from an
already-disciplined clock), and offset; in addition, aspects of the
communication (delay, visibility) may come into play.

Instead of telling us in *these* terms what the stuff they've built
does, we get a) pages and pages of implementation details of the
specific building block in splendid isolation, and b) the shortcut
recommendations that say "thou shalt (not) run ntpd on VMs" without
explaining (much of) the reasons behind it.

I'm no less confused by the metric tons of a) than you are, but let me
pick two such documents, *assume* them to be (still) correct, and show
you what my translation thereof would be:

Again, this LKML posting:


speaks about what goes *through* the kvm-clock interface, i.e., the
properties of the Linux kernel running as the *host* OS and feeding it.
It says that the interface offers the full current time to the best of
the host's knowledge, presumably from its OS clock (which is decoupled
from the host's HW clock).

Now, if the host is running an ntpd (*), its notion of time will - in
the long run - be quite correct, which is to say that the interface will
offer good information for both frequency and offset.

Here's another LKML posting from the same year:


This one speaks about what the Linux kernel *takes* from the
clocksources, i.e., when running as the guest OS. And lo, the data
provided is only assumed to be a *counter* with overflows, with no way
to derive the actual time and date. It also makes mention that
clocksources may be independent hardware oscillators.

Translation: The Linux guest OS takes only the frequency information
from the kvm-clock interface, and doesn't trust that frequency to be
true, either (so I'ld *guess* that the usual correction mechanisms of
the kernel are left in place between that source and the actual OS clock).

Conclusion in the case of the host running ntpd: The guest will take and
use the (true) frequency of the host, thus having a good frequency
itself with no further measures being taken (unless someone manually
disturbs the timing on the host), but has no means to correct offsets
yet. Which is what you observe in reality. Hey, we may be on to
something here! :-}

Still *assuming* that all this information is correct, you can now make
up your own mind whether correcting the offset (and countering manual
intervention on the host) is something you want to run ntpd on the VMs
for (which is an option in the first place only because the information
from the host does get filtered through the guest kernel's correction
mechanisms, whose controls ntpd takes into its hands).

(*) I'm also assuming that the host's ntpd will be using *remote* time
sources. Since the vendors do not think in terms of clocks getting
networked, few, if any, of their HowTos include the explicit statement
that *if* you need to put low-stratum clocks onto your virtualized
platform itself, you'd better *not* put them on the *VMs*, so as to
avoid a feedback loop from the VM through its own host back to the VM.
In one project whose VMs got moved from a provider's platform to a
dedicated one, lack of such a statement made the management decide that
the master clock should stay where it was, on one of the VMs, *and* feed
the new systems, i.e., the hosts. One oscillating platform and emergency
maintenance later, things are configured like I suggested from square
one ...

								J. Bern
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel

More information about the questions mailing list