Posey's Tips & Tricks
What To Do About Hyper-V Clock Sync Issues
Fixing out of sync VM clocks may be a bit annoying, but it's 100 percent doable. Here's how.
One of the nice things about Hyper-V is that you usually don't have to worry about setting virtual machine clocks to the correct time. In the vast majority of cases, the virtual machines synchronize their clocks to the host server, meaning that if the Hyper-V host's time is correct then the virtual machine clocks are correct as well. Additionally, because virtual machines sync their clocks to the Hyper-V host, all of the virtual machines that are running on a given host will normally display the same time as one another.
Occasionally, however, you may find that the Hyper-V Time Synchronization Service (which is a system service that is built into the Windows Server operating system) fails to keep virtual machine clocks in sync. Believe it or not, there is actually a good reason why this happens.
Imagine for a moment that you have a time-sensitive application and the servers that make up that application are all synchronized to an NTP server's clocks. Just to make things interesting, let's also assume that the Hyper-V server is not synchronized to an NTP server. The end result would be that the Hyper-V server's clock would be set to a different time than the application server's clocks. In this case, the Hyper-V server's clocks are incorrect (because they are not synced to an NTP server), so you wouldn't want the application server to forgo its correct time and synchronize to the Hyper-V server's clock, which is incorrect.
So as you can see, there is a good reason for not synchronizing virtual machine clocks in every situation. Even so, I still have not answered the question of why the Hyper-V Time Synchronization Service sometimes keeps virtual machine clocks in sync, but neglects those clocks at other times.
The time synchronization issue ultimately comes down whether the virtual machine clocks are fast or slow, and how long they have been that way. According to Microsoft If the virtual machine's clock is running fast, then the Hyper-V Time Synchronization Service will bring the clock back into sync with the Hyper-V server. However, this will only happen if the clocks have been out of sync for less than five seconds. If the clocks have been out of sync for more than five seconds, then the Hyper-V Time Synchronization Service will not bring the clocks back into sync. The previously cited Microsoft article does not address the issue of a virtual machine whose clocks are slow, so presumably the Hyper-V Time Synchronization Service will bring a slow VM clock into sync with the Hyper-V host's clock.
This of course raises the question of what you can do if you need for VMs to be synchronized to the Hyper-V host regardless of how the VM's clock is currently set. Bringing out of sync clocks into sync isn't always easy to do. There is no setting that you can configure in Hyper-V to force VMs to synchronize their clocks to a Hyper-V host. Microsoft provides a few workarounds in the previously mentioned article, but my advice would be to simply synchronize all of your Hyper-V hosts and the virtual machines that are running on them to an NTP time source.
In an Active Directory domain environment, the PDC emulator normally acts as a time source for all of the member servers in the domain. However, you can use group policy to force Windows to synchronize its clocks with an external time server. You can find the group policy settings within the Group Policy Editor at Computer Configuration | Administrative Templates | System | Windows Time Service | Time Providers. Â You can see what this looks like in Figure 1.
[Click on image for larger view.] Figure 1. There are three group policy settings related to time synchronization.
As you can see in the figure above, there are three group policy settings related to time synchronization. You will need to enable the Enable Windows NTP Client and the Enable Windows NTP Server settings. You will also need to enable the Configure Windows NTP Client setting. Upon doing so, you will need to set the Type option to NTP and you will need to set the NtpServer to: NtpServer: us.pool.ntp.org,0x1 1.us.pool.ntp.org,0x1 2.us.pool.ntp.org,0x1 3.us.pool.ntp.org,0x1; As you can see in Figure 2, there are some other settings available, but you can usually get away with using the default values for those settings.
[Click on image for larger view.] Figure 2. You will need to set the type to NTP and then specify the NTP server names.
Once you have made the configuration changes, you may need to reboot the servers or force a GPO update before the changes will take effect. It's also worth noting that NTP uses Port 123, so if you have trouble getting NTP synchronization to work then make sure that this port is not blocked.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.