Hi Manickam,
Note:The datastore which is having the problematic VM is a NFS datastore.
Outch, that seems to be it. KB Article Changed Block Tracking (CBT) on virtual machines states:
For CBT to identify altered disk sectors since the last change ID, the following items are required:
...
- I/O operations must go through the ESX/ESXi storage stack. So NFS is supported, as is RDM in virtual compatibility mode, but not RDM in physical compatibility mode. Of course VMFS is supported, whether backed by SAN, iSCSI, or local disk.
...
Note that they require a change ID for this to work. Further down it reads:
For CBT to identify disk sectors in use with the special "*" change ID, the following items are required:
- The virtual disk must be located on a VMFS volume, backed by SAN, iSCSI, or local disk. RDM is not VMFS
My interpretation of this is the "*" is not supported on NFS volumes. So if the disk is located on a NFS volume you will have to backup the entire disk. To check whether you problem is really related to the "*" on NFS volumes you could try to invoke QueryChangedDiskAreas via the MOB but specify a concrete changeId. If it works with the concrete Id the "*" on NFS volumes restriction is suggested to be your issue.
To check whether the disk in question is located on a NFS volume I propose using property chain
VirtualDisk.backing(VirtualDeviceFileBackingInfo).datastore.summary.type = vmfs | nfs | cifs | vfat
Please let me know whether things are working out.
--
Thomas G.