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:

Nexenta OS Kernel Panic

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:

2014-03-11_135437

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!

If you like this post, please share it!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.