Using virtual image templates to deploy WebSphere Application Server


The most common motivation for virtualization is consolidating servers to improve server utilization, and to reduce operational space and power expenditures. Once you start heading down the virtualization path, there are additional advantages. One significant advantage is the ability to rapidly provision new environments by using libraries of virtual image templates. This is done by creating pre-installed, pre-configured image templates that, with a small amount of customization, are quickly activated to create new running virtual images. This technique is extremely useful for setting up new environments, especially for development and testing.

This article offers an approach and sample scripts for using IBM® WebSphere® Application Server Network Deployment (ND) inside virtual machine templates. The approach leverages new capabilities provided in WebSphere Application Server V6.x that simplifies the process of creating a template installation that can be easily copied and customized for a new host. This article covers techniques for customizing the WebSphere Application Server ND installation, and also discusses how to include your WebSphere-based applications.

The techniques discussed here apply independently of the underlying virtualization technology and guest operating system you choose. The actual network and operating system customization varies for different platforms and hypervisors.

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.

Four major steps

The process to deploy WebSphere Application Server using virtual image templates includes four major steps, shown in Figure 1:

  1. Create the base installation image.
  2. Decide on which WebSphere Application Server customization to expose to enable the image to be customized and reused in different environments.
  3. Deploy the image.
  4. Activate the image in the new host environment.
Figure 1. Steps to deploy WebSphere Application Server using a virtual image template
Figure 1. Steps to deploy WebSphere Application Server using a virtual image template
Figure 1. Steps to deploy WebSphere Application Server using a virtual image template

Let's take a closer look at each of these steps.

1. Creating the virtual image

Your first decision when creating the virtual image is determining what specific software you will install in the template image. Since you want to be able to reuse the template to instantiate different environments, you only want to install components common to many environments. A complete WebSphere Application Server Network Deployment installation and configuration process, shown in Figure 2, includes installing the software (operating system, WebSphere Application Server, other middleware, one or more applications, and so on), creating profiles, federating nodes, and creating clusters. Depending on your needs, your template image might only include a subset of these components. This article provides three example templates (blank, flexible, and fixed) to address a range of requirements.

Figure 2. WebSphere Application Server Network Deployment installation and configuration steps
Figure 2. WebSphere Application Server Network Deployment installation and configuration steps
Figure 2. WebSphere Application Server Network Deployment installation and configuration steps

Operating system installation

The first thing you will want to do is create a "golden" operating system image to use as the basis for all images. Any company standard software, such as monitoring or auditing agents, can also be included in this base image. With WebSphere Application Server V5, we saw a set of customers just use virtual image templates with the operating system, and then handle all WebSphere Application Server installations through traditional processes. While this is still an option, we are seeing customers being very successful in replicating WebSphere Application Server as part of the virtual image template, and the WebSphere Application Server V6 profile capabilities make this even easier.

The initial virtual image template creation is specific to your target hypervisor, so follow the directions provided by your hypervisor:

  • For VMware, the process of creating a new virtual machine is available in a wizard dialog. From the VMware Workstation or VMware ESX Server program, click on File => New => Virtual Machine to get started.
  • For XEN, the process of creating a new virtual image has several solutions. We used the YAST tool included in SUSE Enterprise Server V10 for creating a virtual image. Select System => Virtual Machine Management => Run an OS installation program to get started.

Once the image is created, you install the guest operating system into the image using the standard OS installation procedure. Any other common software (such as operating system monitoring agents) that you want in all images is also installed at this stage.

Installing WebSphere Application Server

For the WebSphere Application Server installation, you'll want to look at the different applications environments where the image will be replicated and choose an installation that is appropriate. In most cases, your template install will be close to a default installation of WebSphere Application Server.

To add WebSphere Application Server into the image template, install WebSphere Application Server using the standard installation process -- except the operating system that you install to is the guest OS already installed in the image. You do not need to create a profile or configure any parameters during the installation.

You might want to consider creating an Installation Factory Custom Install Program (CIP) to perform this initial installation into the template. The CIP is easily reused if you need to create templates for multiple hypervisors (such as VMware and XEN), or for also performing physical installations. Techdocs are available with more information on IBM Installation Factory for both Version 6 and Version 6.1.

Profile creation

After the default installation of WebSphere binaries is completed, you have created what we call a blank template. The installation does not include any profiles. Profiles can be created separately, during the deployment and activation phase. Using a blank template, application deployment and topology construction is also done at deployment and activation time or post-deployment. As shown in Table 1, this approach is the most flexible, but it also takes the longest time to activate. (See Systems Management for WebSphere Application Server V6, Part 3 for more information on profiles.)

There are scenarios where creating the profiles and installing applications directly into the template provide an interesting alternative. Although this approach might require you to create more templates, there is significantly less processing required at deployment or post-deployment. As you will see later, WebSphere administrative tasks changeHostname and renameNode are leveraged in the customization scripts to quickly modify existing profiles for new environments. This support is available starting with WebSphere Application Server V6.0.2.27 or V6.1.

Two additional example templates are included here, flexible and fixed, in which the profiles and (optionally) applications are included directly in the template, as shown in Figure 2. The fixed template includes even more, by pre-federating nodes and creating clusters. These templates can be used with WebSphere products such as IBM WebSphere Portal and WebSphere Process Server, so the installation and configuration is only done once at template creation time. Additionally, this approach is nice for applications that cannot be exported into a .CAR file.

The flexible template supports different topologies. All the profiles are created in a single template before deployment, and then the appropriate profile is activated in the deployment phase. The fixed template only supports a single topology. The full topology is configured during the template creation phase. The only step required at activation time is to customize the names of nodes and servers, making this the fastest and easiest to activate. If you need to deploy the same application and environment multiple times, a fixed template is an excellent option.

Table 1 shows a comparison between the different templates and their recommends uses.

Table 1. Comparison between the different templates and recommends uses
Use or propertyBlank templateFlexible templateFixed template
FlexibilityOne template supports many apps & configsOne template supports different topologiesSingle application, single topology
Template image sizeSmallest (no profile or apps)Larger (includes profiles)Larger (includes profiles)
Activation or post-deploy activitiesIncludes profile creation, topology construction, application deploymentIncludes topology constructionJust change names and start
SpeedLongest activation timeMedium activation timeFastest activation
Recommended Use
  • Many different applications
  • With .CAR files
  • When post-deployment automation already developed
  • With complex applications
  • With applications that don’t work with .CAR files
  • WebSphere family products
  • For deploying the same application or topology multiple times
  • ISV applications
  • WebSphere family products

If you choose to use a flexible or fixed template, creating profiles is required in this step. There are two ways to create profiles: use the profile management tool with a graphical interface, or use commands. The profile management tool is used here. (The second method will be described later.)

In graphical mode, use this command:


A graphical interface prompts you to follow the instructions and input customized parameters step by step.

For a flexible template, you create three profiles: default, dmgr, and managed. In the deployment phase, you can derive customized standalone, deployment manager, managed nodes, or a cell from these three pre-created profiles.

For a fixed template, you must first determine the topology. This article shows a Network Deployment cluster with a deployment manager and two managed nodes as an example, and each managed node has one application server as the cluster member. Therefore, at this time, you create a deployment manager and two managed node profiles, which are ready to be federated with the deployment manager.

Topology construction

As shown in Figure 2, the cell topology for a fixed template is actually built out during the creation of the template. Therefore, you configure the created profiles to build the topology at this time. The first thing to do is to start the deployment manager using this command:


You then federate the two managed profiles with the deployment manager as its managed nodes using this command:


You can then create a new cluster using the Web console of the deployment manager and add cluster members according to your requirements. Updating attributes of the cluster or the application servers, such as JVM heap size or the log file size, is also done at this time.

Installing applications

WebSphere applications can optionally be installed directly into the template (flexible or fixed), imported from a .CAR file during activation (blank/standalone), or handled post-deployment. If you already have existing application deployment scripts, these scripts can be included in your deployment process.

Leaving the application out of the template maximizes your flexibility. If your application can be exported into a .CAR file, this file can be imported as part of the standalone node activation process, enabling the same template to support multiple applications.

However, some applications, including those using the Service Integration Bus (SIBus) do not work as .CAR files. Additionally, if you have many applications to deploy in the same server, .CAR file import can be time consuming. In these cases, the flexible or fixed template is a good alternative.

If you choose to include the applications in the template, you should deploy them now, following your standard procedures.

2. Providing customization files

After the template image is installed, you need to decide how to quickly activate the image for different WebSphere environments. When a template image is activated to create a new environment, there are a set of customization steps required, which include network changes for the new image location, and customization of the WebSphere environment. Although all of these steps can be automated, we will focus only on automating what is typically required for WebSphere Application Server customization. (See Automating deployment and activation of virtual images, which provides sample automation for the operating system, a framework for including the WebSphere Application Server automation, and deployment scripts.)

The sample customization script included with this article, ConfigWAS, takes a small set of user-provided customization parameters to support instantiating the template image for specific environments. The functions provided by the script are:

  1. WebSphere profiles: Handles the creation or updating of WebSphere profiles, including standalone nodes, deployment managers, managed nodes, and cells.
  2. Include applications: Handles the import of WebSphere applications.
  3. Topology construction: Handles creating or updating the selected topology, including starting the deployment manager, adding nodes, creating clusters, remapping application modules and starting application servers.

The blank template script is designed to work on WebSphere Application Server V6.0.2 or V6.1. When you look at the script, you'll see that most of the capabilities are provided for both releases, but the command syntax is different. The only script capability that is provided only for V6.1 is the option to configure security. WebSphere Application Server V6.1 made admin security configuration a profile creation option, whereas additional code is need to enable a similar capability on V6.0.2. Additionally, certain commands within the flexible and fixed topology customization require at least V6.0.2.27 or V6.1.

The specific sample script to choose as your starting point depends on how much you included in your template image. As shown in Table 2, the customization scripts perform different actions, depending on the template. For example, a blank template requires profiles to be created via the ConfigWAS customization script, whereas the flexible and fixed templates only require the ConfigWAS script to update existing profiles.

Table 2. Customization time actions
NodesFederateFederate & renameNo change
ClustersCreateCreateNo change
ApplicationsImportRemapNo change

Creating the profiles

For our purposes, creating profiles dynamically makes using WebSphere Application Server ND V6 within a virtual image template much easier than in prior releases. The sample customization script, used with the blank template, supports creating different types of WebSphere environments using one virtual image template, and provides these options:

  • Deployment manager
  • Managed mode with application server
  • Standalone node
  • Cell (deployment manager plus a managed node with application server)

The required profile(s) are created by the script using the WebSphere createProfiles command. For example, the WebSphere Application Server V6.1 command is:

$CREATEPROFILE_CMD = "${WAS_HOME}/bin/ -create "; #ver 6.1
$CREATEPROFILE_CMD .= "-enableAdminSecurity true ";

Updating the profiles

In the flexible or fixed templates, the existing profiles need to be updated. For standalone and deployment manager, this is done with just the changeHostName command, like this:

<MN_PROFILE_HOME>/bin/ -conntype none
wsadmin>$AdminTask changeHostName { -nodeName <nodename> -hostName <new_hostname> };

For managed nodes, the renameNode command is also required to avoid managed node name conflict after federation. During renameNode processing, WebSphere Application Server connects to the deployment manager, stops all servers on the node, changes the node configuration on the deployment manager, and then synchronizes nodes. Finally, it changes the node name of all the configuration files on the node.

<MN_PROFILE_HOME>/bin/ <dmgr_host> <dmgr_port> <new_nodename>

Including applications

Including applications via the customization script is available for standalone nodes only. The script takes advantage of the new WebSphere Application Server V6 capabilities to export/import profiles (.CAR file). This technique supports using a single template image to instantiate different applications by just modifying the input parameters to the script with the name of different .CAR files.

To create a .CAR file to use with your WebSphere Application Server template image, issue the ExportProfile command from a standalone node, as in:

$EXPORT_PROFILE_CMD  = ' -conntype NONE -c "\$AdminTask exportWasprofile 
{ -archive '. $EXPORT_PROFILE_FILE .' } "';

In the ConfigWAS script, after the new profile is created, a subsequent ImportProfile command is executed to import the applications from the .CAR file. WebSphere Application Server automatically adjusts the imported profile for the new host environment. The ImportProfile command is executed as follows:

$IMPORT_PROFILE_CMD  = ' -conntype NONE -c "\$AdminTask
importWasprofile { -archive '. $IMPORT_PROFILE_FILE .' } "';
$i_result = 

Limitations: The .CAR file must be exported and imported using standalone nodes. Do not try to export your applications from an existing cluster, as this will not work properly. Also, the current ExportProfile command does not handle messaging and, therefore, if your application uses messaging, you must also include customization script logic to configure the service integration bus (SIB).

Creating cluster and cluster members

For the blank and flexible templates, any clusters are created via the customization script. The fixed template already contains the cluster setup and no additional customization is required via the script.

For creating a cluster, you first create a new cluster using the wsadmin AdminTask object:

$AdminTask createCluster {-clusterConfig {-clusterName ${ClusterName}} -replicationDomain
{-createDomain true}}

Then, save the configuration changes and synchronize the nodes. To creating a cluster members:

$AdminTask createClusterMember {-clusterName ${ClusterName} -memberConfig {-memberNode 
${HOSTNAME}Node01 -memberName ${HOSTNAME}Server01 -genUniquePorts false -replicatorEntry 
true} -firstMember {-templateServerNode ${HOSTNAME}Node01 -templateServerName 

You also need to save the configuration and synchronize the nodes.

Remapping application modules

WebSphere Application Server permits the remapping of application modules. This includes changing the mapping from one server to another, or a cluster, using the MapModulesToServers option of wsadmin AdminApp object.

set optionlist [list -MapModulesToServers $listofapp]
puts "$AdminApp edit $app list $optionlist"
$AdminApp edit $app $optionlist
$AdminConfig save

For the blank and flexible templates, you might want to leverage this function to transfer the application modules from the application server in the standalone node to the cluster in the new Network Deployment environment.

Starting WebSphere Application Server

To create running WebSphere Application Server environments, additional commands need to be executed. The script includes sample code to start the different topologies.

For deployments that include the WebSphere deployment manager, the sample script design follows the required start order for WebSphere Application Server and starts the deployment manager first, using the WebSphere startManager script:

$RESULT = '${WAS_HOME}/profiles/${dmgr_profile_name}/bin/ $USER_PASSWD';

Once the deployment manager is started, if the blank template image is creating managed nodes, the WebSphere Application Server addNode command shown below are included to add a managed node to the deployment manager:

$RESULT = '${WAS_HOME}/profiles/${appsrv_profile_name}/bin/ ${DMGR_FULLNAME}
$RESULT = '${WAS_HOME}/profiles/${appsrv_profile_name}/bin/ $USER_PASSWD';

All template scripts issue a start server command.

Deploying and activating the virtual image

Once you have the template image built and the customization script tailored and included, you are ready to activate the virtual images to support your different WebSphere Application Server environments. This requires you to:

  1. Clone the template image for the new host platform
  2. Customize the network and operating system
  3. Run the customization script.

The steps here describe how to manually perform these steps. See Automating the deployment and activation of virtual images for information on automating these steps.

Cloning the virtual image

To activate the WebSphere Application Server template image, you copy the image files and the virtual machine profiles:

  • For a XEN virtual image, this includes copying two files: the image file of the virtual machine and the XEN configuration file (containing the XEN virtual machine info about kernel, name, vcpus, memory, vif, and so on). The default vm configuration file directory is /etc/xen/vm/, and the vm image file directory is /etc/xen/images/.
  • For VMware ESX Server V3, you copy the image file and the corresponding configuration files. For example, for a virtual machine named "WebSphere," you need to copy the WebSphere-flat.vmdk, WebSphere.nvram, WebSphere.vmdk, WebSphere.vmsd, WebSphere.vmx, and WebSphere.vmxf files from the /vmfs/volumes/ directory to the new environment.

Customizing the operating system and network

After the virtual image is copied to the hypervisor, you can specify any changes to the default resource allocation of CPU and memory required by the operating system in the new environment.

  • If you are using XEN, the resource information is located in the configuration file.
  • For VMware ESX Server V3 virtual images, the configurations are in the .vmx file.

The next step in bringing up a virtual image is customizing its network identity, which is often one of the trickier areas of relocating virtual images. The specifics of this step depend on your hypervisor and operating system, as well as your company's networking policies. In some environments, you might be able to set up your network so that the images can be moved without changing IP address, host name, and domain. This technique can be very useful, especially when making a copy of a production environment, setting up an isolated network to apply changes and test, and then moving the images back to production. When appropriate, we certainly recommend considering this technique, as it should work independent of the software inside the image.

However, if your situation requires you to change host name and IP address of the virtual image during this step, then the operating system's corresponding network interfaces and the network-related lines in the virtual machine configuration file need to be specified to enable the virtual machine to be properly booted up.

Before editing the network information inside the virtual image, the network configuration files outside the virtual image should be modified:

  • For VMware ESX server V3, you need to edit or remove the uuid lines from the .vmx file to remove the identifier of the original physical computer.
  • If you are using XEN, make sure you assign the right MAC address for the network adaptor in the configuration file. The MAC address is changed by modifying the configuration file for the image vif=[ 'mac=00:16:3e:84:8b:01' ] and selecting the last 6 hex digits. Each virtual machine must have a unique MAC address, and failure to provide a unique MAC address to each clone can cause network problems.

Next, the hostname and network settings inside the cloned virtual machine need to be configured. For example, follow these steps to configure a SUSE Enterprise Server V10 guest operating system:

  1. Modify the [/etc/hosts] file with new hostname, domain, and ip information.
  2. Set the [/etc/HOSTNAME] to contain just the short hostname.
  3. Change the default gateway in the routes file [/etc/sysconfig/network/routes].
  4. Fix the network configuration by editing [/etc/sysconfig/network/ifcfg-eth*]. This can be called ifcfg-eth0 or ifcfg-eth-id-00:16:3e:84:8b:01:
    1. Use BOOTPROTO='static' to chose static ip configuration.
    2. Modify other network settings as required; for example, IPADDR=''.
    3. Add line DHCLIENT_SET_HOSTNAME='myNewHostname'.

Customizing WebSphere Application Server

Use the ConfigWAS customization script to instantiate the virtual image template in the new environment. The steps involved are the same for the blank, flexible, and fixed templates, with some variation in the specific parameters.The script is designed to accept input from the console or through an XML parameter file. If the XML input parameter file is not present, the script will prompt for input from the console.

After the network is properly configured, invoke the ConfigWAS script inside the virtual image using the perl ConfigWAS command. Follow the prompts on the console to create your desired configuration options. Help is available by typing [h] or [help] in response to any question.

To automate this process, create a myfile.xml file based on the example provided. When the customization script is invoked, you add the command line option perl ConfigWAS -type [blank|flexible|fixed] -xml myfile.xml. This causes the sample script to run without prompting.

The XML file contains installation values. The possible XML parameter name value pairs are shown below. Parameters that have specific options are listed in parenthesis as value="(option1|option2|option3)". The parenthesis should be removed during actual XML generation. Some parameters are required for certain configurations only. (Note that the EnableSecurity option only works on WebSphere Application Server V6.1.)

<xml solution-name="WAS">
  <software-resource name="WAS_V_6">
    <parameter name="ConfigureType" 
    <parameter name="DMHostName" value="dmgrhost"/>
    <parameter name="DMDomainName" value=""/>
    <parameter name="EnableSecurity" value="(y|n)"/>
    <parameter name="SecureAdminId" value="wsadmin"/>
    <parameter name="SecureAdminPassword" value="password"/>
    <parameter name="ImportProfile" 

To create a WebSphere Application Server ND environment across three virtual machines using the same image template, copy the template twice: once for the deployment manager and once for each managed node. Below is an example of the XML files for activating a flexible template with two managed nodes, as shown in Figure 3. Follow these same steps, modifying the XML files appropriately to create other topologies.

Figure 3. Deploying a WebSphere Application Server Network Deployment cluster using flexible template
Figure 3. Deploying a WebSphere Application Server Network Deployment cluster using flexible template
Figure 3. Deploying a WebSphere Application Server Network Deployment cluster using flexible template
  1. Copy a new virtual machine (vm1) from the template.
  2. Start and setup a new network environment in vm1.
  3. Run the script ConfigWAS using the XML file in Listing 1. This step retrieves the new hostname of vm1, changes the host name in the deployment manager profile of vm1 offline, and starts the deployment manager in vm1.
  4. Copy a new virtual machine (vm2) from the template.
  5. Start and setup a new network environment in vm2.
  6. Run the script ConfigWAS using the XML file in Listing 2. Under the covers, this step retrieves the new hostname of vm2, changes the hostname in vm2’s default node off-line, and federates vm2’s default node to dmgr, including app as managed node 1. This step then renames the node name of managed node 1 in Network Deployment according the hostname of vm2, creates a cluster in Network Deployment remotely from managed node 1, remaps the application modules into the new cluster, creates a cluster member remotely from managed node 1, and starts the server/application in managed node 1.
  7. Copy a new virtual machine (vm3) from the template.
  8. Start and setup a new network environment in vm3.
  9. Run the script ConfigWAS using the XML file in Listing 2. Under the covers, this step retrieves the new hostname of vm3, changes the hostname in vm3’s default node off-line and federates vm3’s default node to dmgr including app as managed node 2. This step then renames the node name of managed node 2 in Network Deployment according to the hostname of vm3, creates a cluster member remotely from managed node 2, and starts the server/application in managed node 2.
Listing 1. Dmgr’s customization file
<xml solution-name="WAS">
  <software-resource name="WAS_V_6">
<parameter name="ConfigureType" value="DeploymentManager"/>
Listing 2. Managed node’s customization file
<xml solution-name="WAS">
  <software-resource name="WAS_V_6">
    <parameter name="ConfigType" value="ManagedNode"/>
    <parameter name="DmgrHostName" value="wasdm"/>
    <parameter name="DmgrDomain" value=""/>

At completion, the example two node cluster topology is created. These same steps are performed for a fixed topology, but the under cover processing is significantly less because the federation and clusters are already done.

When you choose the ConfigWAS "Cell" option, which creates the deployment manager and managed node in the same virtual machine, the script starts the deployment manager for you prior to executing the add node and start server commands.

Update considerations

To simplify maintenance, VMware Virtual Appliance best practices recommends that virtual appliance developers separate read-only virtual appliance files from files that the user changes, such as configuration or application files. Since WebSphere profiles separate the user files (application and configuration data), including host name specific data, into a separate profile directory -- independent of the WebSphere installation binaries -- this separation is easy to accomplish.

To implement this best practice, the template image is set up onto two disks so that profiles created during the instantiation process are directed to a second logical disk. This enables you to apply fixes to the operating system or WebSphere binaries in the template image and deploy these updates without impacting any changes made during the customization process or post-deployment.

Limitations: WebSphere Application Server maintenance packages sometimes require changes to existing profiles, and in these cases, additional steps are required.

To create a WebSphere Application Server virtual image template across two logical disks, make these changes before installing WebSphere Application Server and your applications:

  1. Initially create a second empty virtual disk with enough disk space to hold your applications and WebSphere profiles. This step is hypervisor-specific, so follow your hypervisor directions for configuring logical disks. Here is an example for the configuration file for a XEN virtual machine with two logical disks, called "websphere.disk" and the "profiles.disk":

    Figure 4. VM profile configuration for XEN virtual machine with two logical disks
    Figure 4. VM profile configuration for XEN virtual machine with two logical disks
    Figure 4. VM profile configuration for XEN virtual machine with two logical disks
  2. After you create the empty logical disk and configure the virtual machine profile, the file system configuration inside the virtual machine needs to be updated. Map the installation directory of your WebSphere profiles, /opt/IBM/WebSphere/AppServer/profiles, to the second logical disk. Again, the specific syntax depends on the operating system and hypervisor. Here is an example of the configuration file (/etc/fstab) for a XEN virtual machine using SUSE Enterprise Server V10 as the guest operating system:

    Figure 5. File System configuration for XEN virtual machine with two logical disks
    Figure 5. File System configuration for XEN virtual machine with two logical disks
    Figure 5. File System configuration for XEN virtual machine with two logical disks


Server virtualization provides the capability to rapidly provision new environments by creating template images for quick instantiation. WebSphere Application Server V6 profile capabilities make creating and instantiating virtual templates very easy. Using scripting, WebSphere Application Server customization can be automated to rapidly provision new WebSphere environments.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Using virtual image templates to deploy WebSphere Application Server