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).