Script to disable time synchronization in VM… and more!

Time synchronization of Guest OS-es running vmware virtual machines is a very important topic that has been extensively covered in VMware documentation.

General recommendation for all types of OS-es is to use external (NTP) time source and not to use VMware Tools time synchronization (with vSphere host) whenever possible.
There are many good reasons for that, including but not limited to reduction of CPU overhead when using external time source.

Unfortunately it is not that obvious that un-ticking “Synchronize guest time with host” checkbox might not be enough in some scenarios.

If you saw Artur’s post from last week, you probably know VMware’s KB 1189 where you can read, that even with above functionality disabled, VMware Tools (by default!) will synchronize time with host upon events like machine (s)vMotion, snapshot creation or restore and Guest OS reboots.

Moreover, while “standard” time synchronization with host can only move your time “forward”, Guest OS time can be also set “backward” (in circumstances where host time is “in the past” compared to Guest OS time) after each of the events listed. This in turn can be a source of many unexpected and unwanted situations, included but not limited to Kerberos authentication problems (if time is skewed by more than 5 minutes) or inability to co-relate event timelines from different vms in your enterprise monitoring / log analytics systems.

This has been a reoccurring topic in many VMware environments I’ve supported, especially when implemented backup software heavily depends on VMware snapshots and volume of protected data is larger than average.

[Update as of July 22nd] Inspired by StanJ comment below – I’d like to stress out that I’m not recommending changing this default VMware Tools behavior for everybody, I’m just sharing a tool that would facilitate this change if you need it in your environment (if you experience time synchronization issues coming from VMware Tools) [/end of Update]

Disabling time synchronization via VMware Tools completely requires change of all 8 advanced settings for each virtual machine. This of course is a weary task if you have anything more than 2 vms in your environment, that’s why I wrote a script to automate this task.

Nothing really advanced in this script, it takes vCenter server name and host cluster name as parameters (I assume you want to reconfigure your vms on per cluster basis, but it is really easy to change it to whole datacenter or whatever). Script also expects adv_settings_list.csv file in its working directory. The content of this .csv file are basically parameter name and value pairs, for the use case of disabling vmtools time synchronization the .csv file should look like this:

If you want to disable periodic vmware tools time synchronization and time synchronization for snapshot creation event (leaving synchronization on for revert to snapshot operation – just in case you snapshot your memory as well) the adv_setttings_list.csv file should look like this:

Values imported from .csv file are fed to New-AdvancedSetting PowerCLI cmdlet, which is executed for every vm found in the cluster, templates are excluded from modification but you can easily revert this condition and modify your templates only. Please note that the first setting (tools.syncTime =0) is corresponding to “Synchronize guest time with host” available directly in GUI.

You need PowerCLI 5.1 or higher to use New-AdvancedSetting cmdlet, if you are still in 4.x zone you might be interested in a custom function created by LucD and Alan Renouf some good time ago already.

Because I want my scripts to look as pr0 as possible especially for this blog I introduced Write-And-Log function that allows you to write colorful messages both to the console and logfile (well OK – they are not colorful in plain-text log file), to keep track what the script was trying to do and where had it failed. I also make use of PowerShell transcript log capabilities, but you can easily turn transcripting off.

Disabling vmtools time synchronization is only one possible use case for this script, in fact you can use it to manipulate any of virtual machine advanced settings, in scenarios like vm security hardening etc.
Just know names of parameters to change and values you want to set then save them in adv_settings_list.csv file and you are ready to go.
Well… you should probably be careful with settings that require Guest OS support, like vMemory HotAdd or vCPU HotPlug capabilities 🙂

To be honest – I tried to experiment with New-AdvancedSetting cmdlet a little and tried to use it also to modify “not-so-advanced” settings. For example I tried to modify ethernet0.virtualDev parameter (type of first vnic for virtual machine that is stored in .vmx file) so that all my vms use vmxnet3 but it failed (obviously *-AdvancedSetting cmdlets weren’t build to change “standard” parameters but I still wanted to give it a try 😉 ).

OK, technically the cmdlet didn’t fail, it hasn’t returned any error, even displayed the new value (vmxnet3) for ethernet0.virtualDev parameter but “in reality” nothing has changed, so it looks like “standard” properties of virtual machine object are protected from being modified by *-AdvancedSetting cmdlets.

I hope you find this script useful, feel free to share and provide your feedback!

Sebastian Baryło

Successfully jumping to conclusions since 2001.

  • StanJ

    Hi Sebi, Artur, this is ofc useful bit of work but you are not sharing the risks coming from using it?!

    As I see it if you will run this script across your environment it might be useful but quite dangerous if you (as 99% of the population) would be using AD authentication and you would happen to have only 1gbit links. The reason for my thinking is that if you will start vmotions the time inside of the VM is being slow down to allow vmotion to happen. Once the time difference between AD and the time inside of the VM would exceed defined limit on AD (I reckon by defaut it was 5 mins but not sure about this atm) the VM will be kicked out of the domain. Using vmtools based time sync is useful because every time after the vmotion is finished the time inside of the VM is being synced and therefore the difference between AD and the VM is very low.
    Somebody could point out at this point that thats why you have external time sync – well guess again you don’t 🙂 External time source is syncing time only in predefined time intervals, like every hour/day or else. Therefore if you would be unlucky enough you can have quite few issues caused by disabling the time sync function.
    I’m not trying to critice, just add this bit for people who will be using the script to be aware about it and consider this in their designs and configurations 😉

    • sbarylo

      Hi Stan, thanks for pointing this out!
      This script is actually meant to be a “general tool” to set advanced vm settings and I wanted to use time synchronization as an example only.
      I pointed out (but probably not stressed it enough :/ ) that disabling vm tools time synchronization is useful for some scenarios only (In cases I know it was because of heavy load caused on vsphere hosts by backup tools using snapshots on SAN that is not VAAI capable). It is not that recommend this change for everybody (and thanks again for opportunity to explain this) – I’m just providing a tool if you need to execute such change 😉
      I probably should set only first four options to 0 (that would turn off time synchronization for snapshot events only)
      Not quite sure what do you mean by time slowing down inside vm during vmotion, indeed as of vsphere 5.1 the machine is “slowed down” – this is done by inserting idle cycles for vCPU, so vm becomes less “active” but it doesn’t automatically mean the time becomes out of sync (the way I understand this at least 😉 )

    • Hey Stando – valuable comment – as always. Situation you’ve mentioned might happen when you need to vMotionsnapshot Monster and memory intense VM’s – 64GB RAM+. If so, you should consider if 1Gbps “wide” enough for Monster VMs ? Probably not 🙂 10Gbps would be the way to go. If yes then you should think to decrease default interval time sync with external source to avoidmitigate risk you’ve mentioned.
      Definitely – time sync with host brings more problems than benefits, especially in situation where is high resource oversubscription.

  • Pingback: Newsletter: July 27, 2014 | Notes from MWhite()

  • Pingback: PowerCLI script to report and change host NTP settings - VMwaremine - Mine of knowledge about virtualization()