Over the last few years the amount of CBT related issues has decreased significantly from VMware. I remember back in my previous roles of having to deal with multiple issues and wrote some pretty heavy posts around the topic. While those posts where not popular in some circles at the time, they certainly highlighted the importance of having stable CBT code in vSphere for backup vendors to leverage as part of their solutions. The threat of corruption in backup data was a worst case scenario back then… but even more so now, given how critical data has become.

Contained in the latest patch releases for ESXi 6.0 (November) and 6.7 (last week) is a fix for the an an issue that surfaced a few months ago in relation to a very specific condition upon reverting a SnapShot where CBT data might become corrupted. ESXi 6.5 patch has not been released yet.

The VMwareKB has the information here.

For both ESXi 6.0 patch release and the ESXi 6.7 patch release, the description of the issue and the detail of the fix is listed below.

  • When reverting a virtual machine that has CBT enabled to a snapshot which is not a memory snapshot, you might see InvalidArgument error if you use the QueryChangedDiskAreas() API call. After you revert a virtual machine to a snapshot, change block tracking (CBT) data might be corrupted. When reverting a virtual machine that has CBT enabled to a snapshot which is not a memory snapshot, and if you use the QueryChangedDiskAreas() API call, you might see an InvalidArgument error. This issue is resolved in this release. With ESXi670-201912001, the output of the QuerychangedDiskAreas () call changes to FileFault and adds the message Change tracking is not active on the disk <disk_path> to provide more details on the issue.

In regards to Veeam customers, our SVP of Product, Anton Gostev highlighted the patches in his Weekly Forum Digest (which everyone should be following) and there will be an update to confirm all is well in next weeks digest when it comes to Veeam Backup & Replication working transparently with the fix from VMware.

The patch for 6.7 contains a number of additional fixes.. a lot of them centered around storage so it’s worth looking through the Resolved Issues section of the

References:

https://kb.vmware.com/s/article/71155
https://docs.vmware.com/en/VMware-vSphere/6.0/rn/esxi600-201911001.html
https://docs.vmware.com/en/VMware-vSphere/6.7/rn/esxi670-201912001.html