Ah, the subtleties of upgrading a vSphere environment – tackle the vCenter, tackle the hosts, and then take care of the VMware Tools and Compatability of the VMs themselves. It’s not rocket science but for some reason, I always seem to run into an issue somewhere along the line. This time, it was during the VMware Tools installation on a subset of VMs, running on a couple specific hosts. VMs running on 4 out of the 6 host cluster were updating their tools just fine and dandy – but on the other two hosts, no matter what I did I was receiving this crazy vix error 21012 message when trying to run the automatic tools update on the VMs which resided on them…
“Failed to copy the VMware Tools installation image to the guest operating system. Vix Error Code 21012”
After a little googling and reading of KBs my spidey senses were pointing me towards the hosts possibly losing access to the location where the VMware Tools images were stored – however after poking around everything within the /productLocker folder (where the tools are hosted) seemed fine. – So what gives? Why can vSphere not “copy” the image like the error says? With that in mind, I hit the logs. Looking at vmware.log (located in the same folder as the vmx) of some of the VMs in question I started to see a pattern. Each VM that was having issues on the host was a Windows VM, and it also had the following log entry present…
|
1 |
2018-01-31T13:29:25.088Z| vcpu-0| I125: ToolsISO: Error hash mismatch at offset 0x3c000, expected hash [ibEwgU5hIKctO24kIyqkcc7jsVs0qUQGo+Upk6X+A84=], but found [nntrC+MRVREKgiFuy3f3hRYqnAUP599T8W4x/3vhOQo=] |
Ahh – so there’s my issue! For some reason, the hash on the windows.iso located on those hosts were different than what was expected of the VMs. Migrating the suspect VMs to one of the working hosts and upgrading worked fine. So the answer – simply copy the windows.iso, along with its associated sha and sig files from working host to the host which is failing. For reference, the directory hosting these files is below…
/productLocker/vmtools/
Go ahead and overwrite the original windows.iso files on the target host (backup if you are the worrisome type) and try your upgrade again. This is what solved this mysterious vix 21012 error for me. Now I know this isn’t the most technical of posts, yeah, it’s simply copying files – but after not finding any solutions around vix error codes and VMware Tools on the internets I thought I would try and get this one out there for those who may be poking around for something in the future! Once again, Thanks for Reading!
