[ntp:questions] orphan mode, manycast, and virtualization

Rob nomail at example.com
Thu Sep 12 15:50:03 UTC 2013

Horvath Bob-BHORVAT1 <Bob.Horvath at motorolasolutions.com> wrote:
>> > Use A. C is horrible, and it is very easy for the VM's to exceed the
>> > 500PPM ntpd threshold. And ntpd does a really horrible job of
>> > disciplining a clock that keeps changing and losing time on a short
>> > timescale. It is designed for a clock with a bad, but consistant, rate.
>> > By design it takes a long time to settle down. And having something
>> > like your VM clock going to sleep for random amounts of time will
>> > drive ntpd crazy. That rules out 2 or 3.
>> > Any virtual machine should get its time from the underlying system.
>> Meaningless babble from someone without experience with ESXi.
>> Bob, please don't base your decisions on this.
> Do you have any insight into which might work better and why? 
> I think VMware at one point in time has recommended all three.  The latest one, I think, is basically C but having each VM configured as clients pointed at a known good time source.  That will allow them to slowly bring the clocks back in sync.  That makes sense to me (but what do I know).
> The thing I was exploring with manycast is if you could have them all the VMs find good time sources as manycastclients.  Maybe only having bare iron as manycastservers is the better option.  The bare iron servers can find other bare iron servers and effectively peer with each other, while the VMs would only get responses from good sources rather than be distracted by ones that may appear good for a while. 

We are using solution C and that is what is recommended by VMware.
It works fine.  unruh thinks that the clocks in the VMs do not tick well
because they are scheduled only part of the time, but that is not true
for VMware.  Apparently there has been some workaround for that issue.

More information about the questions mailing list