[ntp:questions] Red Hat vote for chrony

detha detha at foad.co.za
Mon Dec 8 08:49:39 UTC 2014

On Sun, 07 Dec 2014 09:46:35 +0000, David Woolley wrote:

> On 07/12/14 09:08, detha wrote:
>> More and more of those servers end up being virtualized. Quicker
>> reaction to virtualization funnies, and faster convergence on VMs that
>> are spun up/down on demand, seem to be one of the main reasons Redhat
>> switched to chrony.
> Surely the right solution for that is a virtualisation assist API that
> provide access to the host time, and if it is possible to read residual
> counts/cycle counters, without virtualisation overhead, to communicate the
> information needed to use that data for the next few seconds. Obviously
> that requires work from the developers of the virtual hosts.

It requires development on both the vhost and the guest systems. The
typical OS reads time from the RTC at boot, and then keeps its own time
based on clock interrupts/TSC/... To get all those to sync perfectly is
apparently harder than it seems, especially when one takes into account
that the guest can migrate between vhosts. In any case, it means running
some driver on the guest that updates the guest's idea of current time
based on a call to the hypervisor. Which is close to running an ntp client
on the guest with a special refclock driver that calls to the hypervisor.
(come to think of it, do such a refclock drivers exist?)

The 'recommended best practice' seems to have been oscillating between
'sync with vhost' versus 'guest runs own (s)ntp client' in a one or two
year cycle. Every once in a while VMWare/KVM/Xen think 'now we have got
guest sync right', and advise to use guest sync. Then is turns out there
are still some corner cases where it doesn't work, and the advise goes
back to 'use an ntp client on the guest'.


More information about the questions mailing list