Automating deployment and activation of virtual images

One significant advantage of server virtualization is the ability to rapidly provision new environments by using libraries of virtual image templates. Automated provisioning requires the handling of operating system, network, and application specific customization. This article provides a sample framework for automating virtual image deployment and activation, including example code for quickly and easily provisioning new IBM® WebSphere® Application Server environments. This content is part of the IBM WebSphere Developer Technical Journal.

Le He (lehe@cn.ibm.com), Research and Development Engineer, IBM

Le He is a Research and Development Engineer in the Distributed Infrastructure team of IBM China Research Laboratory. Le is currently researching computer networks and operating systems, and he is also looking into ways to incorporate virtualization into the enterprise environment.



Shawn Smith, Masters student, Duke University , EMC

Shawn Smith is a Masters student at Duke University in his second year, and is pursuing his MS in Computer Engineering. Shawn is currently an IBM Co-op in the WebSphere Technology Institute, and has been actively working on virtualization with XEN and VMware.



Ruth Willenborg, Senior Technical Staff Member, EMC

Ruth Willenborg is a Senior Technical Staff Member in IBM's WebSphere Technology Institute. Ruth is currently working on WebSphere Cloud computing and virtual appliance initiatives, and is the technical evangelist for the new IBM WebSphere CloudBurst Appliance. Prior to her work on virtualization and appliance initiatives, Ruth was the manager of the WebSphere Performance team responsible for WebSphere Application Server performance analysis, performance benchmarking and performance tool development. Ruth has over 20 years of experience in software development at IBM. She is co-author of Performance Analysis for Java Web Sites (Addison-Wesley, 2002).


developerWorks Contributing author
        level

Qingbo Wang (wangqbo@cn.ibm.com), Research Staff Member , EMC

Qingbo Wang is a Research Staff Member in the Distributed Infrastructure team of IBM China Research Laboratory. His technical interests have always been in distributed systems and networking, and he is currently working on automated system management using virtualization technology.



February 2008 (First published 22 August 2007)

Also available in Chinese

Introduction

Virtualization offers advantages that include server consolidation, isolation, rapid provisioning, and improved change management processes. Since virtualization breaks the hardware dependency and isolates virtual machines from details about the physical servers on which they are hosted, virtual images can be moved from one hosting platform to another. They can also be cloned to create more virtual machines, as desired.

One of the challenges with cloning virtual images is handling operating system, network, and application specific customization. This article provides a sample framework for automating virtual image activation on new host platforms. This article, along with a previous article on Using virtual image templates to deploy WebSphere Application Server, demonstrates an automated approach for quickly and easily provisioning new WebSphere Application Server environments.

The sample deployment and activation code included with this article is independent of WebSphere Application Server and can be used in conjunction with other software inside a virtual image. The specific example provided here is for WebSphere Application Server V6 in VMware or XEN virtual images, using SUSE V10 as the guest operating system. The activation techniques described in this article can be used in conjunction with IBM Tivoli® Provisioning Manager as described in Using Tivoli Provisioning Manager to deploy composite virtual appliances.

Since writing this article, many of these concepts (and more) were incorporated into the WebSphere Application Server Hypervisor Edition and WebSphere CloudBurst™ Appliance. Both products support VMware ESX, PowerVM, and zVM.


Automatic virtual machine deployment

Automating the deployment and activation of new virtual machines from a "golden" template is accomplished by adding automation capabilities into the template image, combined with external automation scripts that control the deployment.

Automatic virtual machine deployment (Figure 1) can be broken down into three phases.

Figure 1. Steps of automatic virtual machine deployment
Figure 1. Steps of automatic virtual machine deployment
  1. The first phase is preparation, which includes installing a program, referred to as the activation engine, into the template. The activation engine (a sample is included with this article) knows how to run activation scripts (such as ConfigWAS.pl) at boot time. The engine configures the virtual machine during the initial OS boot. The preparation step also includes copying activation scripts to the template, and registering them with the activation engine using the included activation tools. This preparation work is only done once, and then the template can be locked down.

  2. The second step is deployment, which includes:

    • Copying the VM template files to a target hypervisor.
    • Creating an XML data file with the instance's settings, such as network hostname, IP address, and so on.
    • Creating a virtual floppy disk (or v-floppy) containing the XML data file. The v-floppy is attached to the virtual machine and is automatically visible to the activation engine on first boot.
  3. The final step is auto activation, in which the virtual machine is powered on and the activation scripts automatically run, using information from the v-floppy parameter file.

These steps greatly simplify the customization activities typically required when cloning virtual machines from a template. Details of each of these steps are described in the next sections, and the sample deployment scripts and activation engine are provided for download.


Preparation

The activation engine provides tools to register activation scripts for execution during an OS boot. During boot, the activation engine retrieves script command line options from the activation profile XML file, located on the virtual floppy. As shown in Figure 2, copy the activation engine to the virtual machine template you are using to deploy virtual machine clones.

Figure 2. Install activation engine and scripts
Figure 2. Install activation engine and scripts

Install the sample activation engine by simply un-tarring the included AE.tar file in the directory /opt/IBM/AE. The activation engine is written in PERL and requires the PERL XML related libraries that come with the Linux® operating system. If these libraries are not yet part of your template image, you must install them now.

The main program of the activation engine is called AE.sh, which is used to register activation scripts. You need to provide activation scripts for any software components in the template that you want to customize at first boot. For example, this WebSphere Application Server example includes these activation scripts:

  • ConfigNET.pl (the Linux network) sets IP address and host names.
  • ConfigPWD.sh sets the Linux root password
  • ConfigWAS.pl creates WebSphere profiles.

Copy the activation scripts to the template image and place in the directory /opt/IBM/AE/AS. Currently, the activation engine only supports scripts written in PERL and Shell, with the postfixes .pl and .sh, respectively. Design the scripts to accept any input variables as command line parameters. The command line style is:

-parameter "value"

During the activation phase, the activation engine reads the parameters from an XML file (activation profile), validates the parameters, and passes them to each registered script.

To register all the activation scripts with the activation engine, first create an activation logic file. This file must contain the path to each activation script, and ordering rules for when it executes at boot. These ordering rules are based on standard Linux boot services in /etc/init.d. For example, the standard Linux boot service sshd requires the network to be started, and so sshd has a dependency on the "network" service. Similarly, the activation engine provides a tool for registering an activation script with such dependencies. A snippet for the script ConfigWAS.pl in the activation logic (WAS.al) file is shown below with one such dependency shown of the "network".

<software-resource name="WAS_V_6_1">
	<configuration name="ConfigWAS">
		<script file="AS/ConfigWAS.pl" />
		<service name="activation.ConfigWAS">
		    <runlevel value="3" />
		    <runlevel value="5" />
		    <dependency service="network" />
		</service>
	</configuration>
</software-resource>

When the activation logic file is created, place it into the directory /opt/IBM/AE/AL, and then you are ready to register the activation scripts with the engine. For example, execute this command to register all the scripts in the included WebSphere template (the activation logic file for this template, WAS.al, is included in the download package):

%AE.sh –a AL/WAS.al

Each registered activation script has a boot service file created in the Linux /etc/init.d directory. You can use the Linux utility chkconfig to check whether the activation scripts are installed into Linux. For example, after registering the three boot services (activation.ConfigWAS, activation.ConfigNET, and activation.ConfigPWD), you will see these results:

%chkconfig -list | grep activation
activation.ConfigWAS		0:off  1:off  2:off  3:on   4:off  5:on   6:off
activation.ConfigNET		0:off  1:off  2:off  3:on   4:off  5:on   6:off
activation.ConfigPWD		0:off  1:off  2:off  3:on   4:off  5:on   6:off

The last step in the preparation phase is to create a sample activation profile for the virtual image. The sample is for reference only, and is not actually used during activation. Your sample should specify the valid script command line options, a list of all allowed values for each option, and the default values, when appropriate. At instantiation time, the activation engine uses the specific values provided by the user in his customized activation profile to pass the command line options to the activation scripts. (A sample WebSphere activation profile, WAS.ap, is included with this article.)

After the activation engine and activation scripts are installed on the template virtual machine, new instances automatically self-configure. Scripts execute at first boot of a new cloned virtual machine and are passed command line values obtained from the XML file on a virtual floppy disk. After successfully running the activation scripts, the activation engine disables the scripts from future machine reboots.


Deployment

All the preparation work to this point is to make activation easy and automatic, but you also need to handle deployment. In a nutshell, deployment of a new virtual machine involves copying the virtual machine template to a new location, customizing it, providing an activation profile on a virtual floppy disk, and then turning the power on with a virtual floppy attached. Figure 3 shows an overview of these deployment steps.

Figure 3. Deployment phase
Figure 3. Deployment phase

Deployment is automatically handled in one of two sample scripts included with this article:

  • xen_deploy.pl is designed for XEN V3.0.2 or above
  • esx_deploy.pl is for VMware ESX V3

Both scripts accomplish the same task of deploying a clone of a virtual machine template. Let's take a closer look at what they do.

The XEN and VMware activate scripts implement the steps shown in Figure 3 with seven command line options:

  1. Source configuration file of the virtual machine template. This is the full path to the virtual machine configuration file, such as machine.vmx for ESX.
  2. Target directory for storing the virtual machine image files. This is also a full path. Make sure there is sufficient storage room on the disk, since these files are often large.
  3. Name of the new virtual machine to use in the hypervisor inventory (this does not need to be the same as the hostname of the new virtual machine).
  4. Amount of memory the new virtual machine will have using the -memory switch.
  5. Number of virtual CPUs the new virtual machine will have using the -vcpus switch.
  6. MAC address of the network adaptor (optional). This must be unique for each machine on the network or severe network problems can result. If not specified on the command line, a random MAC address is created. In the case of ESX, the virtual infrastructure client software chooses this MAC address, so it can be left blank.
  7. Path to the XML configuration data (activation profile). This file is copied onto the virtual floppy disk.

Command lines for both scripts are shown below. The command you use is executed on the target hypervisor that is hosting the new virtual machine.

XEN command:
%xen_deploy.pl -sourceVMConfig /etc/xen/vm/template.cfg -targetDirectory /etc/xen/images 
-vmname deploy01 -macaddr 00:16:3e:01:02:03 -memory 512 -vcpus 1 -xml /cfg/WAS.ap
VMware command, with a different path to the source and target locations:
%esx_deploy.pl -sourceVMConfig /vmfs/volumes/storage1/template/template.vmx 
-targetDirectory /vmfs/volumes/storage1 -vmname deploy01 -memory 512 -vcpus 1 -xml 
/cfg/WAS.ap

Before executing the command, you need to create a customized activation profile with the specific input parameters for activating the template. This XML file is a series of name/value pairs corresponding to the sample activation profile for the template.

The rest of the process is handled automatically by the scripts. The first thing the script does is create a target directory to hold the new virtual machine. The VM is copied from the source location defined on the command line. In ESX, a special command line tool, vmkfstools, is used to perform the copy. For XEN, the Linux cp command is sufficient.

Next, a virtual floppy disk is created, which is a viable, hypervisor-independent technique for providing the input parameter file to the activation engine. Creating the virtual floppy requires several Linux commands, which are shown below and included in the deployment scripts.

For XEN:
# Virtual Floppy Disk Creation
%dd if=/dev/zero of=/tmp/floppy.img bs=4k count=16k
%losetup /dev/loop0 /tmp/floppy.img
%echo -e "n\np\n1\n\n\nw\n" | fdisk /dev/loop0
%losetup –d /dev/loop0
%losetup -o $partitionstart -s $size /dev/loop0 /tmp/floppy.img
%mkfs -t ext2 /dev/loop0
%mkdir $temp_mount
%mount -t ext2 /dev/loop0 $temp_mount
%cp $FLOPPY_XML_FILE ${temp_mount}/
%umount /dev/loop0
%losetup -d /dev/loop0
For VMWare:
# Virtual Floppy Disk Creation
%dd if=/dev/zero of=/tmp/floppy.img bs=1k count=1440
%losetup /dev/loop0 /tmp/floppy.img
%mkfs -t ext2 /dev/loop0 1440
%mkdir $temp_mount
%mount -t ext2 /dev/loop0 $temp_mount
%cp $FLOPPY_XML_FILE ${temp_mount}/
%umount /dev/loop0
%losetup -d /dev/loop0

The end result is a fully functional virtual floppy disk, floppy.img, that is attached to the virtual machine.

In ESX, the v-floppy shows up as a standard floppy device (such as /dev/fd0). This is setup in ESX by adding these configuration lines to the VMX file:

floppy0.present = "True"
floppy0.filetype = "file"
floppy0.filename = "floppy.img"
floppy0.startConnected = "true"

In XEN, the script xen_deploy.pl assigns the v-floppy to /dev/hdb. At OS boot time, the activation engine mounts /dev/hdb1 to access the v-floppy, which is attached as a virtual IDE device (such as /dev/hdb), because the standard floppy /dev/fd0 device is not supported.

disk = [ 'file:/etc/xen/images/vm2/floppy.img,hdb,r','file:/etc/xen/
images/vm2/WAS.va,hda,w' ]

The script copies the activation profile XML file onto the new v-floppy disk. Finally, the scripts modify the configuration file of the new virtual machine with the amount of memory, number of CPUs, and the MAC address that are specified on the command line. After this final configuration step, the virtual machine is ready for power on.

Rather than creating your own deployment tools using the sample scripts provided here, Tivoli Provisioning Manager can be used to automate the deployment. The deployment steps described above are provided in the IBM Automation Package for Virtual Software Appliance available for download from the Open Process Automation Library (OPAL). The sample workflows copy the images, create the XML activation file, create the virtual floppy, and perform virtual machine registration to the hypervisor. In addition, Tivoli Provisioning Manager provides a graphical user interface for selecting and customizing the images, as well as supports the deployment of multiple images as one composite appliance.


Auto activation

Now, it's time to enjoy the benefits of automation. Turn on the power to the VM, watch the activation engine run, and your new virtual machine should automatically activate itself. Each activation script runs in the order specified, with command line options obtained from the activation engine by scanning the virtual floppy disk for matching activation profile data for each script.

The results of each activation script execution are stored in log files under a subdirectory called AR (for activation results). Examine this directory to debug problems, or to see the status of activation. Since debugging activation scripts is a common task, a manual method for re-running the scripts is provided. You can rerun all of the activation scripts without rebooting the machine. First, delete all the files in the AR directory and then re-run the activation scripts using this command:

%AE.sh -i /opt/IBM/AE/AP/WAS.ap


Activation script samples

The first activation script you need is one that customizes IP network identity. The previous article included the manual steps to accomplish network customization. Included here is an activation script, ConfigNET.pl, that automates the process of setting the hostname, IP address, gateway, DNS server, and so on, for a cloned SUSE V10 virtual machine. Add this script to the activation engine to automatically activate the network identity. The script automatically changes the /etc/hosts file, /etc/HOSTNAME, and the default gateway in the /etc/sysconfig/network/routes file, plus it fixes the ifcfg-eth* file to have the specific configuration options specified on the command line, and the MAC address to match the virtual hardware. The command line options used in the script are:

-bootproto - either dhcp or static ip configuration
-hostname - the new hostname of the virtual machine
-domain - the new domain name like ibm.com
-ipaddr - with static configuration set the actual IP
-netmask - with static configuration set the netmask
-pri_dns - primary dns server
-sec_dns - secondary dns server

For the WebSphere template included with this article, an activation script is used to set the Linux root password automatically. The example shell script, ConfigPWD.sh (below) is included for download.

#!bin/sh
#
# A utility for changing the root password.
#
# usage: sh ConfigPWD.sh –root "pw4vm"
while [ $# -ne 0 ]
do
	case $1 in
		-root*)
		Password=$2
		;;
		*)
		;;
	esac
	shift 2
done

echo "root:$Password" | chpasswd

Sample download

To help you develop automation for deploying and activating your virtual images, the code samples listed here are provided in the download file with this article:

  • General purpose activation engine: AE.tar
  • Samples for using the activation engine with a WebSphere/SUSE V10 template: activation_scripts.tar
    • Activation logic: WAS.al
    • Linux network configuration script: ConfigNET.pl
    • Linux root password script: ConfigPWD.sh
    • WebSphere configuration script: ConfigWAS.pl
    • Activation profile: WAS.ap
  • General purpose samples for deploying virtual machines -- deploy_scripts.tar
    • For XEN: xen_deploy.pl
    • For VMware: esx_deploy.pl

Conclusion

You can deploy and activate virtual machines automatically using the techniques presented in this article. The manual activation steps can be automatically handled at the first boot of a new clone. In addition to the activation engine, this article also presented two automatic deployment scripts, one for VMWare ESX, and one for XEN, plus two useful activation scripts to help you change the network identity and set the root password. The techniques presented here will help you save time by simplifying your virtual image deployment and activation.


Download

DescriptionNameSize
Code samplesvisamples.zip26 KB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=248398
ArticleTitle=Automating deployment and activation of virtual images
publish-date=02222008