vmwarevcenter7.0显示时间不对

VMware虚拟机时间总是异常？简单两步彻底解决此问题
系统时间问题看似很⼩，但是对于⼀些时效性要求较⾼的业务系统，例如：考试系统、实时监
控系统等，时间问题影响甚⼤。我们在实际⽣产中也遇到⼀台虚拟机安装的Windows Server系
统（ *** 作系统时间同步NTP，未配置同步主机）由于系统时间异常导致应⽤服务出现问题。
*** 作系统时间同步
Windows：Windows *** 作系统直接把CMOS时间认定为当前显⽰时间，不根据时区转换。这样
每调整⼀次系统时区，系统会根据调整的时区来计算当前时间，确定后，也就同时修改了
CMOS内的时间。
Linux：Linux和苹果 *** 作系统以当前主板CMOS内时间做为格林威治标准时间，再根据系统设置
的时区来最终确定当前系统时间。
为什么虚拟机会有波动？
计时器中断
虚拟机与主机 *** 作系统共享底层硬件，正在运⾏的虚拟机，有时也会延迟交付虚拟计时器中
断。虚拟机只在某些特定的时刻检查挂起的虚拟计时器中断，⽐如底层硬件接收到物理计时器
中断时，让虚拟机在精确指定的时间内，去请求物理计时器中断。
因为客户 *** 作系统通过计算中断来保持时间，所以当存在计时器中断积压时，由客户 *** 作系统
测量的时间就会落后于实时时间。
VMware虚拟机如何处理计时器中断？
VMware虚拟机通过跟踪当前计时器中断待办事项列表来处理这个问题，并在待办事项列表过⼤
时以更⾼的速度交付计时器中断，以便赶上进度。
如果虚拟机运⾏得太慢，可能是由于与主机上运⾏的其他虚拟机或进程争夺CPU时间的结果，
则不能为虚拟机提供⾜够的时间跟上进度。
发⽣这种情况后，如果客户 *** 作系统安装了VMware Tools并且时钟同步功能启⽤状态，VMware
Tools会在客户 *** 作系统未来的某个时候，通过同步客户 *** 作系统与主机的时钟校正时间。VMware vSphere虚拟化环境时间配置点
ESXi主机时间
主机时间配置分为两种：⼿动配置、同步NTP服务器
主机时间配置
虚拟机时间配置
虚拟机时间配置：同步主机时间（注：必须安装VMware Tools）
虚拟机时间配置-同步主机时间
虚拟机 *** 作系统时间
Windows和Linux时间配置同样分为：VMware Tools定期时钟同步、⼿动配置、同步⽹络时
间。⼀般是Microsoft W32Time for Windows和NTP for Linux，通常⽐ VMware Tools 周期性时
间同步更准确。
通常，在我们交付虚拟机时，最好⼀次只使⽤⼀个时钟同步服务，以确保避免多个服务对时钟
进⾏更改造成冲突的问题。
虚拟机时间在什么时候会发⽣变动？
初始化时间
VMware虚拟机提供了与物理机器类似的机制：⼀个虚拟电池⽀持的CMOS时钟和虚拟⽹卡，可以⽤来从⽹络时间服务器获取时间。另外还提供了⼀种机制:VMware Tools在启动时重置客户 *** 作系统的时钟，以匹配主机的时钟。客户机和主机之间的接⼝使⽤UTC(协调世界时，也称为格林威治标准时间或GMT)，因此客户机和主机不必在同⼀时区。
注：UTC的偏移量与虚拟机的CMOS⾮易失性内存的其他内容⼀起存储在虚拟机的nvram⽂件中的。
虚拟机管理 *** 作
当虚拟机停⽌⼀段时间并继续运⾏时，客户 *** 作系统的时钟通常会落后于实际时间——特别是在挂起并恢复、快照和还原为快照或VMotion *** 作之后。因此，如果在客户 *** 作系统中安装了VMware Tools, VMware Tools守护进程将在这些事件发⽣后，即时关闭了定期的时间同步也会纠正客户 *** 作系统时钟。
VMware Tools周期同步
执⾏时间同步之后，VMware Tools 会每分钟检查⼀次，以确定客户机和主机 *** 作系统上的时钟是否仍然匹配。如果不匹配，则将同步客户机 *** 作系统上的时钟以与主机上的时钟匹配。
如何禁⽤虚拟机时间同步？
即使未打开周期性时间同步，虚拟机有时也会与主机同步时间。若要完全禁⽤时间同步，必须编辑虚拟机的配置⽂件（vmx ⽂件），并将某些同步属性设置为 FALSE。
toolssyncTime = 'FALSE' 是否定期同步
timesynchronizecontinue = 'FALSE' 是否快照后同步
timesynchronizerestore = 'FALSE' 是否快照恢复后同步
timesynchronizeresumedisk = 'FALSE' 是否在从挂起恢复并使⽤VMware VMotion
特性迁移到新主机后同步。
timesynchronizeshrink = 'FALSE' 是否在整理虚拟磁盘碎⽚后同步
timesynchronizetoolsstartup = 'FALSE' 是否在⼯具守护进程启动时同步，通常在
客户 *** 作系统启动时同步。
*** 作系统内禁⽤时间同步
总结
有时候我们在虚拟机安装完 *** 作系统后，往往漏掉⼀些配置，例如：VMware Tools未安装、 *** 作系统时间是否同步⽹络NTP或者关闭时间⽹络同步⽽去同步主机时间等。我们需要根据实际情况，选择⼀种⽐较适合⾃⼰环境的时间同步⽅式，从⽽保证系统及应⽤程序的稳定运⾏。
￥
5
百度文库VIP限时优惠现在开通,立享6亿+VIP内容
立即获取
VMware虚拟机时间总是异常？简单两步彻底解决此问题
VMware虚拟机时间总是异常？简单两步彻底解决此问题
系统时间问题看似很⼩，但是对于⼀些时效性要求较⾼的业务系统，例如：考试系统、实时监
控系统等，时间问题影响甚⼤。我们在实际⽣产中也遇到⼀台虚拟机安装的Windows Server系
统（ *** 作系统时间同步NTP，未配置同步主机）由于系统时间异常导致应⽤服务出现问题。
第 1 页
*** 作系统时间同步
Windows：Windows *** 作系统直接把CMOS时间认定为当前显⽰时间，不根据时区转换。这样
每调整⼀次系统时区，系统会根据调整的时区来计算当前时间，确定后，也就同时修改了
CMOS内的时间。
Linux：Linux和苹果 *** 作系统以当前主板CMOS内时间做为格林威治标准时间，再根据系统设置
第 2 页
的时区来最终确定当前系统时间

需要自己进行修改
按WIN+R组合键，打开运行对话框，输入gpeditmsc命令，单击确定按钮。
打开组策略编辑器”窗口，依次找到(计算机配置—Windows配置—安全设置—本地策略---用户权利指派)目录．在右侧窗口中双击更改系统时间选项即可完成
Windows *** 作系统（别名：视窗 *** 作系统），是由美国微软公司（Microsoft）研发的 *** 作系统，问世于1985年。起初是MS-DOS模拟环境，后续由于微软对其进行不断更新升级，提升易用性，使Windows成为了应用最广泛的 *** 作系统
Windows采用了图形用户界面（GUI），比起从前的MS-DOS需要输入指令使用的方式更为人性化。随着计算机硬件和软件的不断升级，Windows也在不断升级，从架构的16位、32位再到64位，系统版本从最初的Windows 10到大家熟知的Windows 95、Windows 98、Windows Me、Windows 2000、Windows XP、Windows Vista、Windows 7、Windows 8、Windows 81、Windows 10、Windows 11和Windows Server服务器企业级 *** 作系统，微软一直在致力于Windows *** 作系统的开发和完善。

你看看虚拟机里面的vmware tools里面的设置，有个同步虚拟机和物理机时间的选项，你把它去掉，那么你在虚拟机里调整时间就能保持下去了。不过，最好的办法还是同步物理机的时间。ESX有时间服务器，公开的时间服务器有很多的，比如timewindowscom等等。
另外一个问题，linux安装时可以选择系统时间为UTC时间，那么你的虚拟机时间可能会和物理机相差8个小时，是时区的关系。

这道面试题是开放的。熟悉的情境，很容易给出一个回答。但随着被面试者思维方式、知识领域及深度的不同，回答可能大相径庭。

在接着往下阅读时，你可以先想想自己的答案。

没理解题目的回答：

还算正常的回答：

电子工程师的回答：

网络工程师的回答：

……

你可能有更精彩的回答……

本实验室将采用可 *** 作的、尽可能精确的实验作为回答。

题目并没有说两台电脑是和时间服务器同步的，所以目的只是测量两台电脑之间的系统时间是否一致。

用date命令（高精度选项）直接看一下两台主机的系统时间。本地的；远程的；本地的；远程的：

显然，host2的时间读数更大一些。但这究竟是host2的时钟快了，还是ssh调用所花的时间导致的呢？现在还不好说。

假设这个时间差异是T1:

T1 = Diff + RTT12

其中，Diff 是两台电脑真实的时间差异，RTT12是host1到host2数据往返所花的时间（严格来说是ssh调用所花的时间）。

反方向做同样的测试：

host1与host2的时间差异设为T2，则：

T2 = -Diff + RTT21

简单地认为两个方向的往返时间是相等的，于是有：

Diff = (T1 – T2)/2
RTT = (T1 + T2)/2

估算一下：

上面的单位都是ns 也就是说时间差异是163~171ms, ssh路途往返耗费728ms

这个结果可信吗？于是写了一段脚本，把这个测试过程自动化，观察一段时间的结果。

下图是每秒测量一次，1个小时的测量数据。为了在对数坐标下显示，时间差异用绝对值。

说明：

在没有时间同步的情况下，观察2组/3台主机：A, B, S的时间差异。

A, B, S实际上是在ESXi上的3台虚拟机。虚拟机的时钟可能和硬件实钟会有某种同步策略，所以看到的并不是单方向的变化。

在A,B,S上都开启NTP服务，时间服务器使用Debian Linux默认的NTP server (xdebianpoolntporg)。

因为幅度悬殊的原因，实际上使用中位数更有意义。可以看到A-S或B-S的时钟差异在30~50ms

在A,B,S上都开启NTP服务，其中A,B与本地的S同步，但S还是与远程NTP server同步。

可以看到A-S或B-S的时钟差异在3ms左右，一致性比远程NTP同步高了一个数量级。

在A,B,S上都开启NTP服务，其中A,B与S同步，但S直接使用本地时钟，配置为：

server 12712710 prefer

结果有点出乎意料，时间不一致接近60ms。

由于通常的 *** 作系统是非实时 *** 作系统，同样的指令占用的执行时间并不是固定的。做一个简单的实验，看看这个因素对测量会有多大影响。

下图给出了在两台机器上，读取系统时间（gettimeofday）这一调用所花的时间（各运行500000次）

可以看出9997%的执行都在1us及以下。这说明分时执行对统计结果的影响很小。

当然，整个ssh调用耗时的波动范围更大一些（RTT的统计值上可以反映出来）。

用ssh调用读取另一台机器上的系统时间，和本地时间比较，并利用双向ssh调用抵消调用所花的时间，从而可以较准确计算出两台主机上的系统时间差。

虽然在分时 *** 作系统上不能保证执行时间的固定，但通过统计可以逼近结果。由于ssh调用所花的时间在06ms以下，所以测量的精度至少是1ms级的。

另外，如果用非加密的web调用，或者自己实现远程调用，应该会有更高的效率，可能会对测量精度略有提高。

利用这一测量，可以观察NTP的同步效果。如果和远程NTP服务器同步，时钟的一致性实测在50ms以内；如果和本地NTP服务器同步，时钟的一致性在3ms左右；但如果本地NTP服务器使用本地时钟，一致性会下降很多（60ms左右）。

由于硬件/虚拟机时钟的波动、网络的波动、NTP的精度，都导致这种一致性总是处于波动之中。总体上，在局域网内，使用NTP同步，能达到毫秒级的一致性就不错了。

---