You have just rebooted your ESXi 4.1 host, logged in and notice that the inventory no longer shows up and presents the error:
The virtual machine inventory file on host hostName.domain.com is damaged or unreadable.
I’ve searched around on the internet and was only able to find one post that referenced this error and since I had to get the environment up in a hurry, I ended up opening a case with VMware. The engineer said that this error was rare and the only reason why he knew about it was because his colleague, which happens to sit beside him, ran into this error a week ago.
This usually happens if the vmInventory.xml, which is located in the directory /etc/vmware/hostd is either corrupted or somehow has another process that has a lock on it which in turn prevents it from being read properly.
We proceeded to perform the obvious checks by trying to cat the file to see if we can read the content:
As shown in the screenshot above, we don’t get any content returned so we proceeded to double check to ensure it’s not a disk space issue by executing df -h:
As shown in the screenshot above, we did not run out of space so we issued a ls -l to see see what the file size was:
As shown in the screenshot above, the file size was listed as 0 bytes so this was when he asked his colleague what he did to correct this problem and what he was told was that he used an editor such as VI to add the line:
into the vmInventory.xml file, save it, restart the services and the inventory list came back. I proceeded to try and do this:
Just before I restarted the services, I tried to cat the file again but only saw the line I put in:
I proceeded to restart the services by executing the services.sh restart:
… but the inventory didn’t come back. At this point, I was running out of time so I told the engineer that I was going to proceed with manually adding all the VMs back via the GUI since this was a standalone server with only 10 to 15 VMs:
After I added the first VM, I tried to cat the vmInventory.xml file once more and this time saw more content in it:
This was when I believed that the file was simply corrupted so I prceeded to add the rest of the virtual machines manually.
I spoke to the engineer a bit later and he said he’s not sure what the root cause was but if it was a lock on the file by some other process, we could use the lsof (list open files) command to find out exactly what processes are may have a lock on the file.
I hope this helps anyone out there who may encounter the same problem.