Unable to install VMware Tools – no such file or directory

You know those issues that just sit in the background for a while until you can’t take it anymore and have to work them out. You have to fix them. You just have to make them stop?!? (Maybe not, heh). This problem was one of those ones.

For a number of our VMware guests, when being a good guy and installing VMware Tools, this error would come up.


Call "VirtualMachine.MountToolsInstaller" for object "gb-oradec1" on vCenter Server "Sydney - vCenter 4.1" failed.
Unable to install VMware Tools. An error occurred while trying to access image file "/usr/lib/vmware/isoimages/solaris.iso" needed to install VMware Tools: 2 (No such file or directory). If your product shipped with the VMware Tools package, reinstall VMware ESX, then try again to install the VMware Tools package in the virtual machine.
The required VMware Tools ISO image does not exist or is inaccessible.


Seems like a bit of an overreaction to try to get you to reinstall ESXi.

Now I use the very cool repo/unmanaged solution for the majority of our guests, since they run RHEL 6. If you don’t know about this check it out here. If you use RHEL kickstart, it is trivial to make new guests come out with tools installed and the tools repo enabled. Anyway, enough gushing, just check it out if you use RHEL on VMware.

I should note before getting into this, that I am running ESXi from a USB key. This problem seems to be related to the backend media that ESXi is installed on, so if you’re on different media then your mileage may vary. I’d be interested to hear from anyone who sees this error on a non usb platform.

Following the path given in the error on a good system (/usr/lib/vmware/isoimages/) leads you to a symlink called /productLocker/vmtools/ , which in turn is a symlink to /locker/packages/4.1.0/ . No idea why this has to be so complicated, but there’s probably a reason.

After some more digging (tracking back through the innumerable symlinks), it seemed like the partition below was missing.

/dev/disks/mpx.vmhba32:C0:T0:L0p8


On a bad system

This is from a good system, notice the last partition

The mount point for this partition seems to be

/vmfs/volumes/Hypervisor3


Which was missing too. /vmfs/volumes/Hypervisor3 is a symlink back to the volume id of the partition. In the end, I just couldn’t figure out a pattern. Some hosts were fine and had the /productLocker symlink, and a bunch didn’t have it. Consequently, I have no idea how this happened to us, or how to prevent it, but let’s just get on and fix it. The solution seems clear, let’s just make a new partition, format it, and dump the files from a working system on there.

Partitioning the disk as FAT16 was easy (fdisk ftw), but formatting the disk was proving difficult. ESXi doesn’t seem to contain a working version of mkfs.vfat on it, and vmkfstools won’t do FAT16. (Also tried a mkfs.vfat binary from RHEL 5; didn’t work either). Of course, I could’ve pulled the usb key out, and fixed it up on a linux box, but I found an easier way.

To summarize, you create a scratch disk directory for the host inside some of your shared storage, and then point the host to it. After rebooting the host all the symlinks point to the new scratch location on your datastore. For complete steps on how to do it read this. VMware also recommends this as a best practice since your ESXi scratch disk area is now not on a limited ram disk.

Ok. Great. Now ESXi has a place to put VMware Tools. But how do you get the Tools files on there? I found the easiest way to do this was to apply a VMware Tools fix from VUM (VMware Update Manager). If you don’t use VUM I’m sure you could manually download the fix and apply it on your host using esxupdate. The latest VMware Tools fix is here. And that’s it – problem solved!