Mar 062017
 

VMware’s VMTools package has some options for synchronizing the in-guest clock with the time of the ESXi host. By default, these are set to disabled, and under most circumstances, the hypervisor follows these settings and everything is fine. However, several situations exist where the hypervisor will reset the in-guest time, even though the VMTools setting is explicitly set to not allow this to happen.

  • A virtual machine is resumed from a suspended state
  • A vMotion occurs
  • A snapshot is taken
  • A snapshot is restored from
  • A virtual disk is shrunk
  • The VMware Tools service is restarted, which includes a guest reboot

Of these tasks, vMotions for load balancing and snapshots for VM-level backups are very common routine operations for VMs.

These time sync actions can move a guest’s time backwards as well as forwards. More details about this conflict of settings are found in VMware KB1189. If the host time is out of sync, such as when a BIOS battery fails, bad things can happen. This action is extremely detrimental to the state of SQL Server high availability features, such as Availability Groups and Failover Cluster Instances, which depend on the in-guest time closely aligning with the Active Directory synchronized time. This action must be explicitly disabled to ensure that these maintenance items do not trigger an unexpected failover of the SQL Server HA solution. To disable this action, perform the following tasks.

To correct this action, first shut down the virtual machine. Then, edit the virtual machine’s advanced configuration parameters under VM Options, and add the following keys and values.

Key Name Value
tools.syncTime 0
time.synchronize.continue 0
time.synchronize.restore 0
time.synchronize.resume.disk 0
time.synchronize.shrink 0
time.synchronize.tools.startup 0
time.synchronize.tools.enable 0
time.synchronize.resume.host 0

Save the configuration. Power back on the VM.

Jun 162012
 

The VMware KB article at this page is somewhat inaccurate. If you have the need to manually install the VCD agent on an ESXi host (I did – I had a glitch in the home lab tonight) then adjust your directions as follows.

  • Get the VIB file from the VCD server and upload it to a location that the ESXi server can get to.
  • Open up SSH on the ESXi server, and SSH in.
  • Use the command: esxcli software vib install –viburl=file:/path/to/vcdagent.vib
  • The web KB article lists the inaccurate command: esxcli software vib install /path/to/vcdagent.vib. Don’t do this! It wll throw a cryptic error about an unknown namespace.

That’ll fix it!