To work around this issue ensure there are current and valid backups of the VM/vmdk to be svMotioned and then do one of the following:
- Ensure the datastore the VM is being migrated to has the required space to accommodate the provisioned space plus the FTT in use of the storage policy
- If you have a current and valid backup of the VM/vmdk you can restore from backup to the destination datastore
- If migrating a large vmdk of 32TB or more with FTT=1 policy to another vSAN datastore change the policy to FTT=2/3 if it will allow for the size to be under the max vmdk size of 62TB otherwise you'll need to change it to FTT=0
- If going from vSAN to external storage and the datastore has enough space to accommodate the VM/vmdk provisioned space but not provisioned plus FTT follow the steps below:
- Ensure there is plenty of free space on the vSAN datastore and if there is change the vSAN Storage Policy to FTT=0.
- Wait for the resync to complete if going from FTT=2/3 to FTT=0
- svMotion the virtual machine.
Note: Keep in mind following this action plan has its risks as the VM/vmdk will no longer have redundancy which is why it's important to confirm you have backups prior to performing the svMotion.
A proactive approach is to take these considerations into perspective when planning out VM deployments on vSAN.
For more information see About the vSAN Default Storage Policy