December 22, 2011

Fixing VMware Workstation 8 and insserv

vmware

Not too long ago VMware has a product called “VMware Server” which originally came with a dedicated management application. Later VMware threw out the console and created a web interface for VMware Server. Not long after that they completely threw VMware Server away in favor of their new enterprise software solution(s) ESX/ESXi/vCenter/vSphere/etc. For the new(ish) VMware Workstation 8 one of the most notable features is the “Shared VMs” which is more or less a reawakening of  their original VMware Server application functionality. With this feature you can once again set VMs to run in the background, autostart, and access via network. However a problem arises with the installation on systems which use insserv. Read on and I’ll explain the problem and show you how to fix it.

Quick Explanation of the Problem

For the uninformed what we are talking about is the way that a Linux system boots. The kernel is responsible for starting the very first “program” (init) which spawns (initializes) all other programs on the computer; this can include networking support, web servers, hardware detection/configuration servers, etc. The downside was that each process was launched one after the other so boot times took a long time. Also, some programs/daemons/processes relied on other processes to be up and running before they could be started. (For example a network file server would need networking started prior to it etc.) The solution was to number each processes startup script so that they would launch in a particular order. Linux, Linux based Operating Systems, and Linux software are developed by many different groups of people so forcing/maintaining/optimizing a correct boot order is rather cumbersome.

The solution to speed up boot times is to have multiple programs launch in parallel during start up. In order for this to work we need a dependency boot method  where software won’t start until its dependencies have been met. On systems such as Debian and Suse/OpenSuse this is accomplished using insserv. Insserv can be viewed as an extension of the original Sys-V boot method. It works be including a small comment section in each startup script which lists dependencies needed prior to running that script.

The Problem With Workstation 8

VMware software has supported insserv for quite awhile. For instance look at VMware Standalone Converter (released 05/21/09.)

However, after installing VMware Worstation version 8.0.1-528992 I noticed errors with apt and aptitude. These types of issues are documented here: http://communities.vmware.com/message/1870110#1870110. Although a good answer was given regarding the LSB script headers being missing, the proposed solutions still did not fix vmware-workstation-server (the init process responsible for Shared VMs feature.) Checking my system I could see that there were no LSB header information (like that seen above) in /etc/init.d/vmware nor /etc/init.d/vmware-USBArbitrator nor /etc/init.d/vmware-workstation-server.

Digging deeper I discovered this post: http://communities.vmware.com/message/1846324#1846324 where Ubuntu users were complaining that the VMware support for insserv functionality actually broke their installations. — Well these two posts seem contradictory. So I looked a bit deeper at the installer.

Dissecting the Installer

First I extracted the installer files to folder name “workstation_extracted”:

./VMware-Workstation-Full-8.0.1-528992.x86_64.bundle -x workstation_extracted

Taking it one script at a time I looked in the vmware-vmx directory thinking that this would be the section of the installer responsible for the vmware startup script. Inside this folder we can see a directory called initinfo which contained a template for the insserv LSB header information.

Doing a quick search in all the files for the keyword insserv:

find ./ -type f -exec grep -H insserv {} \;

I found that ./.installer/4.0.1/include/initscript.py  was the best place to start. At the very top of this script we can see the funtion “ConfigureService” defined and that it takes all the parameters that we need:

Scanning down through the file I found the following comment:

# First, check for update-rc.d b/c we want to use it instead
# of insserv on Ubuntu and Debian systems.

After which the script searches for the existence of the update-rc.d script on the local system. If it finds it then it assumes that it should not use insserv and this is why the LSB header information needed for insserv dependancy based booting is missing. The only thing I can guess is that due to this post: http://communities.vmware.com/message/1846324#1846324 and some non-updated Debian policy VMware changed the installer to behave in this way.

Building the Solution

The simple work-around is to add the correct LSB header information. To start, we know that the function ConfigureService is passed the information we want so we search for the keyword ConfigureService:

find ./ -type f -exec grep -Hn ConfigureService {} \;

This points us to line 216 of ./.installer/4.0.1/vmware-vmx.py where we get all the information we need, combined with the sequence found in ./.installer/4.0.1/include/initscript.py and the template ./initinfo/initinfo.lsb to build out the proper LSB script headers.

This process is repeated in extracted vmware-workstation-server and vmware-usbarbitrator directories so that we can build the LSB headers for these scripts as well.

**NOTE** I did notice two additional issues when building out these other scripts headers.

  1. The vmware-USBArbitrator script claims a lsbStartDep and lsbStopDep of “localfs.” According to /etc/insserv.conf I believe that should have been: $fs_local
  2. The vmware-workstation-server script claims a lsbStartDep and lsbStopDep of “haldaemon.” According to /etc/init.d/hal I believe that should have been: hal

Finally Down To Business

On Debian the easiest way to fix this issue is two create three executable override files containing the missing and corrected LSB header information gathered above:

  1. /etc/insserv/overrides/vmware
  2. /etc/insserv/overrides/vmware-USBArbitrator
  3. /etc/insserv/overrides/vmware-workstation-server.

 

Next we need to remove the mess created by the installer by removing and correctly recreating the associated vmware scripts from our rc folders:

sudo insserv -r vmware-workstation-server
sudo insserv -r vmware-USBArbitrator
sudo insserv -r vmware
sudo insserv vmware
sudo insserv vmware-USBArbitrator
sudo insserv vmware-workstation-server

After this everything works smoothly for me with no issues.

 

 

Read more from Linux, VMware

Share your thoughts, post a comment.

You must be logged in to post a comment.