The issue being experienced is that every time the server is restarted, vmware-config.pl needs to be ran so that the service may successfully start.
This appears to be a fairly common problem, however, there did not appear to be a magic bullet solution that actually corrected the issue.
Further investigation suggested that during installation, VMware creates the device nodes in /dev and expects them to be present on subsequent system starts. The issue with this is that with udev, the device nodes are dynamically created and thus the VMware nodes are lost. While the /etc/init.d/vmware script suggests that the nodes are created, they aren't from my experience.
One solution to the problem is to force the creation of the nodes required within /etc/init.d/vmware within the service_vmware start function as such:
service_vmware() {
# See how we were called.
case "$1" in
start)
if vmware_inVM; then
# Refuse to start services in a VM: they are useless
exit 1
fi
# UDEV fix follows
if [ ! -e "/dev/vmmon" ]; then
mknod /dev/vmmon c 10 165 2>/dev/null;
chmod 600 /dev/vmmon
fi
if [ ! -s "/dev/vmci" ]; then
mknod /dev/vmci c 10 60 2>/dev/null;
chmod 666 /dev/vmci
fi
for a in `seq 0 9`; do
if [ ! -e "/dev/vmnet$a" ]; then
mknod /dev/vmnet$a c 119 $a 2>/dev/null;
chmod 600 /dev/vmnet$a
fi
done
That solved the device nodes problem for me.
However, another issue was still present that required vmware-config.pl to be ran on server restarts and this was that /etc/vmware/not_configured was now present.
During the start up process for VMware, an exitcode variable is built up from the running and/or starting of various programs required by VMware to operate.
If this variable is anything other than zero and the VMware product is not VMware Workstation, the not_configured file is generated. The impact of this file being present on the next attempted starting of the service results in an exiting of the script from the check_configured function complete with and advising note that VMware has not been configured and that vmware-config.pl needs to be ran to resolve the problem.
Running vmware-config.pl does in fact solve the problem as expected, however, as previously mentioned, the requirements do not stick.
The additional requirement for me to overcome this problem was to comment out the exitcode check performed by the script.
Just below the section added above within the service_vmware start function, you'll need to comment out this check as shown below:
# if [ "$exitcode" -gt 0 -a `vmware_product` != "ws" ]; then # # Set the 'not configured' flag # touch "$vmware_etc_dir"'/not_configured' # chmod 644 "$vmware_etc_dir"'/not_configured' # db_add_file "$vmware_db" "$vmware_etc_dir"'/not_configured' \ # "$vmware_etc_dir"'/not_configured' # exit 1 # fi
While this is not the most ideal solution for some, it solved the problem for me and I hope that some of this information may help others.
