Among the many mouth-watering goodies packed into the newly-released VMware vSphere vSphere 7.0 Update 2 is (finally) VMware’s fully-backed solution to meet the long-standing requests from Enterprise Application vendors and customers who need to support STRICT time accuracy and precision for their time-(hyper-)sensitive virtualized Applications. As I have previously mentioned in the past, most Applications in the Microsoft world, including Windows and Active Directory Domain Services are happy with loose time convergence and accuracy. Kerberos, for example won’t really barf at you if two endpoints have a time skew differing by up to 5 minutes. In the Computer World, life happens, loosely. And this is why the world of time synchronization, time keeping and time convergence has lived on the standard Network Time Protocol (NTP) somewhat happily for so long.
Somewhat happily; because, truth be told, the quest, need and demand for more precision and accuracy have never ceased to exist since almost the time large-scale computing became a commodity accessible to even the lowliest amongst us. Many Applications, operations, processes, tasks (etc) require sub-microseconds convergence and accuracy between and among participating systems and they tend to break down where such is not possible. The emergence and growth in popularity in virtualized High Performance Computing, Trading Platforms, Healthcare and Scientific Researches in modern computing combined to amplify the gross shortcomings of NTP and pressed the need for something better more vigorously. The response to this is a corresponding increase in the push to prioritize adoption and formal implementation of support for the Precision Time Protocol (PTP) in all Platforms. To be sure, PTP is not a new invention – it just hadn’t had the love, respect and attention it deserved as THE alternative to what everyone knew wasn’t serving the needs. VMware silently introduced support for PTP in vSphere 7.0, but vSphere 7.0 Update 2 is really where we feel that it is now ready for its grand entrance into the polite hyper-scale, time-sensitive applications circle.
Let me quickly point out that you can use PTP as the Time synchronization option for both the ESXi Host and its Guest VMs. One is not dependent on the other, as discussed and illustrated below.
While I am focusing on using the “Precision Time” feature for a VM in this post, it is relevant to mention that you can also configure an ESXi Host itself to use PTP for its time sync needs. Doing this requires that you have an external PTP Source that the ESXi can sync from somewhere on the network. If you do, then the image on the right shows where you set that up for the Host.
If you don’t have an external PTP Source, then you would just continue using the standard NTP option to synchronize your Host’s clock, as you have been doing before.
Please note that neither of these Host-side configuration impacts your ability to use the new “VMware Time Provider (vmwTimeProvider)” feature for your VM. What is important to note here is that VMware strongly recommends that you always configure your ESXi Hosts to sync time with at least one reliable external time source. Whether you use NTP or PTP for that is immaterial to our current discussion.
As with most things in vSphere, enabling and using PTP in a VM is quite trivial. It’s all point-and-click.
The process is as simple as just adding the “Precision Clock” Device to the VM, as shown here on the left. Please note that the VM’s Hardware Compatibility Level must be at least “VM Version 17”, so if you have just upgraded your vSphere infrastructure, or migrated the VM from a previous version, be sure to upgrade the VM’s Compatibility.
After adding this device, you must then configure it to use an ESXi Host for time sync. Please note that this is different from the task of selecting whether or not the VM synchronizes its time with an ESXi Host through the VMware Tools. The process is shown in the image to the left:
Wondering which of the two options in this image you should choose?
IF your ESXi is ALSO configured to be a PTP SOURCE (“Source”, I said. Not “Client”), then you would choose “Host System Time (PTP)”. Otherwise, you would choose “Host System Time (any)” as I have done in the image above.
OK, now that we have added the device to the VM, made our choice of synchronization option, and powered on the VM, all we need now is a Driver. No, no… not a Chauffeur – a device driver.
Because “Precision Clock” is a Paravirtualized device, its drivers is not native to Windows. It is delivered through the VMware Tools. So, be sure to also upgrade the Tools. When installing or upgrading the Tools, you must ensure that you select the option to also install the “VMware Time Provider” utility (as shown in the image to the left, the option is NOT selected by default)
And, that’s it. That’s all we need to do. Just reboot the VM after this, then we’re good to go.
Don’t take my word for it, though. Let’s actually verify that we’re now using vmwTimeProvider in our Windows VM:
Let’s also check what https://www.time.is thinks of our configuration?
All good, right? Right. Except…
The Caveats:
Active Directory itself does not require this much time accuracy strictness, so let me be very clear:
- Our recommendation for ensuring accurate time-keeping and synchronization in a vSphere-based virtualized Active Directory infrastructure (Section 3.3 of Virtualizing Active Directory Domain Services on VMware vSphere) and in this blog post (https://blogs.vmware.com/apps/2020/09/ensuring-accurate-time-keeping-in-virtualized-active-directory-infrastructure.html) still remain valid and continue to be our official position, especially for your Domain Controllers.
- Our vmwTimeProvider Plugin provides an opportunity to close the gaps which have existed for long in environments where certain systems, processes and devices require stricter time accuracy than what is provided by the Windows default NTP-based Time Provider.
- vmwTimeProvider lets you configure these systems to satisfy the application/process strict time requirements. Domain Controllers do NOT fall into this category, and most of your AD clients would not need it, either.
- It is, therefore, important to note that VMware does not recommend configuring your Domain Controllers as PTP Clients.
- Microsoft introduced the “Secure Time Seeding (STS)” feature in Windows Server 2016, primarily in an attempt to detect and correct time synchronization errors, using outgoing SSL connections, and to proactively mitigate such occurences. It has since been proven that STS error-detection and correction logic is sufficiently flawed as to have become problematic and very disruptive in the enterprise. Microsoft has, therefore, been recommending that Customers consciously disable this feature in an Active Directory infrastructure where reliable and optimal time synchronization can be accurately provided the Windows NTP or other time-keeping facilities.
- For completeness, here is the instruction for disabling STS in Windows (Note: this is better controlled through a GPO setting in the Active Directory infrastructure:
Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
Value Name: UtilizeSslTimeData
Value Type: REG_DWORD
Value: 0
Command Line: reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f
- Lastly, please note that neither NTP nor PTP can protect a VM against inaccurate CMOS RTC time on a Host. Virtualized Windows Guest Operating System VMs will always read and feed off of its Host’s CMOS clock on boot-up/power-cycle. This is one of the reasons VMware continues to highly recommend that vSphere Administrators pay close attention to possible CMOS-induced Host’s clock inaccuracy AND to always synchronize their Host’s time with a known reliable and accurate external time Source – preferably one in Stratum 1.
