VMware tools installation fails with the error below...
Unable to install VMware Tools. An error occurred while trying to access image file "/usr/lib/vmware/isoimages/windows.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.
Troubleshooting
SSH to the Vmware host reveals that the /usr/lib/vmware is not accessible
ls -l reveals that the isoimages folder is a symbolic link to /productLocker/vmtools/
cd /productLocker is inaccessible
/vmfs/volumes is missing Hypervisor3
The ESXi partition table can be checked using the command fdisk -l
There is a Warning for partition table 8
Warning: ignoring extra data in partition table 8
And the file system for mpx.vmhba32:C0:T0:L0p8 is Unknowm
/dev/disks/mpx.vmhba32:C0:T0:L0p8 ? 740786 1480957 757935405 5a Unknown
mpx.vmhba32:C0:T0:L0p8 should be the scratch disk location.
The fix
It is recommended that the persistent scratch location be set for ESXi
Configuring persistent scratch location using the vSphere Client
You can configure persistent scratch space for ESXi using the vSphere Client:- Connect to vCenter Server or the ESXi host using the vSphere Client.
- Select the ESXi host in the inventory.
- Click the Configuration tab.
- Click Storage.
- Right-click a datastore and select Browse.
- Create a uniquely-named directory for this ESX host (eg,
.locker-ESXHostname) - Close the Datastore Browser.
- Click Advanced Settings under Software.
- Select the ScratchConfig section.
- Change the
ScratchConfig.ConfiguredScratchLocationconfiguration option, specifying the full path to the directory. For example:
/vmfs/volumes/DatastoreName/.locker-ESXHostname - Click OK.
- Put the ESXi host in maintenance mode and reboot for the configuration change to take effect.
Once the scratch location has been set you can run the current ESXi 4.1 update 2 patch this will recreate the Vmware tools installation iso in the scratch file location.
Once the patch has applied reboot the host.
You can check that the vmtools iso's have been created by browsing the persistent scratch datastore.
You will then be able to deploy Vmware tools
good Document...
ReplyDeleteI had this exact problem recently on ESXi 5.1.0
ReplyDelete1 of 3 hosts was working correctly. If I migrated the VM to one of the other 2 hosts, vmtools would not install due to that error message.
After enabling SSH on all hosts, I compared host 3 to hosts 1 and 2 and found the problem. The symbolic link from locker/ > store/ was non-existent on the root. locker/ was its own folder. I simply renamed locker/ to locker.old/ and recreated the symbolic link to store/ and the issue was resolved. I could now CD into productLocker/ as it correctly mapped to my store drive.
I found the problem by working backwards. /usr/lib/vmware/isoimages was not accessible but /usr/lib/vmware was accessible. I could see from ls-l in /usr/lib/vmware that isoimages/ was a symbolic link to /productLocker. I can see on the root that productLocker/ was a symbolic link to /locker/packages/5.1.0. I then saw /locker was a symbolic link to /store. Well if that symbolic link did not exist, then the entire chain of links is broken; so repairing that symbolic link resolved my issue.
I'm posting this here in hopes that this is an easier resolution than recreating the scratch directory and implementing a patch to rebuild the iso images in the store directory. I did not have to reboot my hosts or put it into maintenance mode or take any production VMs offline.
For the noobies out there this is the command set I used after SSH into the host:
Deletecd / #this command changes directory to root
cp -R locker/ locker.old/ #this command copies the folder locker/ to locker.old/ recursively
rm -rf locker/ #this command removes the directory and contents of locker/
ln -s store/ locker #this command creates a symbolic link of store/ (the target) to locker/ (link)
Note: To SSH into host, you need to enable SSH which is disabled by default. After enabling SSH you will see a warning status on your host in vSphere with NO ALARM. This is simply just saying this host is more 'vulnerable' because SSH is turned on (which is strictly considered a troubleshooting tool). To turn SSH on, log into ESXi on your host using a local terminal to your server and go to "Troubleshooting Options" and enable SSH. Remember to disable SSH to get rid of the warning icon on your host in vSphere.
King:
DeleteVery timely, as I ran into this today. Thanks - fixed me right up. In my case, I think the problem started when I had a VM that couldn't disconnect from its virtual CD, and I had to force it closed in order to dismount and re-mount a datastore. At least, that's the most recent "event" I can recall. Also possible that a tools install didn't complete properly - in my case, I noticed this when I tried to install tools on a new VM, and it couldn't mount the ISO. Anyway, cheers.