Currently, our standard deployment of ESX servers and Windows guest VMs involves everything that the following article espouses:
In the guests, VMware tools runs with the checkbox checked to sync time with the host, and Windows time service itself stopped/disabled. These settings have been part of our Windows guest VM templates for about 2 years now.
ESX hosts are setup for NTP time sync, firewall/port opened, step-tickers, ntp.conf, etc. This all per . The ESX hosts all sync with our chosen time server (which in turn is verified accurate).
We are a single Windows domain shop, and the PDC emulator (none of our domain controllers are virtual machines) syncs to the same time source as our ESX hosts do. A check of our domain controllers shows time is indeed in sync with the same NTP source of the ESX hosts.
All that said, I don't think many of us think to check on Windows guests unless a particular program requires our attention, such as, oh I don't know, Kerberos authentication issues. Recently, one of guest VMs had difficulty authenticating to the domain, and I found that, sure enough, its time was offset (relative to the domain controller in its site) by about 6 minutes. First, I checked the VMtools checkbox (checked/fine). Then, I verified the Windows time service itself was stopped/disabled as per our standard practice; indeed it was. Next, I checked the time of the ESX host the VM was running on, and guess what? Its time was off by that same 6 minutes, down to the second. So, VMware tools time sync was indeed doing its job. That's good. Fortunately, the other (2) guests on that 6-minute offset host were not as user-affecting as the one that led me to investigate all this.
The question, of course, becomes s why would the time on the ESX host, controlled via NTP daemon, have such a large offset with its NTP source I configured it for? Also, I immediately checked ALL of our ESX clusters/hosts, and, out of 15 ESX hosts total, NINE of them had various offsets. NONE of my physical Windows hosts (whether domain members or domain controllers) had severe offsets such as the rest of these did. Fortunately, of those 9 offsets, all of them were between 7 seconds fast, to 3.5 minutes slow, per the output of ntpdate -q (time source).
A simple service ntpd restart on the affected ESX hosts has resolved this. For now---until, over time, they drift again(?!). They all use the same ntp.conf and step-tickers configs/files, yet 6 of those 15 had no (or negligible) offset in the 0.0001/2/3/4... range. On all hosts, the NTP service has been configured to start/stop with the system, and the NTP service was certainly running on every one of them. If ALL hosts had some sort of offset, I'd actually feel more comfortable about this, but as noted only 6 did (yet they are all configured the same to the best of my knowledge; I built them all and have set standards for NTP config, etc).
Now I'll have to hand-check every single VM and make sure the time on them (if off), is set to a time that is EARLIER than that of the host, so the tools will sync the time correctly. I get to check about 95 VMs. Hooray.
All hosts are ESX 3.0.2. They don't have every single patch for 3.0.2 but I don't think there are any patches released for 3.0.2 that deal with drifts in the service console's time.
Short of setting up a cron job to restart the NTP daemon every day, does anyone know of drift issues on the hosts? Have you checked 'your' hosts lately for offset? How about yours Windows guests syncing with your hosts via tools? While I'm at it, does anyone have Linux guests (with tools installed)? The time on my one RedHat Ent 4 guest is off as well. Thanks.
