> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 >
_______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
