描述

Nutanix NCC 健康检查插件check_ntp验证 CVM（控制器 VM）和管理程序主机的 NTP 配置。它还会检查集群上是否存在任何时间漂移。

插件check_ntp包含多个针对特定 NTP 相关场景的单独检查：

• CVM/PCVM NTP 时间同步 - 确定 CVM/PCVM 是否能够与配置的任何 NTP 服务器同步时间
• 管理程序 NTP 时间同步（仅限 AHV + ESXi）- 确定主机是否能够与配置的任何 NTP 服务器同步时间

注意：NTP 配置检查，检查 ID 103076 在 NCC 版本 4.0.0 中已停用。

此插件也可在 Prism Central (PC) 上运行，但管理程序检查除外。

这个健康检查插件是在 NCC 3.1 版中引入的，它汇集了以前 NCC 版本中的所有 NTP 检查。在 Prism Central 上，此检查是在 NCC 版本 3.5.3 中引入的。 NCC 3.6.2 中引入了这些检查的警报功能。

可能的原因

如果此健康检查返回非 PASS 结果，则可能有以下原因：

• 集群上没有配置 NTP 服务器。
• 管理程序上没有配置 NTP 服务器。
• hypervisor配置的全部或部分NTP服务器与云服务器或PC虚拟机配置的不同。
• 配置的 NTP 服务器不可访问或不响应 NTP 查询。
• 配置的 NTP 服务器不可靠或不稳定。
• NTP 服务器配置了主机名，但由于 DNS/名称解析问题无法解析。
• NTP 端口 (UDP/123) 未打开。
• 与 NTP 服务器上的实际时间相比，集群上的时间不同步，并且发现未来至少 5 秒。
• NTP服务器正在传递CVM或PC VM的NTP客户端认为不适合NTP同步的参数，例如高分散值、偏移量、抖动、范围或层。
• 默认情况下，使用本地时钟作为时间源的基于Windows的 NTP 服务器 (AD PDC) 将通过在该服务器的 NTP 参数中包含 10 秒的分散值来将自己宣传为不太合适的 NTP 源。 W32time 的设计不符合 NTP 所需的精度，并且不保证优于 +/- 5 分钟的容差。
• genesis 服务最近重启了，NTP 同步还在等待中，或者如果 NTP 配置已经改变，效果可能需要一些时间。根据 NTP 协议，NTP 服务器被接受为同步源大约需要 5 分钟（5 个好的样本）。等待并在 10-15 分钟后重新运行检查可能会产生不同的结果，如果这为更改生效和同步提供了足够的时间。

  比如重启genesis后，ntpq命令显示时间还在和.LOCL同步。

然后，等待 10-15 分钟后，ntpq 命令现在显示：

因此，立即重新运行检查将失败，但在一段时间后重新运行它，比如 10-15 分钟，应该通过。

症状及影响

如果此健康检查返回非 PASS 结果，则集群操作可能面临各种症状/影响的风险，例如：

• 用户无法使用 LDAP 或其他目录集成服务登录到 Prism Web 控制台。
• 由于中断或维护后的主要时间偏差，集群无法启动或正常运行。
• 不准确的日志记录和日志收集。
• 不准确的健康检查结果依赖于准确的时间范围和事件关联。
• Prism 中的不正确和倾斜的图表。
• 用户虚拟机在具有不准确 RTC（实时时钟）的管理程序主机上启动，导致来宾操作系统时间偏差。
• Veeam 或 Commvault 等第三方备份软件产品在与集群交互时遇到问题。
• 当集群和远程站点之间的时间不同步时，快照过期过早或过晚

运行 NCC 检查

作为完整的 NCC 健康检查的一部分运行此检查：

或者单独运行此检查：

您还可以从 Prism Web 控制台运行状况页面运行检查：选择操作 > 运行检查。选择所有检查并单击运行。

示例输出

对于状态： INFO

对于状态：失败

对于状态： ERR

从 NCC-4.0.0 开始的状态： WARN

输出消息

注意：检查 ID 103076 在 NCC 4.0.0 版中已停用。

解决方案

对于运行 ESXi 7.0.3 build 19193900 的集群，即使主机和 Prism UI 上配置的 NTP 服务器相同，检查也会给出误报。

请升级到 NCC-4.5.0.1 以减少误报。

一般故障排除步骤

如果此检查返回非通过结果，请检查以下内容：

• 在集群（CVM/PCVM）和主机（管理程序 - AHV、ESXi、Hyper-V、XenServer）上配置至少一个，但最好是三个或更多可靠的集群外 NTP 服务器。
  • 要在 CVM 和 AHV 上配置 NTP 服务器，请参阅Prism Web 控制台指南中的配置 NTP 服务器。 （通过 Prism 配置 NTP 服务器将同时更新 CVM 和 AHV 主机）。
  • 要在 ESXi 主机上配置 NTP 服务器，请参见Configuring Network Time Protocol (NTP) on ESX/ESXi hosts using the vSphere Client (2012069) 。
  • 要在 Hyper-V 主机上配置 NTP 服务器，请参阅下面的在 Hyper-V 上配置 NTP 。
  • 有关使用哪些 NTP 服务器的建议，请参阅时间同步建议。
• Hypervisor 上配置的 NTP 服务器列表最好与 CVM 上配置的相同。
• 如果使用 FQDN 或主机名设置 NTP 服务器，请确保集群可以针对所有已配置的 DNS 名称服务器解析 NTP FQDN 的 IP 地址。 Prism 中无效的名称服务器配置可能会阻止使用 NTP 服务器并导致时间同步问题。
• NTP 协议目标端口 (UDP 123) 通过所有 CVM/主机与 NTP 服务器之间的网络路径中的任何 ACL/防火墙向目标 NTP 服务器开放。
• 尝试使用 FQDN 和 IP 地址 ping NTP 服务器以建立基本的网络连接。请注意，某些 ACL/防火墙可能会故意阻止 ping（ICMP 回显）流量，但仍允许 UDP/123，因此请考虑无法访问的结果不一定是根本原因，而是可能深入了解网络连接问题。使用下一步进一步验证。
• 无论通过网络 ping 是否可访问 NTP 服务器，请确保其健康并在应用程序层响应有效且可用的 NTP 查询，并返回准确的时间信息。您可以通过运行以下命令来验证 NTP 查询是否返回时间信息：
  nutanix@cvm$ /usr/sbin/ntpdate -t 10 -q
• 使用下面检查“ntpq -pn”命令的输出过程检查所有 CVM 和主机上的 NTP 同步状态。
• 使用下面检查 ntp.conf 文件内容的过程检查所有主机上的 NTP 配置。
• 如果时间尚未与新的/更新的 NTP 配置同步，则在配置 NTP 后，此检查可能会产生非通过结果。如果最近刚刚添加了 NTP 服务器，并且 CVM 时间不被认为是未来时间（NTP 服务器的负偏移），则可能会触发此检查，直到 NTP 协议找到稳定且合适的 NTP 源并且 CVM 已经成功同步（约 10 分钟）。
• 如果配置的 NTP 服务器本身不是可靠的 stratum 0 源（GPS/原子钟），则它们必须配置合适的 stratum（0-3 是好的）外部时间源，并且不应与本地时钟同步该服务器或内部时间源。

笔记：

• 众所周知，将 Nutanix AOS/PC 集群与基于Windows的时间源同步会在一段时间内引起问题。请参阅知识库文章 3851 对Windows时间服务器的 NTP 同步进行故障排除。
  Nutanix 建议您不要将集群的时间与Windows时间源同步。请改用可靠的非Windows时间源。请参阅Prism Web 控制台指南中的时间同步建议。
• 如果实际的 NTP 服务器是在同一集群上作为访客运行的用户虚拟机，请不要将 NTP 服务器用作 Nutanix 集群和/或管理程序的源！这是不可靠的，在用户 VM 和集群中断和重启时不可预测，因此不推荐。
• 您无需在 AHV 主机上手动配置 NTP 服务器。通过 Prism/ncli 配置 NTP 服务器将同时更新 CVM 和 AHV 主机。
• 使用 Prism Web 控制台或 ncli 在基于 ESXi 的 AOS 集群上添加 NTP 服务器时，NTP 服务器不会自动添加到主机的 /etc/ntp.conf 文件中。在 Prism 中添加 NTP 服务器后，您还必须在 ESXi 主机上手动配置这些 NTP 服务器。有关在 ESXi 主机上配置 NTP 服务器的详细信息，请参见Configuring Network Time Protocol (NTP) on ESX/ESXi hosts using the vSphere Client (2012069) 。
• 在混合管理程序集群 (AHV + ESXi) 中，如上所述，AHV 主机将通过 Prism 配置，但您必须在混合管理程序集群的 ESXi 主机上手动配置 NTP 服务器。
• 在 Hyper-V 集群上，check_ntp 插件仅验证 CVM NTP 配置。它不检查Windows Hyper-V 主机的 NTP 或时间配置，因此如果管理程序配置错误或与 NTP 源和/或 AD PDC 不同步，检查不会导致失败状态。手动确认 Hyper-V 主机和域控制器具有健康的Windows时间层次结构。 AD PDC(s) 应该使用与 CVM 并行的可靠上游 NTP 时间源，可能是相同的 NTP 服务器（见下一点）。
• 理想情况下，为了简化日志比较并避免复杂的时间同步问题分类，管理程序和控制器 VM 都应该使用相同的 NTP 服务器。如果虚拟机管理程序和控制器 VM 使用不同的 NTP 服务器，此运行状况检查可能会生成 INFO 输出以提高认识并确保这是有意识且合理的配置，而不是意外的错误配置，并在任何其他不相关的故障排除过程中快速强调这一事实事件应该在集群生产期间随时发生。

有关 Nutanix 集群时间同步的更多信息和最佳实践，请参阅Nutanix 支持门户网站上Prism Web 控制台指南中的集群时间同步。

具体故障排除步骤

• 如果检查报告“信息：在管理程序 xxxx 上配置的 NTP 服务器与 Zeus config xxxx 中配置的不同”，请在集群和管理程序上配置相同的 NTP 服务器。
• 如果检查报告“FAIL：NTP leader 未同步到任何外部 NTP 服务器，因为集群的时间相对于外部 NTP 服务器是未来的：xxxx”，集群可能在没有有效 NTP 同步状态和拉取的情况下启动CVM 时间倒退可能会影响正在运行的存储元数据操作。要解决未来 CVM 时间的这一特殊问题，请向Nutanix 支持部门记录案例以获得进一步帮助，并且不要手动更改任何 CVM 日期/时间。
• 如果检查报告“失败：NTP 领导者未与任何外部 NTP 服务器同步”，请按照上述一般故障排除步骤进行操作。如果上述步骤无法解决问题，请向Nutanix 支持记录案例，提供一般故障排除和当前集群 NTP 配置的结果和任何输出。
• 如果检查报告“失败：管理程序未与任何 NTP 服务器同步”，请按照上述一般故障排除步骤进行操作。如果上述步骤不能解决问题，请按照以下步骤操作：
  1. 在主机上，使用下面概述的重新启动ntpd服务过程重新启动 ntpd 服务。
  2. 使用下面检查“ntpq -pn”命令的输出过程检查主机现在是否正在与 NTP 同步时间。请务必等待约 10 分钟进行同步。
  3. 如果并非所有主机都正确同步，请按照下面的检查 ntp.conf 文件的内容过程进行操作。
  4. 如果问题仍未解决，请考虑联系 Nutanix 支持，提供结果，以及一般故障排除和当前集群 NTP 配置的任何输出。
• 如果检查报告“失败：此 CVM 是 NTP 领导者但未与任何外部 NTP 服务器同步时间”并且您已验证 NTP 服务器已设置：
  1. 配置的 NTP 服务器可能不堪重负和/或有意限制 NTP 客户端请求的数量以响应以保护自己免受 DDoS（意外或其他原因），因此不会响应 CVM NTP 领导者的有效 NTP 请求。您可以通过检查 CVM 创世服务日志文件中包含“来自服务器的速率限制响应”的错误行条目来调查您的 NTP 服务器是否对请求进行速率限制：
     nutanix@cvm$ allssh “grep -A 1 -i '速率限制' ~/data/logs/genesis.out | tail”
     ...
     2018-12-12 11:03:14 错误 node_manager.py:3941 使用 ntpdate 的系统时间更新失败，出现错误：1：12 月 12 日 11:03:14 ntpdate[26695]：来自服务器的 nnn101 速率限制响应。
     2018-12-12 11:03:14 ntpdate[26695]: 找不到适合同步的服务器
     1. 如果您不控制受影响的 NTP 服务器，则将其从 Prism 的 NTP 配置中删除并添加一个不同的、更可靠的 NTP 服务器。
     2. 如果您控制源 NTP 服务器配置，请考虑为 CVM/主机 IP 添加限制例外。有关详细信息，请参阅 NTP 服务器自己的文档。例如，在基于 Linux 的 ntpd 服务上，需要将以下行添加到 NTP 服务器的/etc/ntp.conf文件中，然后重新加载：
        严格 面具
  2. CVM 时间可能早于 NTP 服务器时间，CVM 的创世服务会故意阻止 NTP 同步。通过运行以下命令并查找 CVM 和 NTP 源之间的负偏移，可以在受影响的 CVM 的创世日志中进一步证明这一点：
     nutanix@cvm$ allssh “grep -i ntp /home/nutanix/data/logs/genesis.out | tail”
     示例输出：
     2019-02-03 22:42:11 INFO node_manager.py:2314 查询上游 NTP 服务器：10.xx11
     2019-02-03 22:42:12 INFO node_manager.py:2334 NTP 偏移量：-89.328 秒
     2019-02-03 22:42:12 INFO node_manager.py:2354 时间比外部 NTP 服务器提前 89.328 秒，集群服务运行时不同步时间
     2019-02-03 22:42:12 INFO node_manager.py:2230 重新启动 NTP 服务器。
     2019-02-03 23:02:13 错误 node_manager.py:2450 外部 NTP 仍然无法使用 (0)
     2019-02-03 23:02:13 警告 node_manager.py:2456 禁用上游 NTP 服务器
     2019-02-03 23:02:13 信息 node_manager.py:2202 停止 NTP 服务器。
     2019-02-03 23:02:13 信息 node_manager.py:2230 重新启动 NTP 服务器。
     2019-02-03 23:12:13 INFO node_manager.py:2314 查询上游 NTP 服务器：10.xx11
     2019-02-03 23:12:13 INFO node_manager.py:2334 NTP 偏移量：-89.297 秒
     
     在上面的示例输出中，集群未与新添加的 NTP 服务器同步。在这种情况下，NTP 服务器的运行时间比 CVM 晚 89 秒，因此被视为不可用作 NTP 源。
     重要提示：如果 CVM 时间是未来时间，请勿手动将时钟向后设置！联系Nutanix 支持寻求帮助并提供以上输出。
• 如果检查报告“ERR: Failed to run ntpq on the host”：在每个云服务器上运行以下命令并确保命令运行成功。
  nutanix@cvm$ ntpq -pn

  如果命令运行失败或者NCC检查再次报ERR状态，请排查CVM是否有空闲内存。向Nutanix 支持部门记录一个案例以获得进一步的帮助。

查看“ ntpq -pn ”命令的输出

命令' ntpq -pn '是本次检查的主要命令，用于识别CVM或主机的NTP同步状态。

结果的每一行将采用以下格式：（仅示例输出。实际 IP、NTP 服务器行和相关值将根据个人配置而有所不同）

其中remote是要同步到的远程对等方或服务器。 “127.127.1.0 LOCL”是这个本地主机（包括在没有远程对等点或服务器可用的情况下）。

表中显示的第一个字符是州旗。同步状态，由“*”表示为一个远程 NTP 服务器条目的第一个字符，是预期的。

注意：如果最近更改了具有 NTP 领导者角色的创世服务或修改了 NTP 服务器配置，则需要 10-15 分钟才能出现此同步状态。

1. 要检查所有 CVM 上的 NTP 状态，请从一个 CVM 运行以下命令：
   nutanix@cvm$ allssh ntpq -pn
   以下示例是一个很好的结果 - 显示 CVM NTP 领导者与外部 NTP 服务器同步，其他 CVM 与 CVM NTP 领导者同步。
   ================== 10.xx.xx.61 =================
   remote refid st t when poll reach delay offset 抖动
   ================================================ ============================
   +10.xxx.xxx.21 10.xx.xx.15 4 u 654 1024 377 0.812 -1.026 0.429
   +10.xxx.xxx.22 10.xx.xx.15 4 u 997 1024 377 0.830 -0.998 0.533
   +10.xxx.xxx.10 10.xx.xx.15 4 u 409 1024 377 1.365 -1.159 5.158
   *10.xxx.xxx.11 10.xx.xx.15 4 u 579 1024 377 1.626 -1.055 0.326 <--- 与已配置的 NTP 服务器同步 10.xx.xx.11
   127.127.1.0.LOCL。 10 升 27 小时 64 0 0.000 0.000 0.000
   ================== 10.xx.xx.62 =================
   remote refid st t when poll reach delay offset 抖动
   ================================================ ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0.353 2.584 1.355 <--- 与 CVM NTP leader 10.xx.xx.61 同步
   ================== 10.xx.xx.63 =================
   remote refid st t when poll reach delay offset 抖动
   ================================================ ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0.192 1.775 1.682 <--- 与 CVM NTP leader 10.xx.xx.61 同步
   
   下面是一个有问题的结果的例子。 CVM NTP 领导者仅与其本地时钟同步：
   ================== 10.xx.xx.61 =================
   remote refid st t when poll reach delay offset 抖动
   ================================================ ============================
   127.127.1.0.LOCL。 10 l 27h 64 0 0.000 0.000 0.000 <--- CVM NTP 领导者仅与其本地时钟同步
   ================== 10.xx.xx.62 =================
   remote refid st t when poll reach delay offset 抖动
   ================================================ ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0.353 2.584 1.355 <--- 与 CVM NTP leader 10.xx.xx.61 同步
   ================== 10.xx.xx.63 =================
   remote refid st t when poll reach delay offset 抖动
   ================================================ ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0.192 1.775 1.682 <--- 与 CVM NTP leader 10.xx.xx.61 同步
   
   如果正在使用 IP“127.127.1.0”，则表示 CVM 仅与 NTP 领导者同步（“127.127.1.0”是本地主机 IP），并且在检查时未与任何外部 NTP 服务器同步执行。
2. 要检查所有主机/管理程序上的 NTP 状态，请从一个 CVM 运行以下命令：
   nutanix@cvm$ 主机sh ntpq -pn
   
   下面的例子是一个很好的结果。所有主机都与相同的 NTP 服务器同步。
   ============= 192.xx.xx.1 ============
   remote refid st t when poll reach delay offset 抖动
   ================================================ ============================
   *10.xx.xx.15 218.1xx.xx.70 2 u 822 1024 377 96.679 12.968 3.105
   10.xx.xx.16.初始化。 16 u - 1024 0 0.000 0.000 0.000
   +10.xx.xx.21 203.xx.xx.251 3 u 27 1024 377 0.609 -23.479 4.167
   ============= 192.xx.xx2 ============
   remote refid st t when poll reach delay offset 抖动
   ================================================ ============================
   *10.xx.xx.15 218.xx.xx.70 2u 8 1024 157 2.513 3.510 2.980
   10.xx.xx.16.初始化。 16 u - 1024 0 0.000 0.000 0.000
   +10.xx.xx.21 203.xx.xx.251 3 u 253 1024 377 0.665 -8.794 5.203
   ============= 192.xx.xx.3 ============
   remote refid st t when poll reach delay offset 抖动
   ================================================ ============================
   *10.xx.xx.15 218.xx.xx.70 2 u 184 1024 377 96.566 17.003 4.010
   10.xx.xx.16.初始化。 16 u - 1024 0 0.000 0.000 0.000
   +10.xx.xx.21 203.xx.xx.251 3 u 394 1024 377 0.659 -18.181 5.601
   如果所有主机的 NTP IP 地址不一致，请检查/etc/ntp.conf以了解它们是否使用代表 NTP 服务器池的主机名/FQDN。 NTP 池由许多循环 DNS 条目组成，因此在初始化时，在启动 NTP 服务时给予每个主机的 DNS 响应可能会返回不同的 IP 地址以用作 NTP 服务器。
3. 如果您在运行ntpq时在 AHV 主机上看到以下消息：
   没有返回关联 ID
   
   通过运行以下命令确认您是否正在运行 AHV el6 内核：
   nutanix@cvm$ ssh root@192.168.5.1
   [root@ahv]# cat /etc/nutanix-release
   
   如果您在 el6 内核上运行，您将看到类似于以下的输出：
   el6.nutanix.20170830.151
   要暂时解决此问题（解决方法），请在主机上使用下面的重新启动ntpd服务过程重新启动 ntpd 服务，然后重新运行此 NCC 检查以进行确认。

   要永久解决此问题，请将 AOS 升级到 5.5.8、5.9.2、5.10 或更高版本。

4. 如果您在运行ntpq时在 ESXi 主机上看到以下消息，则表示 ESXi/ESX 主机无法访问配置的 NTP 服务器：
   没有返回关联 ID
   使用hostssh date命令确认所有主机上的时间正确且相同。

   使用/etc/ntp.conf 确认在主机上配置了 NTP 服务器 IP。

   使用以下命令确认主机上的 DNS 服务器配置是否正确：

   nutanix@cvm$ ssh root@192.168.5.1 esxcli network ip dns server list >>> 检查单个主机
   nutanix@cvm$ hostssh "esxcli network ip dns server list" >>> 检查所有主机
   
   要解决此问题，请使用以下命令更正 DNS 服务器配置。或者，在中心添加正确的 DNS 配置：
   [root@Esxi:~]esxcli network ip dns server add --server=
5. 如果您在运行ntpq时在 AHV 主机上看到以下消息：
   名称或服务未知
   此问题可能是由于ntpq命令无法将“localhost”解析为 127.0.0.1 而引起的。

   要解决此问题，请向Nutanix 支持记录一个案例，提供一般故障排除和当前主机 NTP 配置的结果和任何输出。

6. 在 PCVM 上运行ntpq -pn时，您可能会看到以下类型的输出：
   nutanix@PCVM:~$ ntpq -pn
   remote refid st t when poll reach delay offset 抖动
   ================================================ ============================
   x10.48.147.26.GNSS。 1 30 64 377 0.910 -4549.1 22.565
   x10.65.140.26.GNSS。 1 58 64 377 0.251 -4527.7 15.504
   *127.127.1.0 .LOCL。 10升 29 64 277 0.000 0.000 0.000
   nutanix@NTNX-10-66-154-101-A-PCVM:~$
   有关ntpq命令的更多信息，请参阅ntpq 手册页。

查看 ntp.conf 文件的内容

1. 使用上述过程查看ntpq -pn命令的输出。
2. 如果并非所有 AHV 或 ESXi 主机都与 NTP 同步时间，请检查所有主机的/etc/ntp.conf文件。

   下面是一个示例输出，其中 3 个主机中只有 2 个成功地与 NTP 同步。

   nutanix@cvm$ hostssh cat /etc/ntp.conf
   ============= 10.xx.xx.1 ============
   限制默认 kod nomodify notrap nopeer noquery
   限制 127.0.0.1
   服务器 10.xx.xx.8
   漂移文件 /etc/ntp.drift
   ============= 10.xx.xx.2 ============
   限制默认 kod nomodify notrap nopeer noquery
   限制 127.0.0.1
   服务器 10.xx.xx.8
   漂移文件 /etc/ntp.drift
   ============= 10.xx.xx.3 ============
   修补匠恐慌 0
   服务器 10.xx.xx.8
   漂移文件/var/lib/ntp/漂移
   日志文件 /var/log/ntp.log
   限制 10.8.xx 掩码 255.255.255.0 nomodify notrap
   接口忽略通配符
   接口监听 br0
   限制 127.0.0.1
   限制 -6 :: 1
   限制默认 kod nomodify notrap nopeer noquery
   restrict -6 默认kod nomodify notrap nopeer noquery
   禁用监视器
   在上面的示例配置中，主机 10.xx.xx.1 和 10.1xx.xx.2 成功与 NTP 同步，而 10.xx.xx.3 失败，因为它限制了 NTP 同步
3. 要解决此问题，请按照上面的一般故障排除步骤进行操作。请注意，AHV 主机也通过 Prism 与 CVM 一起配置。
4. 如果出现瞬态上游 NTP 或连接问题，请使用以下过程重新启动 ntpd 服务。
5. 等待 5-10 分钟，然后从其中一个 CVM 运行以下命令以检查所有虚拟机管理程序现在是否正在与 NTP 服务器同步：
   nutanix@cvm$ 主机sh ntpq -pn
6. 再次运行 NCC 检查。
7. 如果上述步骤未能解决问题，请向Nutanix 支持记录案例，提供一般故障排除和当前集群 NTP 配置的结果和任何输出。

   注意：在 ESXi 上，已知/etc/ntp.conf中列出的“ interface listen br0 ”会导致上述问题。应删除该行并重新启动 ntpd 服务。

重新启动 ntpd/w32time 服务

在 AHV el6 或 ESXi 上，运行：

在 AHV el7 上运行：

要检查安装的 AHV 版本是否属于 el6 或 el7 系列，请使用以下命令：

 [root@AHV]# uname -r
4.19.84-2.el7.nutanix.20190916.410.x86_64

在 Hyper-V 上，运行：

在 Hyper-V 上配置 NTP

Hyper-V 2016 主机使用域控制器作为 NTP。要在 Active Directory 域控制器上配置外部 NTP 源：

1. 在具有管理权限的 DC 上打开命令提示符。
2. 停止时间服务：
   C:\> 净停止 w32time
3. 设置手动对等列表外部服务器：
   C:\> w32tm /config /syncfromflags:manual /manualpeerlist:” ”
4. 将连接设置为可靠：
   C:\> w32tm /config /reliable:yes
5. 启动时间服务备份：
   C:\> 网络启动 w32time
6. 测试配置：
   C:\> w32tm /query /configuration 和 w32tm /query /status

附加信息

• Nutanix KB 4519 - Nutanix 门户中的原始文档