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.
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?
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.
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).
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…
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.
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)
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.
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 IPs
You can use Atomic Clock Sync from 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.
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.
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…
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: