Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a Windows domain network with 2 Hyper-V hosts. On these hosts, there are several Hyper-V VM clients. Two of these clients are Domain Controllers.

The Hyper-V hosts are both clients of that domain. This brings one to a common time synchronization issue, as the hosts will try to sync their time with the PDC emulator and the domain controllers sync their time with the Hyper-V host.

While working on that issue, I didn't realize that the firewall in the network does not allow outgoing traffic on port 123. Which lead to several (failed) reconfiguration attempts.

Switching the time source

Once the problem was understood, I set the hosts up to sync to a reliable, on-site time source and wanted the DCs to simply use the VM IC Time Synchronization Provider again (so that they would sync the time with the host).

But one of the DCs is refusing to switch to the VM IC Time Synchronization Provider, it still uses the Local CMS Clock source (which, to my understanding, is not desirable).

What failed so far?

  • I tried disabling the Time Synchronization component for that VM in the Hyper-V Manager, then rebooting the machine, restarting the w32time service a couple of times, re-enabling the Time Synchronization component. That didn't work. I also tried other permutations of this process that didn't help either.

  • I tried changing the Enabled values in the registry (HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders) for the different time providers.

  • I re-installed the Hyper-V integration package in the client.

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

The best practice for time sync on Hyper-V is:

For Domain Controllers: Disable Hyper-V time sync inside the guest, but leave Hyper-V time sync enabled on the virtual machine configuration in the Hyper-V management console. This way Hyper-V sets the clock when the guest boots or resumes from a pause, but during normal operation the guest is responsible for its own clock. Use this command on the guest to stop it from using VM IC:

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0

(For a domain controller, it is important that it be responsible for its own time sync because AD needs to know the quality of the time. If the guest is managing the clock, it has access to the quality indicator of the network time. But if Hyper-V is managing the clock, then the guest sees the clock as an authoritative clock and always assumes it's correct, even when it's not.)

For all other guests: Use the Hyper-V guest additions to sync the clock. If the guest does not have additions installed then use the hardware clock, which the Hyper-V hypervisor will emulate.


Since in your case you've monkeyed with the time sync settings on your DC guests, I suggest that you reset your w32time settings first, then reinstall the guest additions, and finally apply the registry setting above.

share|improve this answer
    
While none of this helped me revert back to the VM IC Time Synchronization Provider, I realize now that what I was trying to achieve wasn't desirable in the first place. Thus, I am now synchronizing my Hyper-V hosts as well as all DCs with the same external time source. –  Oliver Salzburg Jul 23 '12 at 16:07
    
Ideally, all of your DC's should not be synchronized to an external time source; only one of them should be. The rest should be allowed to synchronize from that DC. –  longneck Jul 23 '12 at 16:24
    
Thanks for pointing that out. I adjusted my configuration accordingly. :) –  Oliver Salzburg Jul 23 '12 at 16:52
    
By adding the VMICTimeProvider and setting it to 0 on our DC, w32time was using the CMOS source when restarted. However, attempting to configure it to use the peer list (MANUAL sync flag) would systematically reset the source to the VM IC Time Provider (the registry key wouldn't be touched, and remained with a value of 0). I did resort to disabling the IC for the guest DC on its hypervisor despite present advice and the w32time promptly used the correct source (peer list) after a service restart. I'd be grateful to any of you for any thoughts on how to resolve this without disabling it. –  tne Nov 21 '13 at 16:12
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.