# Still not quite sure about getting time sync right for virtualized domain controllers. **URL:** \ **Category:** Factual Questions\ **Created:** [July 11, 2013, 11:00am UTC](https://boards.straightdope.com/t/still-not-quite-sure-about-getting-time-sync-right-for-virtualized-domain-controllers/663216 "2013-07-11T11:00:23Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Lobsang](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/lobsang/32/4067_2.png) [@Lobsang](https://boards.straightdope.com/u/Lobsang)\ **Post date:** [July 11, 2013, 11:00am UTC](https://boards.straightdope.com/t/still-not-quite-sure-about-getting-time-sync-right-for-virtualized-domain-controllers/663216/1 "2013-07-11T11:00:23Z")
Hi guys. Just wondered if I could get some advice from IT expert dopers, of which I know there are many. I have created two virtual domain controllers in vmware esxi. They are intended to replace two physical domain controllers so I will need to transfer all the ‘special’ roles to one of them (pdc emulator, schema master, etc.) I am aware that it is important to make sure the dc with those roles keeps time accurately, so it must be set up to use an internet time service rather than the machine’s hardware. Where I am confused is (apart from the fact that trying to wrap my head aroud this all is frying my brain) - many internet articles seem to explicitely state that a virtualized domain controller should not have its time synced with the physical hosts to avoid ‘time drift’, but if I set the virtual machine to sync from an internet time source surely this becomes irrelevant? In other words - if a virtual machine is using an internet time source (ntp) will it still keep accurate time? And if so, why do internet articles single out virtual domain controllers as requiring consideration when configuring time synchronisation? Surely if the general advice for a DC is to sync from ntp time server then it is irrelevant whether it is phyiscal or virtual? Can anyone confirm if the following is enough to have a correct/stable time synchronisation setup for a virtual domain controller that holds all the special roles? modify the registry to use ntp, and specify one or more external ntp server. run command line commands to set this domain controller as a reliable time source for the domain. ---
**Author:** ![Lobsang](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/lobsang/32/4067_2.png) [@Lobsang](https://boards.straightdope.com/u/Lobsang)\ **Post date:** [July 11, 2013, 1:49pm UTC](https://boards.straightdope.com/t/still-not-quite-sure-about-getting-time-sync-right-for-virtualized-domain-controllers/663216/2 "2013-07-11T13:49:08Z")
What’s worse is, the more I read about this, the more confused I become. For example, some articles say that the correct thing to do is not let your physical esxi hosts be responsible for time syncronisation. Other articles say the opposite! Why does simply having domain controllers in a virtualized environment have to be such a headache? ---
**Author:** ![Caldazar](https://avatars.discourse-cdn.com/v4/letter/c/8e8cbc/32.png) [@Caldazar](https://boards.straightdope.com/u/Caldazar)\ **Post date:** [July 11, 2013, 2:33pm UTC](https://boards.straightdope.com/t/still-not-quite-sure-about-getting-time-sync-right-for-virtualized-domain-controllers/663216/3 "2013-07-11T14:33:30Z")
The core issue is that DCs need to maintain consistent time at all times. This presents a challenge in a virtualized environment because the DCs are sharing resources. If you’re sharing resources among multiple VMs, there’s no guarantee that, at a particular moment, your VM will be allocated CPU cycles to process the timer interrupts and maintain the OS system time accurately. VMware’s recommendation is to disable time sync with the physical host in VMWare Tools, and then use frequent time w32tm/NTP sync to keep time. However, VMs still perform time sync with the physical host in certain circumstances, even with hardware time sync disabled in Tools. So it’s important that your physical host be syncing regularly to the same NTP server(s) as your virtual hosts. ---
**Author:** ![si\_blakely](https://avatars.discourse-cdn.com/v4/letter/s/d9b06d/32.png) [@si\_blakely](https://boards.straightdope.com/u/si_blakely)\ **Post date:** [July 11, 2013, 2:34pm UTC](https://boards.straightdope.com/t/still-not-quite-sure-about-getting-time-sync-right-for-virtualized-domain-controllers/663216/4 "2013-07-11T14:34:08Z")
In VMs, clocks can drift - this is a given due to the way computing resources are allocated and scheduled to the Virtual Machines. Because the AD time tolerence is 5 minutes and the time sync period is every 8 hours, it is easy to get problems As I recall there was an issue where there were serious time sync issues between ESX and supported VMs (the VMWare server could only correct the clock if it was behind realtime). I think that this is no longer the case, but it depends on the version of ESX. This is just background - if you can set up an external ntp system (maybe on your router, some support that) you can go with that and up the frequency of checks from 8 hours to ensure that the drift is never more than 5 minutes (without hitting an external ntp system too often which can also be problematic). ---
**Author:** ![Lobsang](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/lobsang/32/4067_2.png) [@Lobsang](https://boards.straightdope.com/u/Lobsang)\ **Post date:** [July 11, 2013, 3:16pm UTC](https://boards.straightdope.com/t/still-not-quite-sure-about-getting-time-sync-right-for-virtualized-domain-controllers/663216/5 "2013-07-11T15:16:24Z")
I do not want to have to create an external physical time source just so that my vms can sync more often than 8 hours. So it seems my options are… 1. Use vsphere and vmware tools, with win32time switched off. Making sure my hosts have time sync settings configured. And accept a slightly less accurate time. 2. Disable time sync in vmware tools (but make sure my hosts have time sync set up for those times when vms sync with the hosts despite time sync being switched off) and use win32time with an internet ntp time source, and just accept the risk of time drifting by more than 5 minutes every 8 hours. I think I prefer option 1. Are these my only options (bearing in mind that I don’t want to set up an external physical time source) ---
**Author:** ![md2000](https://avatars.discourse-cdn.com/v4/letter/m/73ab20/32.png) [@md2000](https://boards.straightdope.com/u/md2000)\ **Post date:** [July 11, 2013, 6:57pm UTC](https://boards.straightdope.com/t/still-not-quite-sure-about-getting-time-sync-right-for-virtualized-domain-controllers/663216/6 "2013-07-11T18:57:08Z")
ESX(i) itself can be configured for NTP time correction. Unless your clock speed drift is really out to lunch, that should be sufficient. Similarly, unless your ESX host is incredibly overloaded, the drift in guest time due to multitasking in ESX probably won’t hit 5 minutes. Use NTP on the primary DC (the PDC emulator role) and check time regularly - say every hour or two. Of course, if both your DC’s are on the same ESX host, then they will pick up the same (correct) time if you use its clock. There’s no reason to disable the W32time that hands out this time to the rest of the domain(s). Just don’t set W32time to use NTP to acquire time on the DC - use the host clock, provided it gets the time from NTP. I am not aware of the “can’t set time backward” issue, but I defer to an expert. OTOH, if the issue is drift in the guest due to excessive interruptions, the clock would be drifting backward, wouldn’t it? I would be sure that everything - ESX and DC’s - are running fairly close to the same time. If your concern is to limit number of NTP calls, make the ESX the source of all time. Otherwise, have ESX and DC both ask the NTP source. ---
**Author:** ![EricGreenDCFC](https://avatars.discourse-cdn.com/v4/letter/e/a6a055/32.png) [@EricGreenDCFC](https://boards.straightdope.com/u/EricGreenDCFC)\ **Post date:** [July 12, 2013, 6:09am UTC](https://boards.straightdope.com/t/still-not-quite-sure-about-getting-time-sync-right-for-virtualized-domain-controllers/663216/7 "2013-07-12T06:09:13Z")
Here is how I manage time within my ESXi environments, it has worked well for me. All Domain Controllers are virtual Let’s say that two of my domain controllers have IPs of 10.1.1.2 and 10.1.1.3 DC1 is the PDC emulator DC1’s w32time is pointed to several [pool.ntp.org](http://pool.ntp.org) IPs You can use Atomic Clock Sync from [worldtimeserver.com](http://worldtimeserver.com) to set the interval that it checks to something more frequent than the defaults. I also use that app to set the DC2 and any other DC to check their time at more frequent intervals (I have mine set to hourly) Next, all ESXi hosts have NTP enabled and started at startup. I point them to 10.1.1.2 and 10.1.1.3. After doing this almost 6 months ago I have had one issue with some servers going out of sync and it was because the ESXi host’s NTP service was not set to start when the host started up, so make sure to verify that all ESXi hosts NTP settings are configured properly. I check periodically that the ESXi hosts have the proper time and that the domain controllers have the proper time. ---
**Author:** ![Lobsang](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/lobsang/32/4067_2.png) [@Lobsang](https://boards.straightdope.com/u/Lobsang)\ **Post date:** [July 12, 2013, 8:14am UTC](https://boards.straightdope.com/t/still-not-quite-sure-about-getting-time-sync-right-for-virtualized-domain-controllers/663216/8 "2013-07-12T08:14:36Z")
Thanks for the further replies guys. Last night I switched on the ntp config in vcenter. Today they are still not accurate. One host is 50 minutes off, the other is 7 minutes off. My next step is to google that to find out why. **EricGreenDCFC** out of curiosity, is there a particular reason why you set your esxi hosts to sync from the dcs rather than ntp itself? My only reason for being concerned about more frequent calls to an ntp service was reading somewhere that they frown upon people checking them too frequently (more than every 8 hours)… apparently. ---
**Author:** ![md2000](https://avatars.discourse-cdn.com/v4/letter/m/73ab20/32.png) [@md2000](https://boards.straightdope.com/u/md2000)\ **Post date:** [July 12, 2013, 6:04pm UTC](https://boards.straightdope.com/t/still-not-quite-sure-about-getting-time-sync-right-for-virtualized-domain-controllers/663216/9 "2013-07-12T18:04:11Z")
The ESX hosts have NTP client in their individual configuration. (Config tab) (I was not aware they could be sync’ed from the vCenter; can you?) You might set up one (windows) server as your main NTP server and point the ESX to that, but if that WIndows server is a guest VM, then there’s an interesting risk of a self-referential loop depending if the Windows guest then cannot reach the external NTP source… ---
**Author:** ![gnoitall](https://avatars.discourse-cdn.com/v4/letter/g/bb73d2/32.png) [@gnoitall](https://boards.straightdope.com/u/gnoitall)\ **Post date:** [July 12, 2013, 7:44pm UTC](https://boards.straightdope.com/t/still-not-quite-sure-about-getting-time-sync-right-for-virtualized-domain-controllers/663216/10 "2013-07-12T19:44:58Z")
> [@Lobsang](#): > > Thanks for the further replies guys. > > Last night I switched on the ntp config in vcenter. Today they are still not accurate. One host is 50 minutes off, the other is 7 minutes off. My next step is to google that to find out why. > > **EricGreenDCFC** out of curiosity, is there a particular reason why you set your esxi hosts to sync from the dcs rather than ntp itself? > > My only reason for being concerned about more frequent calls to an ntp service was reading somewhere that they frown upon people checking them too frequently (more than every 8 hours)… apparently. Can’t address Windows, but in Unix/Linux implementation NTP-based host correction is slow if the original time diff was signficant. Quoting [man page for nptd](http://doc.ntp.org/4.1.0/ntpd.htm): > [@](#): > > Under ordinariy conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. Under conditions of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus error budget terms, can become very large. The ntpd algorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset, steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to a vanishingly low incidence. > > As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used. > > The issues should be carefully explored before deciding to use the -x option. **The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range.** During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time. **Emphasis** mine.