Virtual Machine is consistently going into RPO Violation state

Products

• VMware Live Recovery
• VMware vSphere ESXi

Issue/Introduction

Symptoms:

• VM is constantly going to RPO violation state.
• Clicking on resume starts the replication and moves to error state the next day.
• In the vmkernel.log file, you see errors reported on the source host where VM is running:

2018-02-26T01:00:54.535Z info hostd[76FC1B70] [Originator@6876 sub=DiskLib opID=5cadf383] DISKLIB-CTK : Could not open change tracking file "/vmfs/volumes/553fb406-36020308-2a22-xxxxxxxxx/SQL10/SQL10-ctk.vmdk": Change tracking invalid or disk in use.2018-02-26T01:00:54.569Z info hostd[761F2B70] [Originator@6876 sub=Hbrsvc] ReplicationScheduler: stats updated for (groupID=GID-fae268e8-806e-4194-8c6e-xxxxxxx): last duration was 652s, bandwidth was 10.89 MB/s; estimated duration is now 782s, estimated bandwidth is 10.89 MB/s.

2018-02-26T01:00:54.633Z warning hostd[76FC1B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/36020308-2a22-xxxxxxxx/SQL10/SQL10.SQL10.vmx opID=5cadf383] Could not determine change ID of virtual disk /vmfs/volumes/36020308-2a22-xxxxxxxx/SQL10/SQL10..vmdk because change tracking information is not available: Change tracking invalid or disk in use

• In the Hostd.log file, you see errors similar to:

Could not open change tracking file "/vmfs/volumes/553fb406-36020308-2a22-1458d052cc20/SQL/SQL10.1-ctk.vmdk": Change tracking invalid or disk in use.

2018-02-26T01:00:54.419Z warning hostd[77240B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/553fb406-36020308-2a22-xxxxxxxx/SQL10/SQL10.vmx] 

Could not determine change ID of virtual disk /vmfs/volumes/36020308-2a22-xxxxxxxx/SQL10/SQL10..vmdk because change tracking information is not available: 

Change tracking invalid or disk in use
 

Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

Environment

VMware vSphere Replication 8.x
VMware vSphere Replication 6.x

Cause

This issue occurs because there is a corrupted .ctk files on source the VM.

Resolution

To resolve this issue:

1. Power off the source VM.
2. Browse the datastore where source VM is running.
3. Create a Delete folder in datastore directory.
4. Move all the .ctk files to that Delete folder.
5. Power on the VM and reconfigure for replication.

NOTE: If the affected VM was configured for backup using any third party software, performing the preceding steps will result in full backup to be initiated by the backup software instead of incremental backup.