To the best of my knowledge, it has never been an issue. Thanks for the link! I will update my mental records accordingly.
On Tue, Nov 18, 2014 at 3:15 PM, Mathew Snyder <mathew.sny...@gmail.com> 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 compassionate have no enemies, the wise have no worries." ##### - Jing-si Aphorism ##### http://kso.cc
_______________________________________________ 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/
