When I powered downed one of my production VMs i got the below message, upon prompt i selected "yes" and it allowed the shutdown task to complete; i was able to power on the VM shortly after. I am confussed what the message means, since this is production environment i need to make sure this is not a red flag that can lead a complete outage. I am litterary the one-man team here to handle this, also because of budget limitation we cannot afford to renew our support agreement with VMware. I have ESX 3.0/ VC 2.0 platform. Any help on this issue will be greatly appriciated.
"Error connecting: VMX connection handshake failed for mks of /vmfs/voluums/UUID/TESTVM/TESTVM.VMX Do you want to try again? Yes/No?"
Since you were able to power on the VM shortly after, I am thinking that ESX could not get a lock on the file, and was able to when you tried again. You may want to check your vmkernel and vmkwarning files to be sure. How many VMs are you running on that particular VMFS volume? If you have a lot, then you may run into this again.
mks as I recall stands for Mouse Keyboard Screen - basically the ability to present the VM Console screen - basicall interruptin the VM Console session - by attemtping the reconnect allowed it to cllose -
Is there something specific I should look for in the vmkernal/vmkwarning files? As of now now we have one iSCSI LUN thats being served to two ESX hosts, the LUN houses 34 VM(s). The ESX host(s) were built with default settings (when VMware ISO was installed).
Look for scsi lock / reservation problems or warnings. Other than that, try not to load more than 10-20 VM's on any one particular VMFS partition.
It is not a hard limit but a performance limit - with 20+ VMs hitting the same LUN you could be saturating the storage -
I just experienced this same problem on 3.5 Update 4. I looked for a hung process, restarted the services, rebooted the ESX server, cloned the VM (both automatically and manually) and was unable to get the VM to power on. After diffing the VMX file with a known good VMX file that did power on I learned that the bad VM was configured as RHEL5x32 while the good VM was configured as RHEL5x64. After switching the VM to RHEL5x64 it booted successfully. I hope someone finds this helpful.