For my current job I work a lot with NexentaOS (an OpenSolaris based distribution) VMs. Today I had to validate the procedure to upgrade VMware Tools on such VMs for a customer and came across some interesting issues.
Follow me…
I uploaded the Solaris tools TGZ on the VM (they come without a CD-ROM drive and I did not want to mess up with the HW configuration), decompressed it and started the vmware-install.pl script as usual.
This is where the problems began: the script detected an old version of the tools and asked permission to perform their uninstallation, which I duly granted. In a matter of milliseconds I was presented with this nice kernel panic message:
Then I remembered a similarly odd behavior of Nexenta VMs when rebooted/halted: most of the time they panicked and dumped in a similar fashion and I started pondering whether or not the two occurrences were linked. I googled up a bit and found a post on VMware Community forums about a similar issue, involving another OpenSolaris derivative, specifically OpenIndiana. Apparently these VMs panicked on vSphere 5.0+ when rebooted/halted, except than when they were configured with exactly two vCPUs. Needless to say, my test VMs were configured with one single vCPU.
I shut down the VM, reconfigured it with 2 vCPUs and attempted the uninstallation of the old tools once again: it worked flawlessly. The process continued without a hitch until the point when the vmware-config-tools.pl script is executed: the script stopped immediately, complaining that the SUNWuiu8 package was missing. After another Google search I learned that this package is Solaris-specific and it doesn’t exist on NexentaOS, nor is indeed required to complete the tools’ configuration. Therefore the vmware-config-tools.pl script could be safely edited in order to bypass the check (credit: http://blog.solori.net/tag/sunwuiu8/).
Just comment the following lines in the script:
After making the changes, the script completed successfully and the tools were upgraded to their latest version. Once done, I reverted the HW configuration of the VM to its original state (i.e. with one single vCPU).
I hope I have spared my customer some serious headache and some unnecessary downtime!