CentOS Host OS Crashes When Installing VMware Tools on a Guest OS Within VMware Workstation 10

Installing VMware Tools on a Windows 7 Guest OS in VMware Workstation 10.1 running on a CentOS 6 host always resulted in the host OS crashing.
This appears to be due to a combination of VMware Workstation 10.1 running on CentOS 6 .5 with kernel 2.6.32-431.1.2.0.1.el6.x86_64 #1 SMP x86_64 GNU/Linux. I see these two interesting items on the screen output followed by a call trace.

BUG: scheduling while atomic: vmware/6035/0x000002000
Pid: 6035, comm: vmware Tainted: G D --------- 2.6.32-431.1.2.0.1.el6.x86_64 #1

2013-12-28_vmware-host-crash
To resolve this issue:

# service vmware-workstation-server stop
# service vmware stop
# mv -v /usr/lib/vmware/modules/binary /usr/lib/vmware/modules/binary~orig
# rm /lib/modules/$(uname -r)/misc/v*.ko
# depmod -a
# yum install make gcc keneral-headers-$(uname -r) kernel-devel
# /usr/bin/vmware-modconfig --console --install-all
# service vmware start
# service vmware-workstation-server start

I could now attempt to install VMware Tools on a Windows 7 Guest OS without the host crashing. However, I now ran into another complication. The VMware Tools install would hang around the point of installing the ThinPrint module. Basically, the VMware Tools install hangs due to cruft left over from previous install attempts. Follow VMware KB Article 1001354 to remove cruft left over from previous VMware Tools installs. Then try reinstalling again.
You do not need to repeat this procedure since the offending modules are being removed in the steps above. During subsequent kernel upgrades, modules will be recompiled automatically.
VMware claims that “this issue should be fixed with the next update (10.0.2), and we will publish a kb article.”
UPDATE: The VMware community appears to agree that this issue is resolved in the Workstation 10.0.2 release.

My System Configuration

  • VMware Workstation 10.1
  • Host: CentOS 6.5 x86 64-bit
  • Guest: Windows 7 Professional SP1

References

6 thoughts on “CentOS Host OS Crashes When Installing VMware Tools on a Guest OS Within VMware Workstation 10”

  1. Hey Dave,
    Thanks a lot for your hint on the VMWare Workstation 10 issue, it has been great help for me!
    I pretty much doubt that I would have been able to solve this bugger on my own…
    Have a good one, greetings from Cologne/Germany, Björn.

  2. Thanks for this hint.
    This issue also seems to be affecting VMware Player v5 with 6.5 and Win7 The commands are the same with a slight modification for player:

    service vmware-USBArbitrator stop
    service vmware stop
    mv -v /usr/lib/vmware/modules/binary /usr/lib/vmware/modules/binary~orig
    rm /lib/modules/$(uname -r)/misc/v*.ko
    depmod -a
    yum install make gcc keneral-headers-$(uname -r) kernel-devel
    /usr/bin/vmware-modconfig --console --install-all
    service vmware start
    service vmware-USBArbitrator start

    I’ve not tried this on Player 6 as we only have licence to run 5 internally.

  3. David,
    Thank you very much for sharing your experience … you’ve saved me a lot of trouble! It seems this is also an issue with Workstation 9, as I tried installing VMware Tools on a W7 VM a few times after updating my system to the 6.5 package set (2.6.32-220.el6.x86_64), and every time, my host would crash. (I always take snapshots as I build what will become a “gold image”, so I don’t lose work/progress.)
    Rather than follow your steps, I reverted to running off the previous kernel, following the general principle that if a kernel change disrupts one thing, it’s very possible there are other things affected, and I don’t want to run on a kernel that seems to have introduced some instability to a sound-running environment.
    Kudos, and take care.
    ~D

  4. David,
    Thanks for this blog post! I just installed Scientific Linux 6.x today (from Fedora 20) and had a similar issue booting my Windows 8 VM in Workstation 10.01. I think the same VMware Tools issue was the culprit and your advice appears to have resolved my issue.
    Sincerely,
    Richard

Leave a Reply

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