VMware Cloud Community
mclark
Expert
Expert
Jump to solution

Time problems w/ ESX 3.0.2

I've read several threads on how to fix time problems with ESX, and I've tried lots of things, but I just can't get it to work. The HW clock shows the right time, and ESX is 5 hours behind. The time zone is correct as far as I can tell. I can sync the HW clock to the system to get it right, but when I reboot the server it comes up 5 hours behind again. I'm needing some advice on what to do to get this working. I am planning on upgrading to 3i when it comes out so maybe this is a moot point when that happens, but I'd still like to know what is wrong...

Thanks!

Reply
0 Kudos
1 Solution

Accepted Solutions
Texiwill
Leadership
Leadership
Jump to solution

Hello,

Your ESX Server needs to be synced to a timeserver. Is your timeserver itself allowing the communication?

echo timeserver > /etc/ntp/step-tickers

echo "server timeserver" >> /etc/ntp.conf

esxcfg-firewall -e ntpClient

chkconfig ntpd on

service ntpd restart

The above is the bare minimum required to get TIME to sync to an ESX server. To get VM's to sync you need to comment out the 'restrict' lines in the /etc/ntp.conf file.

Note that timeserver must be on your subnet or reachable by your system.

You can use 'ntpq' or ntptrace to see what is happening and what problems exist.

Good reference: http://www.ntp.org

Best regards,

Edward

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill

View solution in original post

Reply
0 Kudos
11 Replies
Texiwill
Leadership
Leadership
Jump to solution

Hello,

Your ESX Server needs to be synced to a timeserver. Is your timeserver itself allowing the communication?

echo timeserver > /etc/ntp/step-tickers

echo "server timeserver" >> /etc/ntp.conf

esxcfg-firewall -e ntpClient

chkconfig ntpd on

service ntpd restart

The above is the bare minimum required to get TIME to sync to an ESX server. To get VM's to sync you need to comment out the 'restrict' lines in the /etc/ntp.conf file.

Note that timeserver must be on your subnet or reachable by your system.

You can use 'ntpq' or ntptrace to see what is happening and what problems exist.

Good reference: http://www.ntp.org

Best regards,

Edward

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
esiebert7625
Immortal
Immortal
Jump to solution

Check out the below kb article, it has alot of steps for verifying that your time zone is setup correctly...

Reply
0 Kudos
boydd
Champion
Champion
Jump to solution

Do the commands "date" and "clock" show the same time zone info? Could you post you ntp.conf file? Could you post the output from "watch "ntpq -p".

DB

DB
mclark
Expert
Expert
Jump to solution

I've followed Texiwill's instructions and ntp is now syncing, however, it is syncing with the HW clock and not the server I specified. This is OK since the HW clock is correct, but I'm not sure why it is not talking to the server. I can ping the server I specified, so they are talking. Here is the ntp.conf and output of ntpq -p as requested, in case something is wrong with it.

====== NTP.CONF

  1. Prohibit general access to this service.

restrict default ignore

  1. Permit all access over the loopback interface. This could

  2. be tightened as well, but to do so would effect some of

  3. the administrative functions.

restrict 127.0.0.1

  1. -- CLIENT NETWORK
    -----

  2. Permit systems on this network to synchronize with this

  3. time service. Do not permit those systems to modify the

  4. configuration of this service. Also, do not use those

  5. systems as peers for synchronization.

  6. restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap

  1. - OUR TIMESERVERS
    ---

  1. or remove the default restrict line

  2. Permit time synchronization with our time source, but do not

  3. permit the source to query or modify the service on this system.

  1. restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery

server xx.xx.xx.xx

  1. --- NTP MULTICASTCLIENT ---

#multicastclient # listen on default 224.0.1.1

  1. restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap

  2. restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap

  1. --- GENERAL CONFIGURATION ---

#

  1. Undisciplined Local Clock. This is a fake driver intended for backup

  2. and when no outside source of synchronized time is available. The

  3. default stratum is usually 3, but in this case we elect to use stratum

  4. 0. Since the server line does not have the prefer keyword, this driver

  5. is never used for synchronization, unless no other other

  6. synchronization source is available. In case the local host is

  7. controlled by some external source, such as an external oscillator or

  8. another protocol, the prefer keyword would cause the local host to

  9. disregard all other synchronization sources, unless the kernel

  10. modifications are in use and declare an unsynchronized condition.

#

server 127.127.1.0 # local clock

fudge 127.127.1.0 stratum 10

#

  1. Drift file. Put this in a directory which the daemon can write to.

  2. No symbolic links allowed, either, since the daemon updates the file

  3. by creating a temporary in the same directory and then rename()'ing

  4. it to the file.

#

driftfile /var/lib/ntp/drift

broadcastdelay 0.008

#

  1. Authentication delay. If you use, or plan to use someday, the

  2. authentication facility you should make the programs in the auth_stuff

  3. directory and figure out what this number should be on your machine.

#

authenticate yes

#

  1. Keys file. If you want to diddle your server at run time, make a

  2. keys file (mode 600 for sure) and define the key number to be

  3. used for making requests.

#

  1. PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote

  2. systems might be able to reset your clock at will. Note also that

  3. ntpd is started with a -A flag, disabling authentication, that

  4. will have to be removed as well.

#

keys /etc/ntp/keys

=== END OF NTP.CONF

=== NTPQ -P OUTPUT

remote refid st t when poll reach delay offset jitter

===== ======= == = ==== === ==== ==== ===== ====

xx.xx.xx.xx 0.0.0.0 16 4 - 64 0 0.000 0.000 4000.00

LOCAL(0) LOCAL(0) 10 1 10 64 7 0.000 0.000 0.008

Reply
0 Kudos
bguthrie1
Contributor
Contributor
Jump to solution

I had the same issue, I could get everything to sync and NTP to work and when I rebooted it would be wrong again. I did a hwclock --systohw forcing the hardware clock to sync from the system and it stayed correct.

Reply
0 Kudos
Texiwill
Leadership
Leadership
Jump to solution

Hello,

Actually it is the restrict lines. If you remove them you should also be fine. I leave my systems without the restrict lines and just do not allow NTP to come in via the firewall (which is the default).

Best regards,

Edward

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
mclark
Expert
Expert
Jump to solution

Is there a 'restrict' line I can put in to restrict everything EXCEPT that one server? Barring that, how can I check the firewall to ensure that any incoming NTP requests are blocked?

Thanks!

Reply
0 Kudos
Texiwill
Leadership
Leadership
Jump to solution

Hello,

I would not restrict anything on the ESX server as the VMware Tools use this service to keep the VMs in time sync as well.

It is blocked by default. The port is 123 tcp and 123 udp. You will not that there is no incoming port for that already opened, since the default policy is to drop anything not explicitly allowed, you are safe.

From SC:

iptables -L INPUT -n | grep 123

Will list if anything is open on that port.

Best regards,

Edward

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
tWiZzLeR
Enthusiast
Enthusiast
Jump to solution

There is a great script available that will automatically setup NTP on ESX 3.x servers: . I used it on several servers now without issue.

Reply
0 Kudos
nzsteve
Enthusiast
Enthusiast
Jump to solution

Did you remove the tick box for 'system clock uses UTC' during the installation?

Without knowing what time zone you are in I'm going to guess its UTC -5, and your system clock is actually set to localtime. You can use 'hwclock' to change the config so that it thinks that system clock is local time rather than utc - I think its hwclock --localtime, but dont have a system to check on right now.

Try these 3 commands in order:

1) hwclock --locatime

2) date 'yourdatetime' e.g. "093020252007"

3) hwclock --systohc

then reboot. Fingers crossed you're sorted.

steve

Reply
0 Kudos
bguthrie1
Contributor
Contributor
Jump to solution

Esxcfg-firewall -q

Reply
0 Kudos