- Unable to contact the MKS
- vMotion began failing
- Could not SSH to host or login to console via direct access such as iDRAC
In this support request, just before asking the customer to reboot all of his hosts (with 400 vms!), he was able to view System Logs via iDRAC and we saw:
“Cannot create file ################## for process hostd-worker because the inode table of its ramdisk (root) is full”
This was repeated a number of times. A-ha! That was our eureka moment! That lead us to KB article: ESXi 5.1 host becomes unresponsive when attempting a vMotion migration or a configuration change (204070)
The article resolved the issue, the problem having been cause by exhausted iNodes.
We wanted to highlight this to everyone because issues like this can be hard to get to the root cause of due to difficulties logging in to the host.
vMotion failing at 13% seems to be the signature symptom and if you search our Knowledgebase using quotes “vMotion fails at 13%”, you will find the article.
Those of you using Blade servers with no Scratch partitions configured might be particularly susceptible.