Virtual Acoma

Useful Stuff we find interesting …

Automating VMware Tools install after kernel update on RHEL / Centos

Jul 9

Posted by David in Miscellaneous | 7 Comments

I came across this site when researching a way to automatically get the VMware tools re-installed on kernel updates.

http://www.tuxyturvy.com/blog/index.php?/archives/48-Automating-VMware-modules-reinstall-after-Linux-kernel-upgrades.html

There were plenty of comments but it seemed everybody had a different way of implementing how and when the script to update gets called. Plus, as there are so many init variations amongst the distributions, some SuSe stuff would not work on Red Hat.

Anyway, I have implemented yet another solution for Red Hat / CentOS. (I’m using 5.3).

I pinched this script from the very bottom of the site on tuxy.turvy.com.

#! /bin/bash
# Following lines auto-recompile VM Tools when kernel updated
 VMToolsCheckFile="/lib/modules/`uname -r`/misc/.vmware_installed"
 VMToolsVersion=`vmware-config-tools.pl --help 2>&1 | awk '$0 ~ /^VMware Tools [0-9]/ { print $3,$4 }'`

 printf "\nCurrent VM Tools version: $VMToolsVersion\n\n"

 if [[ ! -e $VMToolsCheckFile || `grep -c "$VMToolsVersion" $VMToolsCheckFile` -eq 0 ]]; then
 [ -x /usr/bin/vmware-config-tools.pl ] && \
 printf "Automatically compiling new build of VMware Tools\n\n" && \
 /usr/bin/vmware-config-tools.pl --default && \
 printf "$VMToolsVersion" > $VMToolsCheckFile && \
 rmmod pcnet32
 rmmod vmxnet
 depmod -a
 modprobe vmxnet
 fi

Save the above as file on your server called vmware-check-tools. Then do the following as root.

# cp vmware-check-tools /etc/init.d

# chmod 755 /etc/init.d/vmware-check-tools

# cd /etc/rc.d/rc3.d

# ln -s ../init.d/vmware-check-tools S09vmware-check-tools

All Done ! That is a zero-nine BTW.  S09. If you look in that rc3.d directory, you will notice lots of scripts starting with S and K and various numbers after them. This is how the init system starts/stops processes and in which order. We want the module check script to run before the network starts (so we load the vmxnet module). The network script is listed as S10network. So, I chose s09vmware-check-tools so it would run immediately before the network starts.

This actually works and I’ve rolled it out to all my CentOS boxes. There is no need for a K script as we don’t need to run the script when the server shuts down.

What the script does is check the current kernel misc module directory for the file, ‘.vmware_installed’. If it does not find it, vmware-config-tools.pl will be run with the default flag and then the .vmware_installed file will be created so the tools won’t re-install next boot (on the same kernel).

With the above, I’m only looking after runlevel 3.  That is, boot to the prompt. If you are one of those people who feel more secure booting to X windows, that would mean you are in runlevel 5. (Check /etc/inittab). In that case, you would want to create the symbolic link S09vmware-check-tools in the rc5.d directory.

Cheers

Installing WebObjects on RHEL Centos 5.3

Jul 2

Posted by David in Linux, Miscellaneous | Comments off

Hi,

I like totally ripped most of these instructions from this site, Installing WO 5.3 or WO 5.4 on Linux , so please give your google adsense love clicks to it. Here is how we did it here…..the main differences are in our apache config and our developer wrote a better init.d script…..as quoted by him. NOW READ !!

0. Before you begin you will require:

  • Installed Sun JDK
  • Installed Apache and development header files
  • Add Dag’s rpmfusion repository. Do not enable it though, we will call it when we need it.

1. Get the WebObjects installer from mDimension’s Web site :

wget http://webobjects.mdimension.com/wolips/WOInstaller.jar

2. Install WebObjects 5.4.3 into /opt

sudo java -jar WOInstaller.jar 5.4.3 /opt

3. Create a user to run wotaskd and JavaMonitor (we are going to follow Mac OS X convensions here)

sudo groupadd appserverusr
sudo useradd -g appserverusr appserver

4. Fix permissions

sudo mkdir /var/log/webobjects
sudo chown appserver:appserverusr /var/log/webobjects
sudo chown -R appserver:appserverusr /opt/Local
sudo chown -R appserver:appserverusr /opt/Library
sudo chmod 750 /opt/Library/WebObjects/JavaApplications/JavaMonitor.woa/JavaMonitor
sudo chmod 750 /opt/Library/WebObjects/JavaApplications/wotaskd.woa/Contents/Resources/SpawnOfWotaskd.sh
sudo chmod 750 /opt/Library/WebObjects/JavaApplications/wotaskd.woa/wotaskd

5. Edit .bash_profile for the appserver user and add the NEXT_ROOT environment variable

export NEXT_ROOT=/opt

6. Change to the appserver user and launch wotaskd and JavaMonitor to ensure everything is working

su - appserver
/opt/Library/WebObjects/JavaApplications/wotaskd.woa/wotaskd &
/opt/Library/WebObjects/JavaApplications/JavaMonitor.woa/JavaMonitor -WOPort 56789 &

7. You should now be able to browse to JavaMonitor at:

http://your.host.name:56789/

8. If you have made it this far you can shut down wotaskd and JavaMonitor and add in the scripts to bring them up on boot.

kill `ps aux | awk '/WOPort 56789/ && !/awk/ {print $2}'`
kill `ps aux | awk '/WOPort 1085/ && !/awk/ {print $2}'`

9. Download the attached start-up script and place it in /etc/init.d

10. Instruct the init script to run the script at boot

chkconfig --add webobjects
/etc/init.d/webobjects start

11. Download and unpack the Wonder source required for the apache adaptor

wget http://webobjects.mdimension.com/wonder/Wonder-latest-Source.tar.gz
tar zxvf Wonder-latest-Source.tar.gz
cd Wonder/Utilities/Adaptors

12. Edit the make.config file to set the environment we are building on

# Set the platform you are building on
ADAPTOR_OS = LINUX

13. Build and install the module

make
cd Apache2.2
apxs -i -a -n WebObjects mod_WebObjects.so

14. Add the following configuration to /etc/httpd/conf.d/webobjects.conf

<IfModule mod_WebObjects.c>

# Path to the Document Root of your Webserver,
# it should contain a directory named WebObjects
WebObjectsDocumentRoot /var/www/html

# You can change the 'cgi-bin' part of WebObjectsAlias to whatever you
# prefer (such as Apps), but the 'WebObjects' part is required.
WebObjectsAlias /cgi-bin/WebObjects

# We set a specific allow rule to prevent default restrictions from denying
# access to the module
<Location /cgi-bin/WebObjects>
    Allow from All
</Location>

# Point /WebObjects requests to the installed document root
Alias /WebObjects /var/www/html/WebObjects
<Location /WebObjects>
    Options -Indexes
    Allow from All
</Location>

# Here are the 3 possible configuration modes.
# The apache module uses one of them to get information
# about your deployed applications.
# 1085 is the reserved port on which wotaskd processes listen to by default.

# Host List Configuration
# wotaskd is started automatically on supported platforms,
# so this is the default mode.
# The apache module gets its configuration from the wotaskds
# listed on the configuration line
# For multiple hosts:
# WebObjectsConfig http://<name-of-a-host>:<port-on-a-host>,http://<name-of-another-host>:<port-on-a-host> <interval>
# For localhost:
WebObjectsConfig http://localhost:1085 10

# Multicast Configuration
# The apache module gets its configuration from all wotaskds
# that respond to the multicast call on the subnet
# WebObjectsConfig webobjects://239.128.14.2:1085 10

# File Configuration
# The apache module gets its configuration from one file
# WebObjectsConfig file://<path-to-a-xml-config-file> 10

# To enable public access to the WOAdaptorInfo page, uncomment the following line
WebObjectsAdminUsername public

# To enable the WOAdaptorInfo page with restricted access,
# uncomment the next two lines and set the user and password
# To access the WOAdaptorInfo page with restricted access, use
# a URL like: http://webserver/cgi-bin/WebObjects/WOAdaptorInfo?user+password.
# WebObjectsAdminUsername user
# WebObjectsAdminPassword password

# To change the logging options, read the following comments:
# The option name is "WebObjectsLog" and the first value indicates the path
# of the log file.
# The second value indicates the log level. There are five, in decreasing
# informational order:
#       "Debug",    "Info",    "Warn",    "Error",    "User"
#
# Note: To enable logging, touch '/tmp/logWebObjects'
# as the administrative user (usually root).
#
# The following line is the default:
WebObjectsLog /tmp/WebObjects.log Debug
</IfModule>

15. Copy the static content into the Apache document root

cd /opt/Library/WebObjects/WODocumentRoot
cp -R WebObjects /var/www/html/

all done!

The init.d script

————————————-

#!/bin/bash
#
# chkconfig: 345 90 10
# description: Provides WebObjects services

USER=”appserver”
NEXT_ROOT=”/opt”
WOTASKD_LOG=”/var/log/webobjects/wotaskd.log”
MONITOR_LOG=”/var/log/webobjects/JavaMonitor.log”

export NEXT_ROOT

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
[ -f /etc/sysconfig/network ] && . /etc/sysconfig/network

# Check that networking is up.
[ “${NETWORKING}” = “no” ] && exit 0

start() {
echo -n “Starting wotaskd and Monitor: ”
daemon –user=$USER “$NEXT_ROOT/Library/WebObjects/JavaApplications/wotaskd.woa/wotaskd -WOPort 1085 >> $WOTASKD_LOG 2>&1 &”
daemon –user=$USER “$NEXT_ROOT/Library/WebObjects/JavaApplications/JavaMonitor.woa/JavaMonitor -WOPort 56789 >> $MONITOR_LOG 2>&1 &”
echo
}

stop() {
echo -n “Shutting down wotaskd and Monitor: ”
WOTASKD_PID=`ps aux | awk ‘/WOPort 1085/ && !/awk/ {print $2}’`
kill $WOTASKD_PID
MONITOR_PID=`ps aux | awk ‘/WOPort 56789/ && !/awk/ {print $2}’`
kill $MONITOR_PID
echo
}

# See how we were called.
case “$1″ in
start)
start
;;
stop)
stop
;;
status)
status $processname
RETVAL=$?
;;
restart)
stop
start
;;
*)
echo $”Usage: $0 {start|stop|status|restart}”
;;
esac

exit $RETVAL

———————————————–

Tags:

Update to pvscsi on Linux

Jun 25

Posted by David in Linux, Virtualisation | Comments off

I just had top build a WebObjects VM using CentOS for our Dev team so had a chance to go over my instructions. The good news is that a 2nd hard disk is not necessary which makes the procedure a lot smoother. The instruction then, once you have the VM up and running and VMTools installed is:

# mkinitrd -f –with=pvscsi /boot/initrd-`uname -r` `uname -r`

Shutdown the VM. Go into Edit Settings and change the SCSI controller from LSI to Paravirtual. Save and Power up the VM. You should have success.

For an updated kernel, see my previous post.

Using pvscsi in Linux – Update

Jun 22

Posted by David in Linux, Virtualisation | Comments off

Well, after a bit of playing I will have to streamline my last post. But before I get to that, I figured out a way to build the pvscsi module into the latest kernel update BEFORE you have rebooted. (So you are able to reboot into the new kernel without a Kernel Panic).

My lasy example used kernel vmlinuz-2.6.18-128.el5. The lastest kernel update at the time of writing for Centos  5.3 was vmlinuz-2.6.18-128.1.14.el5. Its modules directory is located under /lib/modules/2.6.18-128.1.14.el5.  When the VMWare Tools are installed, it installs the relevant modules in /lib/modules/`uname -r`/misc. Where uname -r is the current running kernel. If we try make a ramdisk for initrd for the new kernel, we will get an error saying the modules are missing….which they are.

So here is my dodgy solution….

Create a misc directory in the new kernel’s module directory.  # mkdir /lib/modules/2.6.18-128.1.14.el5/misc

Copy the pvscsi.o file from the current kernel’s directory to the new one. # cp /lib/modules/2.6.18-128.el5/misc/pvscsi.o /lib/modules/2.6.18-128.1.14.el5/misc

Create a symlink in that directory for the kernel module.

# cd /lib/modules/2.6.18-128.1.14.el5/misc

# ln -s pvscsi.o pvscsi.ko

You should then be able to make the new initrd image with the new kernel. Ceck out the /etc/grub.conf config file to get the vewrsion number of the latest kernel. In my example, you would run:

# mkinitrd -f –with=pvscsi/boot/initrd-2.6.18-128.1.14.el5.img 2.6.18-128.1.14.el5

This should succeed. The -f flag means to overwrite the current file with that name.

Ok, reboot and you should be successful in booting off the new kernel with the pvscsi module. The re-run ‘vmware-config-tools.pl’ as per normal to rebuild the the VMware Tools for this kernel. When it gets to pvscsi, it will ask to overwrite the current version. Select yes. You could remove this module before you run vmware-config-tools.pl. I have not tried that though.

Remember, this is not supported and YOU are responsible for any problem that may occur. I am not. Ok! Good.

It should work fine though.

Tags:

Installing and using pvscsi in Red Hat and CentOS 5.3 under vSphere 4

Jun 21

Posted by David in Linux, Virtualisation | 2 Comments

Well, after reading a few blogs (I hate that word) on using the pvscsi adaptor under Windows 2003 and 2008 and converting the boot drive to use the pvscsi adaptor, I figured one for Linux was overdue. At the time of this post, only RHEL was supported. This also includes CentOS 5.3. So, it took me 10 minutes, but I worked out how to get Linux to boot from the pvscsi adaptor.

The process is this:

  1. Create CentOS 5.3 VM or use an existing one using the default LSI bus adaptor
  2. Install the latest VMTools.
  3. Add a new drive on a new adaptor. (ie Choose the SCSI ID of (SCSI 1:0) )
  4. Boot and format and install the 2nd drive
  5. Shutdown and change the 2nd drive adaptor to pvscsi
  6. Reboot and make sure the 2nd drive comes up. Check the module is loaded.
  7. Grab the module name.
  8. Create a new initrd for the kernel to boot up with including the pvscsi module.
  9. Shutdown, change the 1st Disk adaptor to pvscsi.
  10. Boot successfully, hopefully.
  11. Voila

Ok, here is the long version.

  1. Create your CentOS or Red Hat VM (I used version 5.3 at the time of writing)
  2. Boot into the OS. Install VMware Tools.
  3. Power down.
  4. Add a new Virtual disk in the Settings section. This will be a temporary drive. Give the Virtual disk a Device ID of SCSI (1:0). This ensures that a second scsi controller will also be added. Save the changes.
  5. Go back into Settings and choose the 2nd SCSI Controller that was just added. Change the Type to Paravirtual. Save and Exit.
  6. Boot the VM.
  7. Ensure the VM sees the new disk and the pvscsi module was loaded.
  • Run # fdisk -l to see the disks on the system. You should see /dev/sdb (the new drive)
  • Create and format the new drive
  • # fdisk /dev/sdb
  • ‘n’
  • ‘p’
  • ‘1’
  • Press Enter for the defaults
  • Press Enter for the defaults
  • ‘w’ to write the change

This will create the disk partition, /dev/sdb1. Format it with:

# mkfs.ext3 /dev/sdb1

Mount the new disk. Of course this is unnecessary but does help with testing and making sure stuff works.

If you could not mount the disk, something must have went wrong or my instructions are bad. Let me know.

Ok, but what about the first disk that the OS boots from? This is the think VMware does not support but it can easily be implemented. when the OS boots, grub reads a few settings from /boot/grub/grub.conf. The important things are the kernel and the initrd image. The kernel is self explanatory. The initrd stands for Initial ramdisk. This ramdisk is loaded at boot with a subset of modules required for the kernel to bootstap the system.  (Something like that…don’t quote me…). So, currently, the kernel knows nothing about the pvscsi module as we loaded it after the system was installed. If we changed the 1st SCSI controller to paravirtual, then the system would boot but the bork when it came time to mount the disks as it would not have found any as it had no disk controller…understand.   So how do we tell it about the new paravirtual disk controller?

You add it to the initrd so the kernel can then initialize the paravirtual SCSI controller and see the disk. How do you add the module?  Do the following:

  1. The VM is now up and running and you have successfully added a 2nd disk on the paravirtual controller. You can also see ‘pvscsi’, when you run, ‘# lsmod | grep pvscsi’.
  2. Create the new ramdisk as follows.
  3. Move the current initrd to a backup. (In my example, the kernel is /boot/vmlinuz-2.6.18-128.el5 and the corresponding initrd file is /boot/initrd-2.6.18-128.el5.img) Any new kernel that gets installed will have a corresponding initrd file installed as well and added to /etc/grub.conf.
  4. Rename the existing initrd. # mv /boot/initrd-2.6.18-128.el5.img /boot/initrd-2.6.18-128.el5.img.bak
  5. Make a new initrd with the same name but with the pvscsi module……..

# mkinitrd –with=pvscsi /boot/initrd-`uname -r`.img `uname -r`

That is the tilde sign, not a sigle quote. (`) Where `uname -r` returns the current kernel version, 2.6.18-128.el5.

Once the new initrd is in place and you have confirmed, (# ls -l /boot), shutdown the VM.

  1. Go into the Settings of the VM and change the Adaptor type of the 1st SCSI Controller to Paravirtual.
  2. Save and Exit.
  3. Boot and test.
  4. You should boot successfully. This means you have booted via the new paravirtual scsi controller.
  5. Hurrah

From then, do what you like. shutdown the VM, remove the 2nd disk, or keep the 2nd disk and place it on the first disk controller, the choice is yours. (Do that in the Setting pane by change Virtual ID from SCSI (1:0) to SCSI (0:1)).

Important things to take note of!

This is unsupported by VMware at the moment but works fine and VMotion does work fine as well. Whenever a kernel update gets released, please make sure to rebuild a new initrd image for the new kernel.

This can be a hassle. One way, would be to shutdown the VM, change the disk controller back to LSI Parallel. Boot, re-run vmware-config-tools.pl to update the tools for the new kernel. The re-run the commands above to rebuild the initrd. then power off, change the controller back to paravirtual and reboot. That is the safest way.

Another way is to try build the modules for the new kernel and build a new initrd. I have to work on how to do that so look out for another post.

Another pvscsi link for Windows

Jun 21

Posted by David in Virtualisation, Windows | Comments off

Here is another URL to guide you into pvscsi glory. GLORY!!!!!

http://blog.petecheslock.com/2009/06/03/how-to-add-vmware-paravirtual-scsi-pvscsi-adapters/

Tags:

Implementing pvscsi in Windows 2003 and windows 2008 on vSphere 4

Jun 21

Posted by David in Virtualisation, Windows | Comments off

I found a great URL on how to update an ESX 3.5 VM to vSphere 4 (ESX 4) and also incorporate the new pvscsi I/O adaptor for the root drive (C: drive).

Now I just have to find it…….

Here is the link to Scott Lowe’s excellent blog…. I’m not sure if this is the exact page I read but it has the same instructions.

http://blog.scottlowe.org/2009/06/01/vsphere-virtual-machine-upgrade-process/

IMPORTANT!! VMWare do not support the pvscsi adaptor for the boot drive….they do not support it……important words…does not mean it does not work. For years, they did not support Storage Vmotion on iscsi and nfs …does not mean it did not work. You have been warned. END COMMUNICATION

Hello world! Pants Off!

Jun 21

Posted by David in Miscellaneous | Comments off

This will be a blog for handy tips and our way of giving something back to the Interweb after taking so, so much from it. 😀