[ntp:questions] orphan mode, manycast, and virtualization
Bob.Horvath at motorolasolutions.com
Thu Sep 12 14:22:22 UTC 2013
> -----Original Message-----
> From: questions-bounces+bob.horvath=motorolasolutions.com at lists.ntp.org
> [mailto:questions-bounces+bob.horvath=motorolasolutions.com at lists.ntp.org] On
> Behalf Of Rob
> Sent: Monday, September 09, 2013 12:56 PM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] orphan mode, manycast, and virtualization
> unruh <unruh at invalid.ca> wrote:
> > On 2013-09-09, Horvath Bob-BHORVAT1 <Bob.Horvath at motorolasolutions.com>
> >> Another question if you guys have the time :),
> >> We situations in which we have almost everything deployed as virtualized
> servers running inside of VMware ESXi. It seems like the recommendation on
> time synchronization with ESXi has changed from release to release. It seems
> to boil down to one of the following:
> >> A) Run ntpd on the bare iron at the ESXi layer and let it change the
> virtual hardware clock (without ntpd running on VMs)
> >> B) Run ntpd on the bare iron at the ESXi layer and let ntpd on the VMs
> use it as a time source
> >> C) Run ntpd on all the VMs and point them to as many "good" ntp
> servers that you can find whether in its own ESXi or another physical server's
> > 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.
More information about the questions