Time Synchronization for Domain Controllers Virtualized Via Hyper-V

Question

I would like to know if someone can recommend a better way to configure domain time synchronization for a group of Windows Server 2008 R2 servers than what I currently have configured. I have three domain controllers that are all Hyper-V guests. For all of these DCs, the host’s time synchronization feature of integration services is disabled. The DC’s are configured as authoritative time servers and the FSMO DC1 server uses the public nist-a and nist-b servers as its time source. DC2, DC3, and all other servers in this environment, both hosts and guests, are members of the one domain and look to DC1 for time. For all remaining guests (i.e. not the DCs) the time synchronization feature of integration services is enabled. The reason for this post is that I’m sporadically seeing the message that follows in the next paragraph and I would like to get all of my servers (both hosts and guests) to have their time be as accurate as possible:

The time service detected a time difference of greater than 5000 milliseconds for 900 seconds. The time difference might be caused by synchronization with low-accuracy time sources or by suboptimal network conditions. The time service is no longer synchronized and cannot provide the time to other clients or update the system clock. When a valid time stamp is received from a time service provider, the time service will correct itself.

If someone has a similar setup with virtualized DCs and has achieved highly accurate time synchronization across all servers in the domain, your input would be appreciated.

Thanks.

Answer 1

The most reliable method of maintaining time in a virtualized domain environment is to keep your PDC physical, increase the sync frequency and drift tolerance on all your virtualized DC and domain members, and disable host-guest time synchronization for all VMs in question.

Here's a pseudo-explanation of the problem (it's been a long time since I looked at this):

When a machine (workstation, server, VM) starts up, it reads the time from the RTC (battery backed clock chip on the motherboard/BIOS), and works out the duration of each CPU tick. The OS then counts the number of clock ticks that have occurred since the initial reading was taken, and adds the time from that to the original time reading taken at boot. This gives you the current time.

Problem is, hosts obfuscate the true clock cycles occurring from the VMs. A VM may have seen 100 clock cycles when 500 clock cycles have actually occurred on the host. So this method of calculating time breaks down, and time drifts out of whack on the VM.

Host-Guest time synchronization via the installed vm tools/enhancements packages on vSphere and Hyper-V go some way to curing this, but they're not perfect (in some setups they can pull a VM forwards if it's drifted behind realtime, but they don't jump a VM forwards if it's drifted ahead of realtime).

This complicated further by the way clock cycles are counted on multi-core setups (the timing counter is essentially emulated on each core) and on setups that can change clock speeds on the fly (I have no freaking idea how this is maintained). Factor in the idea that a VM can execute one clock cycle on one core, then jump to a different core on a different CPU for the next cycle, and it gets really horrible.

So back to the original point: Domain time by default starts at the PDC, then trickles down to the other DCs, then out to the member servers and workstations from there. So if you ensure your PDC is a truly reliable time source (by keeping it physical), and disable host-guest sync on all other domain members, you'll ensure a stable and relatively accurate time infrastructure.

Note that running your PDC as a physical server then enabling Hyper-V on that server and adding some guests to it is probably not a suitable fix either, as I believe that when you enable Hyper-V the 'base' OS actually becomes a virtualised OS as well (silently). So keep one physical server as a PDC, and keep Hyper-V off the box.

Interesting side point to note: Microsoft's official stance on Windows Time Synchronization, even using the compliant NTP service that's been built into Windows since XP/2003, is 15 seconds. In practice, you can get it down to sub-100ms, but all they'll support is synchronization to within 15 seconds. Kinda makes sense, the only time-sensitive key component at the core of most MS environments is Kerberos, and by default that'll operate happily as long as you're within a 5 minute tolerance.

Answer 2

Yeah. Do not turn off synchronization EXCEPT on the one server that actually is also a physical domain controller.

I have the same setup and I have made sure that the machine that serves time is a physical domain controller- small box. All virtual DC are time synced from hyper-v.

The real danger is the feedback loop between host and client and this way the loop is broken.

This is NOT highly accurate BTW - windows never is. It only syncs to a very bad degree of accuracy. I have another machine that collects financial data and is synced to the ms to an external host (average skew per hour: 37ms according to statistics) ;) THIS is accurate.