One Guest VM Needs 2 Shutdown Requests

[EddieA]

I'm just getting around to adding an automated shutdown of my server, once it drops onto battery power.  In doing this, I've been playing around with the Automatic Start/Stop of the VMs.

I've found that one of the VMs I want to cleanly shutdown doesn't, when I power off the server.  In experimenting, using Shutdown from the guest menu in the vSphere Client, I've observed that it appears to ignore the 1st request to shutdown, but (so far) has always done so on the 2nd request.

Any ideas why it would do this, and how can I get it to honour the 1st request.  I'm running the latest build 5.0.0, 768111.

All the VMs I'm trying to automatically shut down are running Linux.  The one that needs the 2 requests reports it's VMWare Tools status as:  Running (Current).  For the other 2, which shut down on the initial request, vSphere reports the status as:  Running (3rd-party/Independent).  Side question:  One of these VMs is the VMA.  How come it reports as 3rd-party.  Don't VMWare use their own tools.  :smileydevil:

Cheers.

[EddieA]

OK, now I've upgraded to 5.1 I'm revisiting this, as 5.1 works a little different than 5.0.  Well, it produces some warnings that 5.0 didn't.  :smileylaugh:

Trying to run the shutdown now produces the following warning:

Cannot shut down the guest OS. The request to Power off this virtual machine failed because the corresponding VMware Tools script did not run successfully. If you have configured a custom power-off script in this virtual machine, make sure that it contains no errors. Attempting the operation again will ignore the script failure. You can also submit a support request to report this issue.

Part of the error text explains why the 2nd attempt at shutting down then works.

Well, I don't have any custom scripts written, so I started checking the VMWare installed ones, once I worked out where they were.  Looking at the script:  /etc/vmware-tools/scripts/vmware/network I found the following:

   # XXX Are these really necessary?  If so, we should have seen customer
   # complaints by now.
   which ifup >/dev/null 2>&1      || Panic "ifup not in search path."
   which ifconfig >/dev/null 2>&1  || Panic "ifconfig not in search path."

Well, the distibution I use doesn't use "ifup", so obviously this causes the "Panic" which breaks the shutdown script, even though shutdown is just a return, it doesn't actually process any commands.

Creating a dummy "ifup" executable solves the issue, and as long as I only use commands that don't rely on "ifup", all should be well.

Note to VMWare developers:

I think the reason that you have not seen any customer complaints, so far, is that any problems with this script are not written anywhere.  Not to a terminal, and not to any logs.  The command is just silently ignored.  That makes it difficult to report an issue when you aren't informed that it's happening.  :smileygrin:

Cheers.