What is CBT?

Virtual disk block changes are tracked from outside virtual machines, in the virtualization layer. When software performs a backup, it can request transmission of only the blocks that changed since the last backup, or the blocks in use. The CBT feature can be accessed by third-party applications as part of the vSphere APIs for Data Protection (VADP). Applications call VADP to request that the VMkernel return blocks of data that have changed on a virtual disk since the last backup snapshot.

excerpt from VMware KB 1020128

This feature is typically used by third-party applications for virtual machine backups. The feature may be enabled by those backup solutions via integration with the vSphere API. Virtual machines that have CBT enabled will show configurations in the VMX file:

One entry in .vmx files: ctkEnabled = “TRUE”
Per virtual disk in .vmx file: scsix:x.ctkEnabled = “TRUE”

You can see these options in vCenter. Edit Settings > VM Options > Advanced > Edit Configuration

Change Block Tracking and HCX

PAST:

In the earlier versions of HCX, CBT-enabled virtual machines were not supported. CBT would cause the virtual machine migration to fail. A user that ultimately wanted to migrate the virtual machine with HCX would need to go through the process of powering off the virtual machine, removing the CBT feature, and then power on the virtual machine for HCX migration (or use the Cold Migration option).

PRESENT:

The current versions of HCX, the CBT scenario, when CBT is detected, the HCX migration interface gives this warning:

The effect is that virtual machines can be moved to the destination, but the CBT settings will not follow. This is true for HCX Bulk, Cold/vMotion and RAV migration types. HCX will remove the CBT filter from the virtual machine (subsequently CBT state is lost). It should be taken into account that restarting CBT at the destination means change tracking would be happening from scratch.

This behavior should be accounted/planned for with intra-Site migration projects that will leverage the same backup solutions once the virtual machine is moved to the destination.

It may be necessary to plan per-VM CBT changes as a post-migration activity, or it may be necessary to allow the backup solution to re-enable CBT. Test the process with your specific backup solution.

Additional Info

Because CBT behaviors may impact how backups are managed during a migration project, here are a couple of additional points of consideration in the context of migrations and backups:

• It may be optimal to stop backups prior to migration to prevent unintentionally saturating the HCX network extension paths with site to site backup traffic. Depending on backup traffic paths before and after a migration, they may need to be reconfigured.
  
• The User Guide states:
  Replication Assisted vMotion creates two folders at the destination site. One folder contains the virtual machine infrastructure definition, and the other contains the virtual machine disk information. This is normal behavior for RAV migrations and has no impact on the functionality of the virtual machine at the destination site.
  While this doesn’t impact virtual machine functionality, it may impact third party backup solutions. I would generally recommend for this to be considered/tested during POC or in the pre-production migrations.

References:

Understanding HCX vMotion and Cold Migration
Understanding HCX Replication Assisted vMotion
VMware KB 1020128 – Change Block Tracking (CBT) on Virtual Machines
VMware KB 1031873 – Enabling or Disabling CBT on Virtual Machines

—
Gabe