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'. -d _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
