vMotion migration fails - Ubuntu 16.04 LTS (32-bit) | Failed waiting for data (Error 195887167)
My company distributes a local python web server application that runs on an Ubuntu 16.04 LTS 32-bit VMs.
We currently have 24 instances of live VMware installs. One client (running vSphere 6.7) is reporting an issue every time they update the VM host. Our VM fails to migrate to a different host when the update occurs. The image becomes corrupted and they need to run the following command to repair it:
vmkfstools -x repair <vm_name>/<vm_name>.vmdk
Here is the error we receive when we test the migration manually (apologies for the bad screenshot):
We ran a migration test with the VM powered off and the VM migrated successfully. VMware Tools is installed and updated on the VM, and we have the ability to do a clean shutdown from the ESXi web client. I'm wondering if the VM is failing to power off cleanly when the migration occurs?
In our first troubleshooting session, I only saw the first line of the error:
Failed waiting for data. Error 195887167
All the posts I found online suggested this occurs when there is an issue with the vMotion network configuration.
However, most or all of the posts indicated that this issue affected all VMs on a particular host. In our case, there are several VMs on the host (some of them are also Linux) and ours is the only one that's failing. The client IT informed me that all their hosts are virtually identical, with the same network setup and on the same subnet.
In a subsequent session, I noticed the additional lines in the error message:
Failed to establish transport connection (9): There is no VMware process running for config file <path_to_vmx>...
This message produces fewer results in google and I'm not able to piece together any patterns or helpful resolutions.
I'm wondering if anyone has run into a similar issue or can shed some light on this. If you can't already tell, I'm not a VMware expert by any stretch. I apologize for the lack of log data - please let me know if there are any specific logfiles or other resources that would be helpful to diagnose this and I can try to grab those from the client.