☰

背景

tag-icon • tag-icon ubuntu vmware ntp ntpd
背景

我已经安装了 NTP，并且内部 NTP 服务器对等方是层 2。但是，每次重新启动服务器时，虚拟机时间都会与 ESX 主机同步，然后提前 6 小时。

我确实运行了 ntpdate -s xxxx 并更正了它。然而，重启后，时间又提前了6个小时。

为什么 NTP 不处理它？我已启用 ntp，它会在引导期间启动，但时间始终是 ESX 时间。我使用的是 Ubuntu 16.04。

另外timedatectl，不显示 NTP，但systemd.timesyncd会显示。systemd.timesyncd在虚拟机上被禁用并停止。

root@host001:~# timedatectl
                      Local time: Fri 2020-05-08 16:00:59 UTC
                  Universal time: Fri 2020-05-08 16:00:59 UTC
                        RTC time: Fri 2020-05-08 08:57:03
                       Time zone: UTC (UTC, +0000)
       System clock synchronized: no
systemd-timesyncd.service active: no
                 RTC in local TZ: no

答案1

虽然 VMWare 自己的白皮书建议在 Linux VM 安装中运行 NTP 服务器，默认情况下，VM 时间与其所在的虚拟机管理程序/主机的时间同步。

如果虚拟机管理程序的时间与实际时间存在差异，则启动时或者如果 ntpd 守护进程未运行，受影响的虚拟机管理程序中托管的虚拟机将会出现时间差异。

vSphere 文档中心 - 配置客户机和主机操作系统之间的时间同步描述VMWare默认行为：

时间同步发生后，VMware Tools 每分钟检查一次，以确定来宾操作系统和主机操作系统上的时钟是否仍然匹配。如果不是，则来宾操作系统上的时钟将同步以匹配主机上的时钟。

如果客户机操作系统上的时钟落后于主机上的时钟，VMware Tools 会将客户机上的时钟向前移动以匹配主机上的时钟。如果客户机操作系统上的时钟早于主机上的时钟，VMware Tools 会导致客户机上的时钟运行得更慢，直到时钟同步。

无论是否打开 VMware Tools 定期时间同步，时间同步都会在某些操作后发生：

  • 当 VMware Tools 守护程序启动时（例如在重新引导或开机操作期间）

  • 从挂起操作恢复虚拟机时

  • 恢复到快照后

  • 缩小磁盘后

如果实时时间、管理程序时间和 VM 时间之间出现这种差异，则应执行以下几项操作：

  • 更正时间、时区/在 VMware 主机/管理程序中启用 NTP；
  • 在VM的VMWare side/vmx文件中禁用VM/Linux和虚拟机管理程序之间的同步；

  • 无法访问虚拟机管理程序，在 VM/Linux 端，启动时禁用虚拟机与虚拟机管理程序的同步，使用虚拟机工具，因为它不竞争每时每刻，使用 NTP 守护进程设置/漂移 VM 时间：

    vmware-toolbox-cmd timesync disable

    如果您无法纠正主机/虚拟机管理程序时间，则必须禁用时间同步，当这些差异更大时，情况就更加紧迫。

再次引用自vSphere 文档中心 - 配置客户机和主机操作系统之间的时间同步

本机时间同步软件（例如网络时间协议 (NTP)...）通常比 VMware Tools 定期时间同步更准确，因此是首选。在您的来宾中仅使用一种形式的周期性时间同步。如果您使用本机时间同步软件，请关闭 VMware Tools 定期时间同步。

至于VM端的NTP服务，恩特普德如果时间差太大则中止，或者如果被告知忽略它则同步速度非常慢。

对于开机/NTP服务启动时，要立即自动更改时间，添加为ntp.conf的第一行：

tinker panic 0

也可以看看：

VMWare KB - 禁用时间同步 (1189),用于完全禁用主机和虚拟机之间的时间同步。

不同步超过 30 分钟时为 11 分钟模式更详细的解释tinker panic 0

阿登达

尽管如此，再次强调一下，如果与多学科团队合作，强烈建议纠正主机端的时间概念，并引起 VMWare 团队的注意。

一个管理程序关闭时间确实会影响该 VMWare 主机生成的日志时间戳和 VM/内务文件创建/修改时间。

虚拟机管理程序时间错误的影响可能会更加复杂，特别是在以下情况下：

  • VMWare文件所在的存储空间被多台VMWare主机共享；
  • 日志被发送到中央系统日志服务器；
  • 具有由同一 vCenter 管理的多个 VMWare 主机。

答案2

背景

在大多数计算机上，在启动时：

  • 时间是从 RTC 读取的（在计算机关闭时，RTC 一直由电池供电）。
  • 根据计算机上次关闭时文件中存储的内容，可能会添加一些调整。
  • 这就是新的“硬件时间”，也就是计算机的时间。
  • 直到某个时间客户端（sntp、ntpdate、ntpd、chronyd 等）或硬件时钟 (GPS) 将该时间更新为更好的估计。

如果由于任何原因，RTC 电池出现故障，启动时间可能会与正确时间相差很大。

回答

在虚拟计算机中，RTC不是真实的RTC而是虚拟的RTC，时间是从主机时间读取的。如果主机时间关闭，虚拟机的启动时间也会大幅关闭。就像 RTC 电池坏了一样。

这就是发生这种情况的原因（您从虚拟机复制的内容）：

root@host001:~# timedatectl
                      Local time: Fri 2020-05-08 16:00:59 UTC  
                  Universal time: Fri 2020-05-08 16:00:59 UTC  
                        RTC time: Fri 2020-05-08 08:57:03  
                       Time zone: UTC (UTC, +0000)  
       System clock synchronized: no  
systemd-timesyncd.service active: no  
                 RTC in local TZ: no

这RTC时间不同比真实的、本地的或 UTC 更准确。

解决方案

确保主机时间正确。在那里使用 ntp 或 GPS。

例如，来自 Qemu 手册页：

-rtc [base=utc|localtime|datetime][,clock=host|rt|vm][,driftfix=none|slew]

默认情况下，RTC 由主机系统时间驱动。这允许使用 RTC 作为来宾内部的准确参考时钟，特别是如果主机时间平稳地遵循准确的外部参考时钟（例如通过 NTP）。

相关：欺骗VM BIOS RTC来设置时间

相关内容