Failed to get active blocks for disk2001. It will be backed up as a thick disk. QueryChangedDiskAreas: SOAP 1.1 fault: :ServerFaultCode [no subcode] Error caused by file /vmfs/volumes/path.file.vmdk Detail: FileFaultFault xmlns=urn:vim25 xs

Modified on Tue, 31 Oct 2023 at 11:51 AM

Symptoms


The warning might be reported during backup (VMware VADP sets).

1. "Failed to get active blocks for diskxxxx. It will be backed up as a thick disk. QueryChangedDiskAreas: SOAP 1.1 fault: "":ServerFaultCode [no subcode] "Error caused by file /vmfs/volumes/path.file.vmdk" Detail: <FileFaultFault xmlns="urn:vim25" xsi:type="FileFault"><file>/vmfs/volumes/path/file.vmdk"

2. Failed to get active blocks for diskxxxx. It will be backed up as a thick disk. QueryChangedDiskAreas: SOAP 1.1 fault



Cause

1.a The ESX backup target uses NFS storage. All disks located on NFS volumes would be backed up as thick disk ( due to lack of in-use blocks information passed by VMware Api), meaning that the whole disk would be read, not only in-use blocks, so the first backup will be slower compared to the same (non-thick eager) disk on VMFS volumes.

1.b. Mostly reported for VADP backup of VM on NFS datastore: NFS3 VMware ESXi, 5.5.0, 3116895 with VM Hardware level 8 (even after multiple CBT resets and with no vmotion)


2.a The option "Attempt to use CBT" has been selected in backup set's properties, the backup source vm contains thin or thick lazy vmdks and the CBT is broken, details are available in VMware KB 2035976.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2035976

2.b. CBT option will work with NFS datastore but it will log some warning message

2 c. The ESX backup target uses NFS storage.



Workaround

1.a. Workaround: http:kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1031106 For ESX5.5

1.b. First gen backup for all disks located on the NFS datastore reads the whole disk, instead of only active blocks. The disks of the gens with warning, will be restored as thick eager disk, regardless of the type of the original disk (from NFS4 thick provisioning is not supported and resulting restore will be thin)

2.a. Remove any snapshots available for the backup source vm and then disable and re-enable the CBT

2.b. Disable the CBT on the vm and try to backup


3. In the current implementation of the code, we do not detect the type of the volume on which the virtual disk is located. so we only log the failure of getting in-use blocks (or active blocks in Asigra terminology) so please ignore these warning in this case.


To disable and re-enable the CBT using the vSphere Client:

1. Shut down the virtual machine.

2. Remove any existing virtual machine snapshots.

3. Right click the VM, click "Edit settings", find the "Options" tab and click "Configuration Parameters"

4. Set the "ctkEnabled" value to false

5. Set the "scsi0:x.ctkEnabled" value to false for each disk of the VM in question

6. Remove or rename any files ending with the *-ctk.vmdk file extension in the virtual machine directory.

7. Power on the virtual machine.

8. Power off the VM again.


Then enable back CBT: 


9.     Right click the VM, click "Edit settings", find the "Options" tab and click "Configuration Parameters"

10.   Set the "ctkEnabled" value to true

11.   Set the "scsi0:x.ctkEnabled" value to true for each disk of the VM in question

12.   Power on the VM

13.   In the home directory of the virtual machine, verify that each hard disk contains a vmname-ctk.vmdk file.

14.   Run the backup.

c. http:kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1031106 For ESX5.5, disable the CBT on the vm and try to backup.

 



Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select atleast one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article