Changing NTP Server in ESX 3.5 fails with error “failed to change host configuration”
I ran into another ESX configuration issue this week that seems to continue to hang around even though it was identified quite a long time ago. After a fresh install of two different ESX 3.5 Update 2 servers (installed from the 110268 build .iso), I was configuring NTP time sync from the VI Client (installed from the VirtualCenter 2.5 Update 3 119825 build .iso) and was unable to change the NTP server. The error message window told me “failed to change host configuration”. Most frustrating to me is the fact that I have been able to change the NTP configuration from the VI client in past versions of ESX 3.5.
I was able to manually change the NTP configuration by digging out the related recommendations from the VMTN Communities thread VMware Communities: ESX 3.5 - Time Configuration = “Failed …. I have summarized my resolution steps in the rest of this post. Note that I did not have to modify all of the files and settings (steptickers, esx firewall) as previously required (and scripted) when manually changing NTP sync in ESX version 3.0.X.
Early in the VMTN thread was the advice:
“To use the NTP Time setup configuration option, your ESX server must also be in Maintenance mode. Once that is done, it works just fine.”
Honestly, I did not try this for my scenario but I wanted to point this out for future reference. Replies in the thread indicated putting the host in maintenance mode did not fix the error.
Later in the thread I found my resolution and cause of the problem.
“The issue happens when you set ZONE=UTC in /etc/sysconfig/clock. The host agent uses the timezone list in /usr/share/zoneinfo/zone.tab to determine if the ZONE is valid. Since UTC isn’t in zone.tab, it thows an error and will not change the NTP settings.
There is an PR open for this issue internally, but you should probably also file an SR so that this will be fixed in a future release. As a workaround, would it possible for you to use a timezone that does appear in /usr/share/zoneinfo/zone.tab?”
Sure, changing that file is possible! VMware, if you are reading this please consider this post an informal Support Request.
To investigate I used putty and nano. Putty for remote access from my XP workstation and nano because I never seem to remember how to use vi. I opened 2 Putty sessions to the ESX host. Logged in as root I typed:
in the first putty session
#nano /ect/sysconfig/clock
in the second putty session
#nano /usr/share/zoneinfo/zone.tab
For the hosts I was working on /etc/sysconfig/clock was set to
ZONE=”Etc/GMT-5″
UTC=true
ARC=false
Looking at the other Putty session I was not a matching zone entry in /usr/share/zoneinfo/zone.tab. So, it was obvious I had to find the appropriate entry. The file is alphabetically in order by the first column of location abbreviations and I had to scroll all the way down to the US entries. I found the following entry for my timezone:
America/New_York
Then I changed /etc/sysconfig/clock to match the zone.tab entry and look like this
ZONE=”America/New_York”
UTC=true
ARC=false
Ctrl+W saves the file changes in nano and prompts you for over writing the original file
Then I used nano to change
/etc/ntp.conf
#nano /etc/ntp.conf
The VMTN thread suggests the line with the default NTP server to change will read “server 127.1.0.1″, but in my file the line was slightly different. I had to change “server 127.127.0.0″ to “XXX.XXX.XXX.XXX” where “XXX.XXX.XXX.XXX” is the new NTP server to sync with.
Once again Ctrl+W in nano saves the changes.
To make it all work I had to restart the NTP service
#service ntpd restart
Then to make the changes show up in the VI client I had to restart the VMware management service
#service mgmt-vmware restart
The NTP information was updated in the VI Client.
Just for a “warm fuzzy” I also ran the following from one of the Putty sessions before closing them out.
#ntpq -p
That will show you the time sync is working and if there is any offset.
Related Posts
Tags: esx3.5, how to, issues, ntp, putty, update 2, vi client, vmtn, vmware
