Old Bug in open-vm-tools and Git Commit Problem.

There is a known bug in open-vm-tools that can interference with a number of applications when we operate on a vmhgfs-fuse file system. This bug is documented as issue #90, and there are a few other discussion about this, in particular, a discussion on how to install recent release of open-vm-tools on Ubuntu 16.04 LTS since Ubuntu 16.04 LTS at this moment still ships open-vm-tools version 10.0.7 that carries this bug.

You may check your open-vm-tools version with one of many methods, such as,

vmware-toolbox-cmd -v

or

apt-show-versions open-vm-tools

If the output indicates that you have a version of earlier than 10.1.0, your version of open-vm-tools may have this bug. It causes serious problems in a few rather frequently used applications. In my case, when I use do a git commit, I would observe the following,

$ git commit -m "done something trivial"
error: bad index file sha1 signature
fatal: index file corrupt

After 5 seconds, when I try it again, the git commit is successful. As discussed in issue #90, this is the result that the tools cache file attributes and entries and causes a cache inconsistency. The 5-second delay is the waiting time before the cached items get updated.

Some also observed that this bug causes the npm install to fail.

Perhaps, the more important issue is how we may address this issue before the Linux distributors have a new version of the tools for us to upgrade to. Suggested in the discussions cited is to use a Ubuntu test PPA repository since it does not appear to be problem-free to build the tools from the source. The steps to install from the test PPA are as follows,

sudo add-apt-repository ppa:ci-train-ppa-service/3152
sudo apt-get update
sudo apt-get upgrade open-vm-tools open-vm-tools-desktop open-vm-tools-dkms

In my case, these steps lead to the successful installation of the open-vm-tools version 10.2.0.1608 (build-7253323), and it seems to work fine although some seem to observe some issues, such as, a race condition.

VMWare Tools Installer Complaining About Ethernet Driver on Linux Guests

When installing the VMWare Tools on Linux Guests, we sometimes see that the installer of the VMWare Tools complains about Ethernet drivers,

The vmxnet driver is no longer supported on kernels 3.3 and greater. Please
upgrade to a newer virtual NIC. (e.g., vmxnet3 or e1000e)

which does not necessarily mean that the Ethernet drivers are not vmxnet3 or e1000e. My experience indicates that it sometimes complains about the Ethernet driver's not being vmxnet3 or e1000e even if the driver is one of the two.

First, we can determine what Ethernet driver is loaded by using lspci command on the Linux virtual machine as follows,

lspci |  grep "Ethernet controller"

As the example below, if the output indicates that the Ethernet driver is vmxnet3 or e1000e, we can safely ignore the complain.

$ lspci |  grep "Ethernet controller"
03:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)

However, if the Ethernet driver is not one of the two, it is better to change the virtual Ethernet driver to be one of the two. VMWare has a Knowledge Base article on how to manually configure Ethernet adapter for a virtual machine. Following the article, we can configure the Ethernet driver in the steps below,

1. Power off the virtual machine
2. Locate and open the virtual machine configuration file (.vmx) for editing on the host
3. Look for Ethernet configuration, by searching "ethernet" in the configuration file
4. If you find a configuration entry as follows,

   
         ethernet0.virtualDev = "vmxnet"
         

   or

   
         ethernet0.virtualDev = "e1000"
         

   you should replace "vmxnet" or "e1000" by "vmxnet3" or "e1000e".
   
   Be aware that the above shows an example for the first Ethernet adapter, i.e., "ethernet0". If you have multiple Ethernet adapters, you should repeat the above steps for all Ethernet adapters.
   
   If you do not find a configuration entry as such, you need to add the entry to the configuration file, i.e.,

   
         ethernet0.virtualDev = "vmxnet3"
         

   or

   
         ethernet0.virtualDev = "e1000e"
         

   Repeat the step all Ethernet adapters.
5. Save the configuration file and reboot the Linux guest
6. Use lspci on the Linux guest to confirm that desired Ethernet driver is loaded.

You may wonder among "vmxnet3" or "e1000e", which one you should choose. According to this article, it appears that the better choice is "vmxnet3".

After Kernel Upgrade VMware Ubuntu Guest Hang During Boot

I am running a Ubuntu Saucy (13.04) guest and later a Ubuntu Trusty (14.04) guest using VMWare Player on Windows 8.1. What has troubled me is that the guest hangs every single time after the POST screen is shown during boot after I upgraded the kernel. I have to press "Ctrl-Alt-Del" to restart, enter "Advanced Option" from the Ubuntu boot menu and choose an old kernel to boot. I finally figured out how to solve the problem.  The hint of the solution came from my examining the VM log file. The location of the VM log file is on the VMware Player's "About VMware Player" window. From VMWare Player, you can open the window by clicking on the "Player" menu, next "Help", and then "About VMware Player". Below is an example of the "About VMware Player" window.

 

In the above example, the VM log file is at C:\Users\...\Ubuntu\vmware.log. When the Ubuntu is hangs, at the end of the VM log file, I saw some log messages similar to the below,

2014-07-22T19:21:19.299-04:00| vmx| I120: GuestRpcSendTimedOut: 

                                          message to toolbox timed out.
2014-07-22T19:21:19.299-04:00| vmx| I120: Vix: [5648 guestCommands.c:1924]: 

                                          Error VIX_E_TOOLS_NOT_RUNNING in 
VMAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest
2014-07-22T19:21:25.635-04:00| vmx| I120: USBGW: Write arbitrator op:13 len:11

My guess is that the VMware Tools is not installed and configured properly for the new Linux kernel. The solution would to reinstall the VMware Tools. Since the Ubuntu guest hangs during boot, I have to find an alternate to do it. Luckily, I can boot the Ubuntu guest into the "Recovery Mode" with the problematic Linux kernel via the "Advanced Option" during boot. 

I observed two difficulties when I tried to reinstall the VMware Tools in the "Recovery Mode".

1. When I tried to install the VMware Tools when I switched to shell in the "Recovery Mode" by running <code>sudo ./vmware-install.pl</code>, I observed many warning messages similar to below,
   

   
   The /tmp directory may be under attack
   

   
   
   
2. You may have to download the VMware Tools, for which, we need to enable network in the "Recovery Mode". 

To address the above difficulties, my solutions is,

1. In the "Recovery Mode", first enable "network" from the list of options.
2. Then go to shell (by choosing "Drop to root shell  prompt").
3. Start the sshd. This is a two-step procedure.
   
   

   
   mkdir /var/run/sshd
   /usr/sbin/sshd
   
   

4. Now, figure out the IP address of the guest (e.g., using ifconfig)
5. Log onto the virtual machine using a Secure Shell client as a regular user with sudo privilege.
6. Install the VMware player as the regular user using sudo.
7. Reboot. The the problem went away.

VMWare Tools Failed to Load on Ubuntu 13.10 (Saucy)

I am running a Ubuntu guest OS using VMWare Player. I upgraded my guest Ubuntu to Ubuntu 13.10 through "do-release-upgrade" and upgraded my VMWare player to 6.01. When I was upgrading the VMWare Tools, I encountered a problem that the VMWare Tools cannot be loaded. I did a quite a few web searches and many suggested to disable the vmware-tools-thinprint service. On my guest, it did not help by disabling the vmware-tools-thinprint service. What actually helped was to upgrade vmxnet to vmxnet3, which can be accomplished by directly editing the virtual machine's configuration file. To edit the configuration file, in my case the Ubuntu.vmx file, add a line to the file, e.g.,

ethernet0.virtualDev = "vmxnet3"

The solution was hinted by the error message when I ran vmware-install.pl,

The vmxnet driver is no longer supported on kernels 3.3 and greater. Please 
upgrade to a newer virtual NIC. (e.g., vmxnet3 or e1000e)

In some case, as indicated by the comment below, you may also need to uninstall (by running vmware-uninstall-tools.pl that should have been installed, by default at the /usr/bin directory) and reinstall VMWare tools.