Answering my own question, I unstalled VMWare Tools from all of the VMs, and everything is working as expected now.
Not sure what VMWare tools does in a GUI-less environment anyway...hopefully nothing important that I need. ;-)
Hrm. I'll forward this on internally to someone who might be able to help. Can you give some more information about the guest OS environment?
It's actually no biggie for me any more, now that I discovered it all works fine if I uninstall the tools. That said, it was just Ubuntu 10.04 server, no desktop GUI installed, pretty plain jane. Some of the various VMs were running PostgreSQL, others with Apache; all of them were current on OS updates.
Ok, actually, I see now that my date/time doesn't update as I'd hope if I don't have the tools installed, so I re-installed them. Same problem, very consistent. For now, I've disabled the suspend script by running
sudo /usr/bin/vmware-toolbox-cmd script suspend disable
in the guests. That solves the immediate problem, although I'm not entirely sure of the impact of that. :-)
Sigh...one impact of what I did is if I have 3 of my Ubuntu VM's running, and I try to quit VMWare Fusion, it suspends ONE of the VMs, and then continues running. Expected behavior would be to suspend all running VMs and exit.
Apologies for all these messages in a row...but to disable the default suspend script, AND get the normal shutdown behavior when closing VMWare fusion, I had to create a dummy script that would return success, and use that as a suspend script. So:
1. Create /home/foo/vmware-suspend-script, with the contents#!/bin/shexit 0
2. chmod 777 /home/foo/vmware-suspend-script
3. sudo /usr/bin/vmware-toolbox-cmd script suspend set /home/gregr/vmware-suspend-script
As to why the original script isn't working...I took a quick look, and it looks like it's doing some network related stuff with the interfaces. I do have a modified /etc/network/interfaces file, which perhaps is causing a conflict with the suspend script? Here's my interfaces file:
# The loopback network interface
iface lo inet loopback
# The primary network interface
auto eth0 eth0:0
iface eth0 inet static
iface eth0:0 inet static
I run the same version of Ubuntu have encountered the same problem. I traced the problem down to the VMware networking scripts and this bug in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/440179
In the "/etc/vmware-tools/script/vmware/network" script, there's a function "run_network_script()". It first finds the "/etc/init.d/networking" script and then tries to find the SysV "service" script. If it can find the "service" script, it'll use that to suspend networking. Otherwise it'll use the init.d script. The problem is that the "service" script does exist but is broken for networking in this version of Ubuntu, hence the failures when VMware runs it script. The solution for me is to just comment out the line that tries to find the "service" script so that it falls back to the init.d script. Just comment out the: "service = `which...`" line (line 81)
Hope that helps.
1 person found this helpful
Yeah, so I spoke with a couple of folks internally and it sounds like the two best options are 1) upgrade to another version of Ubuntu that contains a properly working service or 2) comment out the line that tries to find `which service` as jupiterstar mentioned in his previous post.
Thanks. In my case, I run VMs that simulate production servers for testing, so it's a matter of running the same Ubuntu version that the real servers do...so I can't just upgrade to make VMWare work better. :-)
I'll do the workaround described above - thanks for following up!
jupiterstar, thanks so much for this tip! I've got some Ubuntu 12.04 LTS text only servers that I use under Fusion and every time I'd try to shutdown my mac, VMWare would block the shutdown saying it was unable to run the suspend script. Commenting out line 81 of the script file did the trick!