Error "Disk size reported by storage (VASA provider) is inconsistent" during Storage vMotion

Products

• VMware vSphere ESXi

Issue/Introduction

• Storage vMotion fails at approximately 35% completion, or shortly after starting.
• Migrating a virtual machine (VM) across datastores or between ESXi hosts without a shared datastore results in a failure with errors similar to:

  Failed waiting for data. Error #########. Connection closed by remote host, possibly due to timeout.

  or

  Error encountered while unstunning the virtual machine for Storage vMotion.

• When reviewing the /var/run/log/vmkernel.log of the ESXi host where the VM is running, the following error stack can be observed:

  <timestamp> cpu##:###)Hbr: 3561: Migration start received (worldID=###) (migrateType=1) (event=0) (isSource=1) (sharedConfig=0)
  <timestamp> cpu##:###)MigrateNet: 1751: ### S: Successfully bound connection to vmknic vmk1 - '###.###.###.###'
  <timestamp> cpu##:###)MigrateNet: vm #######: 3263: Accepted connection from <::ffff:###.###.###.###'>
  <timestamp> cpu##:###)WARNING: SVM: 5114: scsi0:2 Disk size reported by storage (VASA provider) of 1084479242240 bytes is inconsistent with the size reported by vmx (912680550400). Failing migration.
  <timestamp> cpu##:###)WARNING: Migrate: 6145: ################### S: Migration considered a failure by the VMX. It is most likely a timeout, but check the VMX log for the true error.
  <timestamp> cpu##:###)WARNING: Migrate: 282: ################### S: Failed: Migration determined a failure by the VMX (0xbad0092) @0x############
  <timestamp> cpu##:###)Hbr: 3655: Migration end received (worldID=###) (migrateType=1) (eve..

Environment

• VMware vCenter Server 7.0.x
• VMware vCenter Server 8.0.x
• VMware vSphere ESXi 7.0.x
• VMware vSphere ESXi 8.0.x

Cause

This error occurs when the disk size in the descriptor file of a virtual disk is different from the size of the disk reported by the VASA provider.

Resolution

Identifying the issue

• Start with finding out the actual size of the disk.
  Going with the example above, the provider reports it as 1084479242240 bytes, aka 1010 GByte:

  1084479242240 bytes / (1024*1024*1024) = 1010 GByte

• So the actual size of the virtual disk is 1010 GByte.
• Next, review the VMDK descriptor file and look for the line starting with RW:

  # Disk DescriptorFile
  version=3
  encoding="UTF-8"
  CID=86022472
  parentCID=ffffffff
  createType="vmfs"
  
  # Extent description
  RW 1782579200 VMFS "vmname-flat.vmdk"
  
  # Change Tracking File
  changeTrackPath="vmname-ctk.vmdk"
  
  # The Disk Data Base
  #DDB
  
  ddb.adapterType = "lsilogic"
  ddb.deletable = "true"
  ddb.geometry.cylinders = "110960"
  ddb.geometry.heads = "255"
  ddb.geometry.sectors = "63"
  ddb.longContentID = "3f8978d734b845d9fbfaa51786022472"
  ddb.toolsInstallType = "1"
  ddb.toolsVersion = "11333"
  ddb.uuid = "60 00 C2 9e 66 a9 f3 30-00 b9 f7 36 2a 88 23 0d"
  ddb.virtualHWVersion = "9"

• The value in this line is the number of sectors in the virtual disk.
• Sector size is 512 bytes, therefore multiply the value in the descriptor by 512 to get the actual size value in bytes:

  1782579200 sectors * 512 bytes = 912680550400 bytes

• Again divide by 1024^3 to get the size in GBytes:

  912680550400 bytes / (1024 * 1024 * 1024) = 850 GByte

• So according to the descriptor file, this disk is 850 GBytes, but the VASA provider actually reports it to be 1010 GByte, hence the error occurs.

Resolving the issue

To fix this issue, update the VMDK descriptor file with the actual size of the virtual disk as it is being reported by the VASA provider.
For this, follow the steps below:

1. Open the vSphere Client and login with an administrator account
2. Find the problematic virtual machine, right-click it and select "Edit Settings" to open the VM settings wizard
3. Select the disk with the invalid size. If the VM has a larger number of disks attached, expand the "Hard Disks section" and identify the disk.
4. Replace the current disk size (going by the example above this would be 850 GB) against the size reported by the VASA provider according to the vmware.log (for our example enter 1010 instead of the 850), then click on [ OK ] to close the wizard:
   

It should now be possible to successfully migrate the virtual machine.

Additional Information

Similar issues might occur when there is a corruption on the underlying storage. In such cases, it will not be possible to solve the problem with the steps above.
In this situation a restore of the virtual disk or the whole virtual machine from its last know good backup is needed, or a recreation from scratch (after making sure that the corruption has been fixed).