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: https://lkml.org/lkml/2010/4/15/355 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: https://lkml.org/lkml/2010/11/15/101 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 ... Regards, 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
