That is almost certainly the problem. In 6.0, SRM is much more sensitive to time skew and 5 minutes is likely to be too much.
I have placed the vCenter in the correct time zone now by using the following process:
Enable SSH in the vCenter 6 appliance console
Enable BASH in the vCenter 6 appliance console
Putty in the vCenter 6 appliance
putty into the vCenter 6 appliance
Enter the root/PW
Enter the following commands:
* This will display the list of available time zones, in my case I needed Eastern, replace with your time zone
ln -s /usr/share/zoneinfo/US/Eastern localtime
* Verify that you are now displaying the correct date and time.
** Optionally you can set the appliance to use an NTP server by using the following command:
sntp -P no -r time.windows.com
I am still having the exact same problem even though the ESXi host and the vCenter6 appliance are now perfectly synced for time. After doing more digging I see that when I putty into the host and type 'date' I get a totally different result then what I'm seeing in the host details within vCenter itself. Keep in mind, this in the same host displaying two different time settings, any idea why?
The commands I used to set the time zone within the appliance do not work on an ESXi host, however this has already been set correctly within the GUI, why would I need to set it in both places anyway??
Just ran into the same issue. My time sync was only off by about 45 seconds. I changed the local server time to be as close as possible (within 1 or 2 seconds) and the installer let me proceed.
I'm not sure why, but this issue seems to have just vanished on its own. I haven't been able to reproduce it since I initially encountered it.
I had this happen today. I also, only had a 45 second time skew between the Windows 12 server that was hosting SRM and the vCSA 6.5 appliance. Since the Windows server had a group policy that didn't allow me to mess with the NTP, I was left with the vCSA side.
Here's what fixed it for me ..
0) reboot the windows SRM server (to refresh ntp)
1) puTTy to vCSA
3) show the time offset:
4) stop ntpd:
systemctl stop ntpd
5) start ntpd:
systemctl start ntpd
Hope this helps someone else.
I know this is an old article but someone may come across this.
Recently came across this issue.
I am using appliances for vCenter and SRM.
I had a time skew issue as well. It took me a while and I had NTP running on the appliances and they were 26 seconds off.
I'd add seconds to the CLI (date -s “26 seconds”) of the vCenter only for it to slowly go back to time being out of sync.
I realized I had the virtual appliance syncing it's time to the hosts through vmtools as well as using NTP.
So anything happening on the NTP side within the appliance was negated by vmtools.
I disabled vmtools from syncing time to the hosts and to use NTP that worked and I was able to connect SRM to the vCenter.
I then fixed the NTP issue on the hosts as well.