I think I found the one you're referring to but I don't recall seeing ntpdate mentioned.
On Tue, Nov 18, 2014, 12:58 Chris Snell <k...@employees.org> wrote: > VMWare has a big long KB article on all the tweaks you need to make to > your OS > for NTP depending on the OS and version. When you're in a shop like ours > that > runs 3 different RHEL versions with varying patch levels, it can be a bit > of a > nightmare to keep up with. I don't have the KB article handle, but I'm > sure you > can find it without too much trouble. > > - Chris > > On Tue, 18 Nov 2014, Mathew Snyder wrote: > > >> VMs in our public cloud environment required VMware Tools to be > > installed, so we were able to force each VM to synchronize its time with > > the ESXi host that it lived on, via Edit Settings. > > > > Has this ever been an issue? VMware recommends against using VMware Tools > > to sync time: > > http://kb.vmware.com/selfservice/microsites/search. > do?language=en_US&cmd=displayKC&externalId=1006427 > > > > "VMware recommends using NTP instead of VMware Tools periodic time > > synchronization. NTP is an industry standard and ensures accurate > > timekeeping in your guest." > > > > I should point out that our environment is hosted. We don't have control > > over how the ESXi hosts are configured, but we do believe they are > syncing > > to a source internal to the provider. > > > > > > -Mathew > > > > "When you do things right, people won't be sure you've done anything at > > all." - God; Futurama > > > > "We'll get along much better once you accept that you're wrong and > neither > > am I." - Me > > > > On Tue, Nov 18, 2014 at 12:07 PM, Chris Lindbergh < > chrislindbe...@gmail.com> > > wrote: > > > >> Good question Matthew! > >> > >> Here's how we tackled NTP & vCloud/ESXi at $job-1: > >> > >> As our ESXi hosts were authenticating off an Active Directory domain, > and > >> best practices for AD is to point NTP to your Domain Controllers (or > >> whatever the DC's are using if they don't run NTP themselves) to ensure > >> authentication doesn't break due to time skew, we pointed each host to > the > >> DCs for NTP. > >> > >> VMs in our public cloud environment required VMware Tools to be > installed, > >> so we were able to force each VM to synchronize its time with the ESXi > host > >> that it lived on, via Edit Settings. > >> > >> We had hardware devices (Cisco routers) that we enabled NTP servers on, > >> and pointed our DCs to those. These routers themselves looked to the > U.S. > >> pool of ntp.org for proper time. > >> > >> This way NTP clients on the domain could get time from the DCs, and > >> clients not on the domain could talk to the routers. > >> > >> If cloud customers ran ntpdate or ntpd or any other NTP client/server, > we > >> figured it should stay very close to what we were setting it to, and > this > >> was the case in our tests. > >> > >> > >> > >> > >> > >> > >> On Tue, Nov 18, 2014 at 2:55 PM, Matt Simmons <msimm...@lopsa.org> > wrote: > >> > >>> As of a major version ago on ESXi, it was considered best practice to > run > >>> ntpdate in a cron rather than ntpd on VMs, particularly if you weren't > >>> using the most up-to-date VMware tools (and I believe they recommended > the > >>> VMware version, rather than open-vm tools). > >>> > >>> I've also seen that behavior when a VM Host had a screwed up NTP > config. > >>> > >>> I haven't noticed any significant clock skew during a vmotion, but I've > >>> never checked it. I can give it a shot if you'd like. > >>> > >>> --Matt > >>> > >>> > >>> On Tue, Nov 18, 2014 at 4:50 PM, Mathew Snyder < > mathew.sny...@gmail.com> > >>> wrote: > >>> > >>>> We are currently in a situation where we are being pressured to > >>>> re-engineer our NTP service. We currently host it, along with other > >>>> services, on Windows DCs. Our initial plan is to move NTP off of those > >>>> servers and host it on dedicated Linux servers. > >>>> > >>>> We likely won't get approval for hardware to host NTP and will thus > have > >>>> to rely on VMs. This poses a few concerns such as: How will a Vmotion > >>>> affect the service? What happens if access to the sources that we use > is > >>>> lost (for whatever reason)? > >>>> > >>>> In the past, all of our VMs would run ntpd normally. That is, as a > >>>> constantly running daemon.. However, we found that time was drifting > >>>> significantly to the tune of several seconds a day on several > servers. We > >>>> never figured out why it was happening. Instead, we found that using > a cron > >>>> job which runs /usr/sbin/ntpd every five minutes kept time synced up > >>>> nicely. We haven't had any issues since. > >>>> > >>>> However, now Red Hat is telling us we should (need) to be running ntpd > >>>> as a daemon because they are seeing timing issues. Interestingly, > this was > >>>> never brought to the attention of us platform engineers so I don't > know how > >>>> bad the problem is or how many servers are affected. > >>>> > >>>> The problem could be VMware Tools conflicting with ntpd. But again, we > >>>> don't know what the problem is. Only that we have a workaround-type > >>>> solution that we're being told we have to replace. > >>>> > >>>> This leads to my question to the list: those of you who have cloud > >>>> environments based on VMware solutions, how do you keep time in sync? > What > >>>> issues have you encountered and how did you solve those problems? > What can > >>>> you recommend for a virtualized NTP solution? > >>>> > >>>> > >>>> -Mathew > >>>> > >>>> "When you do things right, people won't be sure you've done anything > at > >>>> all." - God; Futurama > >>>> > >>>> "We'll get along much better once you accept that you're wrong and > >>>> neither am I." - Me > >>>> > >>>> _______________________________________________ > >>>> Tech mailing list > >>>> Tech@lists.lopsa.org > >>>> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > >>>> This list provided by the League of Professional System Administrators > >>>> http://lopsa.org/ > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Tech mailing list > >>> Tech@lists.lopsa.org > >>> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > >>> This list provided by the League of Professional System Administrators > >>> http://lopsa.org/ > >>> > >>> > >> > >> > >> -- > >> ##### "The compassionate have no enemies, the wise have no worries." > >> ##### - Jing-si Aphorism > >> ##### http://kso.cc > >> > > > > "The greatest pleasure in life is doing what people say you cannot do." > - Walter Bagehot >
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
