VMware Cloud Community
cwb2000
Contributor
Contributor

How to stop the ESXi host changing VM's time.

Recently I had a VMware ESXi (4.1 and 5.0 are the same) environment and creating three VM server (Windows 2008 R2 Standard). I found a interesting thing is whenever I manually changed the ESXi host time a big value let's say 5mins or 10mins.

And roughly within one hour later, all three VMs have been changed the time, like "The system time has changed to ‎2011‎-‎12‎-‎29T07:27:38.500000000Z from ‎2011‎-‎12‎-‎29T07:22:41.502723100Z." EventID is 1, and user is "system". Before that, the time configuration on ESXi host is showing red (refer to picture1). And after 10~20 minutes later, the host is not responding. (refer to picture2). After the VM's time been changed, the time configuration on ESXi host is showing normal again.

I checked everything with the w32time service inside the windows registry and disable all NTP, even disable w32time service. This one seems to happen again and again.

Then I enable the logging with w32time service and found the SyncToCmos is yes, I suspect the root cause is VM try to sync with hardware sometimes. Would like try to disable it and see how is going. Any idea with this kind of issue?

I did add the following content into configuration (.vmx) file and reboot the VM as well.

tools.syncTime = "FALSE"
time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"

The reason why we will pay attention to this issue is because our environment don't have any connection to internet which means we can't use NTP server to sync ESXi host. Then we ran one script to manually sync the ESXi host with one of the VM which is the master clock of our system. But everytime we have a big change such as 3 minutes, sound like ESXi host will correct the VM again and then the master clock is not correct any more and trigger the problem.

Your reply will be greatly appreciated!

Reply
0 Kudos
8 Replies
Rubeck
Virtuoso
Virtuoso

Hi..

Have you tried to use "0" instead of "FALSE" in those .vmx entries?

/Rubeck

Reply
0 Kudos
cwb2000
Contributor
Contributor

Hi Rubeck,

Not really, will change it tomorrow morning to see does this affect?

Thanks a lot for the comment.

Reply
0 Kudos
AWo
Immortal
Immortal

Try to replace "False" by 0.

Check page 17 of http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

AWo

vExpert 2009/10/11 [:o]===[o:] [: ]o=o[ :] = Save forests! rent firewood! =
Reply
0 Kudos
cwb2000
Contributor
Contributor

Hi Rubeck,

I changed to "0", it is same. I posted more information which i found out, please have a look if you got time. Thanks a lot!

Reply
0 Kudos
cwb2000
Contributor
Contributor

Hi AWo,

I changed to "0", it is same. I posted more information which i found out, please have a look if you got time. Thanks a lot!

Reply
0 Kudos
a_p_
Leadership
Leadership

Although ESXi 5.0 is not listed under Product Versions, http://kb.vmware.com/kb/1189 should apply to it too.

André

Reply
0 Kudos
cwb2000
Contributor
Contributor

I had read "Timekeeping in VMware Virtual Machines" carefully. I think the following text may explain what I experienced.

"The virtual CMOS TOD clock has the following limitation: Because the clock is implemented as an offset from the host operating system’s software clock, it changes value if you change the host operating system time. (Changing the host time zone has no effect, only changing the actual time.) In most cases this effect is harmless, but it does mean that you should never use a virtual machine as a time server providing time to the host operating system that it is running on. Doing this can create a harmful positive feedback loop in which any change made to the host time incorrectly changes the guest time too, causing the host time to appear wrong again, which causes a further change to the host time, etc. Whether or not this effect occurs and how severe it is depended on how the guest operating system uses the CMOS TOD clock. Some guest operating systems might not use the CMOS TOD clock at all, in which case the problem does not occur. Some guests synchronize to the CMOS TOD clock only at boot time, in which case the problem does occur but the system goes around its feedback loop only once per guest boot. You can use rtc.diffFromUTC to break such a feedback loop, but it is better to avoid the loop in the first place by not using the virtual machine as a time server for the host. Some guest operating systems periodically resynchronize to the CMOSTOD clock (say, once per hour), in which case the feedback is more rapid and rtc.diffFromUTC cannot break the loop."

That is what we had, we use one VM as time master. (Unfortunately we can't change it for many reasons).

"A daemon present in Windows NT-family systems (that is, Windows NT 4.0 and later) checks the system time of day against the CMOS TOD clock once per hour. If the system time is off by more than 60 seconds, it is reset to match the TOD clock. This is generally harmless in a virtual machine and might be useful in some cases, such as when VMware Tools or other synchronization software is not in use. One possible (though rare) problem can occur if the daemon sets the clock ahead while the virtual machine is in the process of catching up on an interrupt backlog. Because the virtual machine is not aware that the guest operating system clock has been reset, it continues catching up, causing the clock to overshoot real time. If you turn on periodic clock synchronization in VMware Tools, it disables this daemon."

That is why I need to stop the daemon present in Windows 2008 then try to fix this issue.

Thanks!

Reply
0 Kudos
cwb2000
Contributor
Contributor

Hi André,

Thanks for the reply, please check my new reply. I think the problem I met is not migration or resume VM etc. It happened when we changed ESXi host clock from one of the VM.

Now I am more concerning with the daemon inside the windows to sync with CMOS.

Thanks!

Reply
0 Kudos