An error occurred while communicating with the remote host. Migrating Virtual Machine active state
vmware.log
file, you see the entries similar to:
[YYYY-MM-DDTHH:MM:SS] Worker#1| I120: SVMotion: Enter Phase 8
[YYYY-MM-DDTHH:MM:SS] Worker#1| I120: Disk/File copy started for /vmfs/volumes/528a4a82-########-####-1cc1de1cf19c/VM/VM.vmdk.
[YYYY-MM-DDTHH:MM:SS]| vcpu-0| I120: HBACommon: First write on scsi0:0.fileName='/vmfs/volumes/5846c857-######-####-9cb65488f208/VM/VM_2.vmdk'
[YYYY-MM-DDTHH:MM:SS]| vcpu-0| I120: DDB: "longContentID" = "0f27513e4da5cb398a0000000000000" (was "113f5adc309c000000000000000000")
[YYYY-MM-DDTHH:MM:SS]| vcpu-0| I120: DISKLIB-CHAIN : DiskChainUpdateContentID: old=0x14e577b, new=0x7fdc3ae2 (
0f27513e4da5cb398a0000000000000
)
[YYYY-MM-DDTHH:MM:SS]| vcpu-2| I120: HBACommon: First write on scsi0:1.fileName='/vmfs/volumes/528a4a82-######-####-1cc1de1cf19c/VM/VM.vmdk'
[YYYY-MM-DDTHH:MM:SS]| vcpu-2| I120: DDB: "longContentID" = "c40278c760000000a96888f37e2b0" (was "a234a3800000000c063f051ad2")
[YYYY-MM-DDTHH:MM:SS]| vcpu-2| I120: DISKLIB-CHAIN : DiskChainUpdateContentID: old=0x3f051ad2, new=0x8f37e2b0 (c40278c7604e00000000888f37e2b0)
[YYYY-MM-DDTHH:MM:SS]| vmx| I120: Migrate: Cancel requested.
/var/log/vmkernel.log
file, you see the entries similar to:
[YYYY-MM-DDTHH:MM:SS]|
cpu11:33524)ScsiDeviceIO: 2651: Cmd(0x439e01216200) 0x83, CmdSN 0x782e77 from world 4095701 to dev "naa.6
" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0xa 0xd 0x1.########
028000008e0000
[YYYY-MM-DDTHH:MM:SS]|
cpu11:33524)ScsiDeviceIO: 2651: Cmd(0x439e0127bd00) 0x83, CmdSN 0x782e78 from world 4095701 to dev "naa.6########
028000008e0000" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0xa 0xd 0x1.
0xd Aborted commands is expected behavior for XCOPY commands while sVmotioning a VM from one storage array to another storage array as XCOPY is not supported across storage arrays. However we should switch to software datamover to migrate the VM.
See KB Frequently Asked Questions for vStorage APIs for Array Integration for more details.
If the sVmotion is failing collect the logs from the source and destination hosts for further analysis.
You can try disabling XCOPY to see if the sVmotion completes:
esxcli system settings advanced set --int-value 0 --option /DataMover/HardwareAcceleratedMove
If the sVmotion completes with XCOPY disabled collect a new set of logs from source and destination so we can determine why we're not switching to software datamover