Horvath Bob-BHORVAT1 <bob.horv...@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. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
