How to Configure ESX Server as NTP Client

— ny_wk

To configure NTP on a VMware ESXi host, add one or more reachable time servers, start the NTP daemon, set the policy to start with the host, and open the NTP client firewall rule — either through the vSphere Client UI or the esxcli system ntp commands. Correct NTP configuration keeps the hypervisor clock accurate so every virtual machine, log timestamp, certificate check, and Active Directory authentication on the host stays in sync.

Clock drift on a hypervisor is one of those quiet problems that causes loud failures: Kerberos tickets get rejected, TLS handshakes fail with "certificate not yet valid," backup jobs land out of order, and correlating logs across hosts becomes impossible. This guide walks through configuring an ESXi host as an NTP client the modern way, with the original vSphere Client steps included for context, plus the command-line method, common pitfalls, and how to verify time is actually synchronized.

Why a hypervisor needs accurate time

An ESXi host is the time authority for the guests that depend on it. By default many guest operating systems will (or can be configured to) periodically sync their clock with the host via VMware Tools. If the host clock is wrong, that error propagates to every VM that trusts it. Getting NTP on VMware ESXi right at the hypervisor layer is therefore the foundation of a healthy environment.

• Authentication: Kerberos (Active Directory) allows only a small clock skew, typically five minutes. Drift beyond that breaks domain logins and integrated services.
• Certificates and TLS: A host with a clock set in the past or future can reject valid certificates or, worse, accept expired ones.
• Forensics and troubleshooting: Cross-host log correlation only works when timestamps agree to the second.
• vCenter and clustering: vCenter, vSAN, and other distributed features assume consistent time across all hosts.

A quick note on ESX vs. ESXi

The original "ESX" (with the Linux-based Service Console) reached end of availability years ago; VMware ESX 4.x was the last release before the architecture was retired in favor of ESXi. If you are still running classic ESX, treat it as legacy and plan a migration. The concepts below are the same, but on modern ESXi (6.x, 7.x, 8.x) you use the HTML5 vSphere Client or esxcli rather than the old Service Console ntp.conf edits. Everything in this guide targets supported ESXi while preserving the spirit of the original UI workflow.

Before you start: prerequisites

• Reachable NTP servers. Use your organization's internal time sources where possible (they were referenced as scctime.domain.net and bcctime.domain.net in older internal docs — substitute your real hostnames), or public pools such as pool.ntp.org / time.google.com / time.cloudflare.com.
• UDP port 123 open from the host's management network to those servers. NTP uses UDP 123 in both directions.
• Working DNS on the host if you reference servers by hostname; otherwise use IP addresses.
• Administrator access to the vSphere Client or SSH/console access to run esxcli.

Method 1: Configure NTP on ESXi with the vSphere Client (UI)

This is the graphical equivalent of the classic Time Configuration workflow, updated for the current HTML5 vSphere Client. The exact label wording shifts slightly between 6.7, 7.0, and 8.0, but the flow is identical.

1. Log in to the vSphere Client (or connect directly to the host with the ESXi Host Client at https://<host-ip>/ui).
2. Select the ESXi host in the inventory, then open Configure → System → Time Configuration. (On the standalone Host Client: Manage → System → Time & date.)
3. Click Edit next to "Network Time Protocol." Choose Use Network Time Protocol (Enable NTP client).
4. In NTP servers, enter your servers separated by commas, for example time.google.com, pool.ntp.org or your internal pair scctime.domain.net, bcctime.domain.net.
5. Set the NTP Service Startup Policy to Start and stop with host so the daemon comes up automatically after a reboot.
6. Make sure the NTP Service Status is set to Start (or click Start after saving), then click OK / Save.

Saving this dialog does three things behind the scenes: it writes the server list to the host, opens the built-in NTP Client firewall rule, and starts ntpd. Older versions had a separate "Restart NTP service to apply changes" checkbox — the modern client restarts the daemon for you when you save.

Method 2: Configure NTP on ESXi from the command line

The CLI is faster for scripting across many hosts and is the most reliable way to confirm exactly what the host is doing. Connect via SSH (enable it in Configure → Services → SSH) or use the DCUI/ESXi Shell, then run the following.

Add the NTP servers

The modern, supported way is the esxcli system ntp namespace (available on ESXi 7.0 and later). Add each server, then enable the service:

1. Add one server at a time:
   esxcli system ntp set --server time.google.com
esxcli system ntp set --server pool.ntp.org
2. Enable the NTP daemon and have it persist across reboots:
   esxcli system ntp set --enabled true
3. Confirm the configuration:
   esxcli system ntp get

On older hosts (6.x) where the esxcli system ntp namespace is absent, the server list lives in /etc/ntp.conf and the daemon is managed as a service. The equivalent commands are:

1. Open the firewall rule for the NTP client:
   esxcli network firewall ruleset set --ruleset-id ntpClient --enabled true
2. Add your servers to the config (append, do not blindly overwrite an existing file):
   echo "server time.google.com" >> /etc/ntp.conf
3. Set the daemon to start with the host and start it now:
   chkconfig ntpd on
/etc/init.d/ntpd start

Important: ESXi 8.0 introduced support for chronyd and Precision Time Protocol (PTP) alongside classic ntpd. On 8.x you can manage the time source with esxcli system ntp for NTP and esxcli system ptp for PTP. For the vast majority of environments, NTP via esxcli system ntp is the correct and simplest choice.

Reference: key commands at a glance

Common pitfalls when configuring NTP on ESXi

Most "NTP isn't working" tickets come down to one of these. Check them in order before assuming a bug.

• Firewall rule not enabled. The UI opens the ntpClient ruleset for you, but a CLI-only configuration often forgets it. Without it, outbound UDP 123 is blocked and the host never reaches the server.
• Daemon configured but not started. Adding servers does not start ntpd. You must enable and start it, and set the startup policy to start with the host or it will be off after the next reboot.
• Name resolution failure. If you used hostnames and the host has no working DNS, the servers are unreachable. Test with an IP address to isolate this.
• Initial skew too large. ntpd will refuse to "step" a clock that is off by more than ~1000 seconds and instead slews very slowly. If the host is wildly wrong, stop the daemon, set the time manually with esxcli system time set, then start NTP.
• Time zone confusion. ESXi always keeps its hardware and system clock in UTC. Do not try to change the host to a local time zone — the vSphere Client converts for display. A clock that looks "off by hours" is usually just UTC being read as local.
• Asymmetric or upstream-unsynced source. If your upstream server itself is not synchronized (stratum 16), the host will never converge. Always point at a known-good, low-stratum source.
• Using only one server. Provide at least two, ideally three or four, NTP sources so the daemon can detect and reject a "falseticker" and survive one source going down.

Verification: confirm time is actually synchronized

Configuring is not the same as syncing. Always verify after a change. Give the daemon a few minutes — NTP converges gradually — then run these checks.

1. Confirm the service is running and enabled. In the vSphere Client, the Time Configuration panel should show NTP service status Running and policy Start and stop with host. From the shell: esxcli system ntp get should list your servers with enabled = true.
2. Check the peer/association status. Run ntpq -p on the ESXi shell. A working source shows a * (the selected system peer) or + (candidate) in the first column, a non-zero reach value climbing toward 377, and a small offset (milliseconds). A reach stuck at 0 means the host cannot talk to the server — revisit the firewall and DNS pitfalls above.
3. Compare host time to a trusted source. Run date -u on the host and compare it to a known-good UTC clock. They should match within a second or two.
4. Watch the offset shrink. Re-run ntpq -p over several minutes; the offset column should trend toward zero as the daemon disciplines the clock.

Once you see a selected peer (*), a rising reach, and an offset in the low milliseconds, the host is synchronized and its guests can safely trust it for time.

Best practices for time sync across a cluster

• Use the same NTP sources on every host in a cluster and on vCenter, so the entire vSphere environment shares one notion of time.
• Prefer internal NTP appliances (GPS-backed or a hardened internal pool) over the public internet for production, and allow public pools only as a fallback.
• Avoid double time sources in guests. Decide whether each VM syncs from the host (VMware Tools) or directly from NTP/Windows Time — not both — to prevent fighting clocks. Domain controllers should sync from NTP, not the host.
• Monitor drift. Alert on hosts whose NTP offset exceeds a threshold or whose daemon stops, so you catch silent drift before it breaks authentication.
• Document your sources so the next administrator knows which servers are authoritative.

Key Takeaways

• NTP configuration on ESXi has four moving parts: add servers, enable/start the daemon, set it to start with the host, and open the ntpClient firewall rule.
• The vSphere Client does all four automatically when you save the Time Configuration dialog; the CLI requires you to handle the firewall and startup policy explicitly.
• Classic ESX is end-of-life — use supported ESXi with esxcli system ntp (7.x/8.x), and consider chronyd/PTP options on 8.0.
• ESXi keeps its clock in UTC; never set it to a local time zone, and provide at least two NTP sources for resilience.
• Always verify with ntpq -p: look for a * peer, a reach climbing to 377, and an offset in the low milliseconds.

Frequently Asked Questions

How do I check if NTP is working on ESXi?

Run ntpq -p on the ESXi shell. A correctly synchronized host shows a * next to the selected server, a reach value rising toward 377, and an offset in the low milliseconds. You can also confirm in the vSphere Client under Configure → Time Configuration that the NTP service status reads "Running."

What port does ESXi use for NTP and do I need to open the firewall?

NTP uses UDP port 123. The ESXi host firewall has a built-in ntpClient ruleset that must be enabled. The vSphere Client opens it automatically when you enable NTP; from the CLI you enable it with esxcli network firewall ruleset set --ruleset-id ntpClient --enabled true.

Why is my ESXi clock still wrong after configuring NTP?

The most common causes are the daemon being configured but not started, the firewall rule not being enabled, DNS failing to resolve the server names, or an initial clock skew larger than ~1000 seconds (which ntpd refuses to step). Fix the time manually with esxcli system time set if the skew is huge, then start NTP and re-check with ntpq -p.

Should virtual machines sync time from the ESXi host or from NTP?

Pick one source per guest. Most general-purpose VMs can safely use VMware Tools host time sync, while domain controllers and time-sensitive servers should sync directly from NTP (or Windows Time) and have host time sync disabled, so the two mechanisms never fight over the clock.

If this helped you keep your hypervisors in sync, subscribe to @explorenystream on YouTube for more practical system administration and virtualization walkthroughs.