To state the obvious; In every environment you should have configured NTP! That said; I recently stumbled upon a nice feature of the NTPD daemon which is widely used in Linux (ESXi/Photon).

At my current assignment there is a massive upgrade throughout the entire network/infrastructure. One part of this upgrade is replacing the NTP servers. As a good and decent sysadmin I entered DNS names throughout the entire environment instead of using IP addresses.

But here comes te tricky part. They implemented a new NTP servers and changes de DNS names to the new NTP server. Because i used DNS names everywhere I thought i could sit back and relax. But after a few days the firewall admin came knocking on my door because i was still querying the old NTP adressen.

ESXi

If you log in with root on an ESXi server you can see with ntpq -p the current status of NTP

[root@secret:~] ntpq -p
     remote       refid      st t when poll reach   delay   offset  jitter
==============================================================================
ntp0..nl.        .INIT.      16 u    - 1024    0    0.000   +0.000   0.000
ntp1..nl.        .INIT.      16 u    - 1024    0    0.000   +0.000   0.000

So as you can see it clearly states the correct dns name, but the status is .init. which mean that no time is recieved. My first guess is that there is some kind of (DNS) caching mechanism in the NTPD daemon so I tried to restart the NTP daemon

[root@secret:~] /etc/init.d/ntpd restart
Stopping ntpd
watchdog-ntpd[25942238]: Terminating watchdog process with PID 17040615
Starting ntpd

[root@secret:~] ntpq -p
     remote     refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp0..nl.     .INIT.      16 u    -   64    0    0.000   +0.000   0.000
 ntp1..nl.     10..189     2 u    1   64    1    1.819   -0.010   0.000
[root@secret:~] ntpq -p
     remote    refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp0..nl.    10..189     2 u    1   64    1    1.660   +0.100   0.000
 ntp1..nl.    10..189     2 u    3   64    1    1.819   -0.010   0.000

As you can see after the restart it takes a few moments but the then the refID contains the IP adres which the NTP server sync to en de stratum changes to 2 (This means it get’s the time out of second hand)

So for as far ESX concerns ‘m not gonna login on alle ESX host to restart the daemon. So a simple POwercli script did the trick

$allVMhost = Get-VMHost

foreach ($vmhost in $allVMhost){

$ntp = Get-VMHostService -vmhost $vmhost| ? {$_.Key -eq 'ntpd'}
Restart-VMHostService $ntp -confirm:$false
Write-Host "$ntp Service on $vmhost was restarted"
}

NSX

The same logic from above applies to NSX (it’s all the NTP daemon). I only have 3 NSX Managers and 4 Edges i decided to reboot the NTP daemon via SSH.

..-nsx-m-02> restart service ntp
..-nsx-m-02> st en
Password:
***************************************************************************
NOTICE TO USERS
 
WARNING! Changes made to NSX Data Center while logged in as the root user
can cause system failure and potentially impact your network. Please be
advised that changes made to the system as the root user must only be made
under the guidance of VMware.
***************************************************************************
[email protected]:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp0..nl.           10..189     2 u    4   64    1    0.293   -0.293   0.206
 ntp1..nl.           10..173     2 u    4   64    1    0.261   -0.316   0.310

But if you have a large environment you can use restAPI to reset the NTP daemon

The original article was posted on: www.ruudharreman.nl

Related articles

  • Cloud Native
  • Implementation and Adoption
  • Platform Engineering
  • Digital Workspace
  • Hybrid Cloud
  • ITTS (IT Transformation Services)
  • Managed Security Operations
  • Managed Cloud Platform
  • Backup & Disaster Recovery
Visit our knowledge hub
Visit our knowledge hub
Ruud Harreman Virtualization Consultant

Let's talk!

Knowledge is key for our existence. This knowledge we use for disruptive innovation and changing organizations. Are you ready for change?

"*" indicates required fields

First name*
Last name*
Hidden