Last Updated: 26 January 2024

Question

How do I configure Domain Time II on a virtual machine (i.e. VMware, Hyper-V, etc.)?

Answer

Because operating systems running as virtual machine guests share the host's physical resources (such as CPU processing time and interrupt handling), their ability to keep their own accurate time is diminished. Accurate OS time depends on regular servicing of timers so that the system clock continually moves forward smoothly. Virtual machines must often wait while the hypervisor is busy servicing other guests, resulting in clock drift or erratic behavior. This problem is inherent in the basic nature of multiple operating systems sharing the same physical hardware.

As a result of this inherent instability, a virtual guest OS is generally less suitable for use as a platform for accurate timing than are those running directly on physical hardware. This is of particular concern when a guest OS is used to provide time to other systems on the network (such as on Active Directory domain controllers) or as a primary time source to other time clients. Excessive clock instability of a guest machine acting as a server can result in serious problems with time sychronization throughout your enterprise. Also, be aware that any tools that calculate time variances (such as Domain Time II Audit Server, Domain Time II Monitor Service, the Domain Time II Manager variance report, DTCheck utility, etc.) will also be affected by these clock instabilities.

In general, any machine where accurate time synchronization is critical should run directly on physical hardware. If you decide to use virtual machines instead, care must be taken to ensure any machine used to run Domain Time be tested in your environment under your workloads to be sure it performs within your accuracy targets.

Guidelines for using the various Domain Time II components on virtual machines

---



Domain Time II Client, Server, or DTLinux:
Domain Time can be configured on a guest OS in the same manner it is configured on a stand-alone physical machine. However, given the additional instability of the virtual platform, you should take into account the need to synchronize more frequently to compensate for drift. As a result, relaxed synchronization rate settings may not be sufficient. If you are using NTP or the DT2 protocol, you will need to set Domain Time to synchronize on a regular schedule of at least every 1 minute and then adjust that schedule up or down to achieve your desired accuracy. See the Timings page (Client) (Server) or loop settings (DTLinux) for how to set a fixed synchronization schedule. If you are using PTP, follow the configuration instructions on the IEEE 1588-2008/2019 (PTP) page carefully.

Domain Time Windows Servers and Clients have additional built-in support for virtual guests that assist with issues unique to virtual environments, such as immediate resynchronization of the clock upon resumption from a paused/saved state. This feature is enabled on the Advanced property page of the applet (Client) (Server)

Domain Time II Manager and Tools: The Domain Time II Management tools contain a number of programs that calculate, compare, and report on clock variance such as Domain Time II Monitor Service, the Domain Time II Manager Variance Report page, the DTCheck utility, etc. Tools that calculate comparative time variances will provide less accurate results when executed from a virtual OS. Use a physical machine for this component, if possible.

Domain Time II Audit Server: Audit Server does time comparisons and raises alerts based on measured variances that are highly affected by time drift. Use a physical machine for this component, if possible.

Recommendations

---



• Consider using PTP to synchronize your systems if available. If not, set your machines to synchronize with local NTP or DT2 time sources on a frequent, fixed schedule.

• It's very important that you regularly monitor your clock synchronization on virtual machines. The environment is extremely susceptible to changes in load, not just in your virtual guest but across the entire hypervisor host. Since these changes can occur at any time in other guests or on the host, settings that were once perfectly adequate to keep your time synched in any particuar guest may suddenly be insufficient. We recommend using a monitoring product capable of generating alerts to notify you of insufficient sync, such as Domain Time II Audit Server.

• The time on the hypervisor host machine (i.e. ESX/ESXi host or Hyper-V root partition) should also be synchronized as much as possible to the correct time (preferably using Domain Time II). The guest OS will use the host's time at startup, and occasionally, some functions of the virtualization software will attempt to match the guest clock to the host (even if you have built-in time synchronization disabled - see below). It's therefore very important that the host clock be as close to accurate as possible.

• Virtual machines are more sensitive to clock disruptions due to system maintenance such as system backups and functions specific to virtual enviroments, like vMotion/replication transfers, snapshots, etc. Maintenance tasks should be scheduled during off-hours, if possible.

• Use the most recent version of your hypervisor and of the guest OS. For example, as of Windows Server 2012R2, Microsoft has made significant improvements in Hyper-V guest clock handling. In addition, Windows Server versions as of 2012R2 and desktop verison as of v8.1 have additional optimizations that greatly improve clock stability when operating as Hyper-V guests. These versions also perform somewhat better on VMware since they are more stable in their overall clock performance.

Regarding the host built-in time sync features (i.e. VMware Tools, Hyper-V Integration Services, etc.)

---



Most virtualization products include a built-in time synchronization function that attempts to synchronize the guest OS clock to that of the host (such as those included in the VMware Tools, Hyper-V Integrations Services, etc.). These functions vary in effectiveness and often create additional problems for accurate timekeeping, such as unexpected stepping of the clock, backwards time jumps, etc.

Previous versions of this KB article recommended using the built-in time sync functions of the virtual software based on manufacturer documentation; however, we have revised our recommendations based on extensive testing and customer feedback. It is almost always best practice to disable the built-in guest-to-host time sychronization functionality of the guest and use Domain Time to synchronize the guest OS clock.

As mentioned above, even if you have the built-in sync tools turned off, some virtual environments (like VMware) do still occasionally attempt to set the guest OS clock to match the host, such as when doing backups of the guest image files, or other housekeeping. Domain Time will detect these attempted changes and immediately attempt to correct for them, however, the host clock should still be kept correct to prevent a wild-time situation where the guest clock suddenly jumps to a highly incorrect value that Domain Time cannot quickly repair. If these types of unexpected clock adjustments will present serious problems for your application, you should change to using a physical machine instead of a virtual one. Note, some of these unwanted events can be avoided by disabling internal time synchronization on the VMware host as well as in the Guest VMware tools as described in VMware KB article (1189).

 

References
Disabling Virtual Machine Guest-to-Host Time Synchronization on Multiple Hypervisors
Disabling Time Synchronization under Virtual PC 2007
VMware Time Sync and Windows Time Service
Timekeeping in VMware Virtual Machines (.pdf)
Disabling Time Synchronization (1189) - VMware