I recently came through an issue during a vMotion between vCenters part of the same SSO domain. A colleague of mine just needed to move this vm from one vcenter instance to another one using the “Change both compute resource and storage” option or the usual called Shared Nothing vMotion.
The version of the source and target vCenter is 7.0u3g
So apparently a super easy task but here the issue, during the first phase of the vmotion “the check” of source and destination he got this error message:
A general system error occurred: Connection reset by peer: The connection is terminated by the remote end with a reset packet. Usually, this is a sign of a network problem, timeout or service overload.
The fact that the VM was even in power off status was not helping to much, but we we’re sure no network problem was present on the environment because both vCenter and relative ESXi hosts can communicate to each other without issues. So we start searching on the web and one of the first results was this KB:
https://kb.vmware.com/s/article/91002
The resolution on the KB is the creation of two advanced settings on the target venter:
- Add the below vCenter advanced settings to increase the maxDocSize to 50MB and maxElements to 1 million elements
config.vmomi.soapRequest.maxDocSize = 50000000
config.vmomi.soapRequest.maxElements = 1000000
In our case even after adding this two advanced settings the problem of doing vmotion across the two vcenter persists with different UI message
We also start listening the vpxd.log and here we saw the error message immediately after try to trigger the vMotion through the vSphere UI.
THE SOLUTION:
In the end looking at the log message on the vpxd.log is clear that the value “1000000” is not enough for the config.vmomi.soapRequest.maxElements. So after double it to 2000000 and restart the vcenter services the vmotion now is able to go through the first steps and return the message “Compatibility checks succeeded“. This we think is caused only when you have a Big inventory with thousands of objects on the source vCenter so it needs to pass so many information to the target vCenter that are not enough with the default configuration of the KB.
Thanks to my colleague Damian Janczur for the precious help and support to fix this!
