I have searched the internet high and low for some information on this error, the virtual machine fails at 82% during host migration.
No snapshots were attached to the server, however there were a large number of .vmsn files in the root folder. I have had problems backing up that server using vDR because it used to fail on creating the snapshot. Apparently these files are created even though the backup was failing which accumulated over time, files aren’t being marked for deletion.
Going back to vMotion, some of the information recorded on the web is about misconfiguration of VMFS ID’s depending on how you assigned the name to the datastore and how consistent is that name within your virtual environment. ESX assigns a hexadecimal value based on the name you assign to the datastore. For a successful vMotion, each shared datastore should have the same hexadecimal representation on each ESX host and that can be checked by running vdf –h on the console on each host.
The problem was solved by doing a storage vMotion to another shared datastore and then performing host vMotion which worked successfully. There is another way which entails disconnecting the shared datastore and re-mapping it again. I haven’t tried this myself by it worked for some people with similar issue. The latter will cause some downtime since you have to disconnect the LUN and reconnect it again which means shutting down all your effected VM’s.
SysCloud.dev 