EDIT: VMware has now released patches that prevent this issue from occurring. Follow the link to KB58715 below for links to the patches for vSAN 6.6 and 6.7 respectively.

Note that the patch can’t repair VM disks that have already been corrupted. Contact VMware Support if you suspect any corruption. They also have a tool that can VMs that are potentially impacted, and it’s recommended that this tool is run before installing the patch.

VMware has released KB article 58715 stating that there is a risk (under “very specific conditions”) that VM disks (VMDKs) might get corrupted (“potential data inconsistency”).

This is only for customers running vSAN 6.6 and later (which ships with ESXi 6.5.0d and later), and there is currently (as of 2018-09-26) no solution/patch released.

There is instead a workaround that might avoid the problem from occurring (although it seems like some people think it doesn’t eliminates it completely).

The workaround is to change an advanced setting on each ESXi host. The setting doesn’t require any reboots, and will automatically get activated within 60 seconds. The easiest way to apply the configuration change is through PowerCLI.

Simply run the following one-liner (after connecting using Connect-VIServer as usual). It will ask for the cluster name and apply the setting to all ESXi hosts in that cluster. (We do recommend you test this change on a limited number of ESXi hosts before rolling it out on all ESXi hosts)

Foreach ($VMHost in (Get-Cluster -Name (Read-Host “Cluster Name”) |Get-VMHost)) {Get-AdvancedSetting -Entity $VMHost -Name VSAN.ClomEnableInplaceExpansion | Set-AdvancedSetting -Value ‘0’ -Confirm:$false}

Since the bug appears on VMDKs that have been expanded, we also recommend caution when expanding. Postpone any expansions (if possible) until a bug fix is in place, and make an extra backup before performing the change.

Do keep an eye out for the patch, and test/install it as soon as possible if you’re running vSAN 6.6 or later.