Hi,
I started a svmotion and part way through (about 48% according to vCenter Server) the vCenter server reported the above error. Yet it appears that the data transfer is still going on the ESXi host. The three pieces of evidence that it is still going are :
1. The storage array's (source and destination) show i/o at a rate that is consistent with the start of the svmotion; 80MB/s read on the source and 160MB/s write on the destination,
2. The date/time stamps on the vmdk files on the destination datastore are still being updated,
3. The vmware.log file on the source datastore is being updated with these messages:
2012-08-27T17:31:31.661Z| Worker#0| Disk copy done for scsi0:8.
2012-08-28T00:10:38.773Z| Worker#0| Disk copy done for scsi0:6.
2012-08-28T01:57:21.622Z| Worker#0| Disk copy done for scsi0:5.
2012-08-28T07:45:58.863Z| Worker#0| Disk copy done for scsi0:4.
2012-08-28T14:16:53.699Z| Worker#0| Disk copy done for scsi0:3.
So the vCenter Server thinks the task is failed, but the ESXi host performing the task has not aborted/failed.
Questions:
1. Is it possible to 'reconnect' the vCenter Server to the ongoing svmotion?
2. Is it possible to safely stop the svmotion on the ESXi host?
3. Are there connection timeout values that can be adjusted on the vCenter Server so this loss of comms does not happen again?
4. What happens if I do nothing and let the ESXi host complete the svmotion?
4.1 Can I delete the files on the destination datastore,
4.2 Can I delete the defunct duplicate vm guest entry in the vCenter Server inventory.
System info:
ESXi Enterprise Plus, v5.0U1, build 768111
vCenter Server 5.0 U1b, build 804277
Storage Array : Nexsan E60 on iscsi SAN
Storage HBA : Hardware independent Emulex OCE10102
Hosts : Dell PowerEdge R720, x2
I have opened an SR with vmware, but I am hoping that the collective intelligence here will come up with some answers faster than tech support.
Cheers,
Ron