DOM0 has NTP running and its time is correct. We are using north-amaerica.pool.ntp.org as the time server. However, CDOM and the CM both have the wrong time by 15 minutes. When I log into the CM web interface as admin and navigate to date/time I see the wrong time, but the correct time server. How does CDOM and the CM get their time for DOM0? Have any of you seen this before? Thank you.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
CM 6 Time sync issue 1
- Thread starter FrankG77
- Start date
phoneguy55
Programmer
Are you sure you can get to the internet from your servers? I would goto cdom, server management, date/time configuration. Then query state. That might point you in the right direction. Also a reboot never hurt. lastly you may want to check the PSN's for your load of system platform. There have been some known issues with time.
-
1
- #3
That's odd. I'd say set the time manually on each and reboot.
Generally with virtualization you want to have the hypervisor - dom0 in this case - NTP syncd and the virtual machines either defer to the hypervisor or use NTP themselves but not both to avoid having two things slapping the clock ahead/back microseconds.
Just because you're connected to NTP doesn't mean you're syncing off it.
Here's my dom0. The * means I'm using the first one and st1=stratum 1, literally the atomic clock. Stratum 2 is a clock that gets its time from a stratum 1 and so on. What's the stratum? If your NTP client doesn't consider it to be reliable enough, it won't use it.
The refid is also very important. It's where that NTP server you connected to got his time from. Normally an IP, but in my case, GPS based on rotation of the earth or something. If the refid is the same IP as 'remote', then that means you have a NTP server who sets his own time and provides it to you. Your Linux OS will look at that and say "well, how reliable can this guy be? he only sets his time himself. Me on my own am just as reliable trusting myself as this other server who only trusts himself. I'll poll the time from him every so often, but I'm not going to use it to set my clock for anything"
NTP is very detailed
Generally with virtualization you want to have the hypervisor - dom0 in this case - NTP syncd and the virtual machines either defer to the hypervisor or use NTP themselves but not both to avoid having two things slapping the clock ahead/back microseconds.
Just because you're connected to NTP doesn't mean you're syncing off it.
Here's my dom0. The * means I'm using the first one and st1=stratum 1, literally the atomic clock. Stratum 2 is a clock that gets its time from a stratum 1 and so on. What's the stratum? If your NTP client doesn't consider it to be reliable enough, it won't use it.
The refid is also very important. It's where that NTP server you connected to got his time from. Normally an IP, but in my case, GPS based on rotation of the earth or something. If the refid is the same IP as 'remote', then that means you have a NTP server who sets his own time and provides it to you. Your Linux OS will look at that and say "well, how reliable can this guy be? he only sets his time himself. Me on my own am just as reliable trusting myself as this other server who only trusts himself. I'll poll the time from him every so often, but I'm not going to use it to set my clock for anything"
NTP is very detailed
Code:
[root@dom001 ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*100.200.30.4 .GPS. 1 u 18 1024 377 4.940 -0.360 0.046
+101.200.30.4 .GPS. 1 u 4 1024 377 2.357 -0.052 0.167- Thread starter
- #5
Thanks for the replies. I have not done any updates to it in a long time and need to. I am currently at R016x.03.0.141.0.
[admin@cmdoma ~]$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*a1.pcloud.com .INIT. 16 u 469 1024 0 47.187 3.158 0.000
Here is the tail end of the ntp.conf file:
# Specify the key identifier to use with the ntpq utility.
#controlkey 8
server north-america.pool.ntp.org
[admin@cmdoma etc]$
It is interesting, the time on dom0 is right on, but if NTP was working, shouldn't I see a value other than 0 for the reach?
[admin@cmdoma ~]$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*a1.pcloud.com .INIT. 16 u 469 1024 0 47.187 3.158 0.000
Here is the tail end of the ntp.conf file:
# Specify the key identifier to use with the ntpq utility.
#controlkey 8
server north-america.pool.ntp.org
[admin@cmdoma etc]$
It is interesting, the time on dom0 is right on, but if NTP was working, shouldn't I see a value other than 0 for the reach?
- Status
Similar threads
- Locked
- Question