This series of articles has been discussing customization capabilities of the IBM WebSphere CloudBurst Appliance. Part 1 provided an overview of the different customization capabilities of the appliance, and explained when and why you would employ these capabilities. Part 2 explored the use of editing patterns to create custom WebSphere environments. Part 3 further explored creating such custom environments by discussing the role of script packages as a means to save the configuration of your WebSphere Application Server environment directly into the pattern.
Parts 2 and 3 focused specifically on techniques that enable you to customize the topology and configuration of your middleware layer via pattern editing. While those customizations are important, customization of the operating system layer is also often required.
In WebSphere CloudBurst, the operating system layer is contained within IBM WebSphere Application Server Hypervisor Edition. This is a new virtual image offering of WebSphere Application Server that includes an operating system, WebSphere Application Server binaries, WebSphere Application Server profiles, and an IBM HTTP Server all pre-installed, pre-configured, and pre-tuned, as shown in Figure 1. The virtual image is packaged according to the Open Virtualization Format (OVF) standard.
Figure 1. WebSphere Application Server Hypervisor Edition
When you build a WebSphere CloudBurst pattern, you select a particular version of WebSphere Application Server Hypervisor Edition on which that pattern will be based. When the pattern is deployed, each of the parts in the pattern results in the creation of a virtual machine containing the WebSphere Application Server node type represented by the part (Figure 2).
Figure 2. WebSphere CloudBurst pattern deployment
Each virtual machine is created from the WebSphere Application Server Hypervisor Edition virtual image that was selected to be the basis of the pattern. Parts 2 and 3 in this series provided examples of how to influence both the WebSphere Application Server topology and the configuration of the WebSphere Application Server cell that is comprised of virtual machines. This article will explain how you can customize the underlying WebSphere Application Server Hypervisor Edition to deliver customizations at the operating system level of these virtual machines.
There are many reasons for directly customizing the WebSphere Application Server Hypervisor Edition (hereafter referred to as Hypervisor Edition) virtual images shipped with WebSphere CloudBurst. Doing so enables you to introduce custom operating system configurations. This might mean installing custom software (like anti-virus programs, JDBC drivers, monitoring agents, and so on), altering operating system configurations (such as network timeouts), and much more. Customizing virtual images is a good way to capture the kinds of customizations that are needed in most, if not all, of your WebSphere Application Server environments. If there is functionality you want in every deployed virtual machine, directly adding it into the image is typically the fastest and easiest way to make this happen.
Customizing the Hypervisor Edition virtual images in WebSphere CloudBurst is accomplished through the process of extend and capture.
First, you select an existing virtual image and extend it. As a result, WebSphere CloudBurst creates a running virtual machine in the private cloud based off of the selected image, as shown in Figure 3.
Once the virtual machine is running in the cloud, you can login and install custom software or otherwise configure the operating system environment. When installing this new software or modifying the environment in the virtual machine, it is important that you understand the disk layout of the virtual machine. Hypervisor Edition is separated into four separate virtual disks, one disk each for the operating system, WebSphere Application Server binaries, WebSphere Application Server profiles, and IBM HTTP Server that exist in the image. You can introduce changes into the operating system, IBM HTTP Server, or WebSphere Application Server virtual disks.
You should not introduce customizations into the WebSphere Application Server profiles disk space, as they will be discarded during the capture phase of the extend/capture process. Namely, changes cannot be made anywhere in the /opt/IBM/WebSphere/Profiles directory, nor in any of its subdirectories. Employ the use of script packages to deliver customizations that affect the configuration in this area of the virtual machine. This restriction enables WebSphere CloudBurst to capture your extended WebSphere Application Server virtual image to support all the different parts (IHS, Deployment manager, custom node, and so on).
When you have made the desired changes to the virtual machine instance, the modified environment can be captured and stored as a virtual image in the WebSphere CloudBurst catalog alongside the other virtual images. When the appliance has successfully captured the new virtual image, it can be used as the basis for custom WebSphere CloudBurst patterns. The entire extend/capture process is depicted in the Figure 3.
Figure 3. Extending and capturing WebSphere Application Server Hypervisor Edition
The ability to produce customized virtual images and use them in an auditable manner to construct virtual systems is an important value proposition of the WebSphere CloudBurst Appliance. Think of the customization as the installation of additional software and capabilities to create a certified, supported virtual image. Once this has been performed and tested in accordance with your enterprise’s standards, the resultant image is captured and locked. You can then construct virtual systems based on this image, enabling configuration of the new capabilities using script packages on one or more of the virtual machines, in a repeatable and auditable way.
The remainder of this article will focus on a particular scenario that involves extending an image, installing custom software, capturing the resultant image, and storing it back into the WebSphere CloudBurst catalog. In addition, you will see how to use this image to build a custom pattern containing a script package that configures the newly installed software during pattern deployment. Finally, you will walk through pattern deployment and the resulting virtualized environment.
Use cases and the process for image customization, or extension, is probably best seen through an example. One of the most common examples is the inclusion of a monitoring agent in each image. The example here will use customization features of the appliance to produce an application environment that contains virtual machines with embedded IBM Tivoli® Monitoring Linux OS Agents. (Although this article explicitly shows the Tivoli Monitoring agent, this process can be followed for extensions of other agents, or for any other software product in general.)
Additional software, like agents, often needs configuration parameters that are unique for different deployment environments. For example, monitoring agents usually require configuration to communicate with a monitoring server. While this configuration can be hardwired into the embedded software agent, the solution is more flexible when the agent configuration is parameterized. This example shows how to combine the WebSphere CloudBurst extend/capture capability with the scripting and pattern capabilities (described in Parts 2 and 3 of this series) to configure the agent via script parameters. These agents will be configured here to communicate with an existing IBM Tivoli Enterprise Monitoring Server specified during deployment.
The example includes these major steps:
- Create an extended image and install additional software, in this case Tivoli Monitoring Linux OS Agent.
- Create a script package to configure the agent. In this example, the script runs at deploy time to configure the Linux OS agents in the virtual machines to report to the specified Tivoli Enterprise Monitoring Server.
- Create a custom pattern using the extended image. This pattern will also contain the configuration script.
- Deploy the custom pattern.
If you wish to follow along and perform these steps, you will need access to a WebSphere CloudBurst Appliance with permissions to deploy patterns, create patterns, and create new catalog content. In addition, you will need to have access to at least one existing virtual image in the catalog.
If you want to actually extend your image with the Tivoli Monitoring agent, you will also need to have access to the Tivoli Monitoring agent software, and both a Tivoli Enterprise Monitoring Server and an IBM Tivoli Enterprise Portal Server installation.
It is also important that the network utilized by the virtual machines created by WebSphere CloudBurst can communicate with the network hosting the monitoring server, in this case the Tivoli Enterprise Monitoring Server instance.
- Within WebSphere CloudBurst, image extension is the process that
enables you to create customized Hypervisor Edition images. Image
extension begins by selecting an image to start with from the
WebSphere CloudBurst catalog. In this case, start with WebSphere
Application Server Hypervisor Edition 126.96.36.199. Once the image
is selected, click the Extend button shown in Figure 4.
Figure 4. Extend icon in WebSphere CloudBurst
- Enter Name, Description, and Version information about the image you
want to create on the General Information dialog that displays (Figure
Figure 5. Basic information for the new image
- Next, provide deployment information for the extend process. Since
WebSphere CloudBurst will be creating a virtual machine in the cloud
based on this virtual image, you need to select a cloud group that the
virtual machine will be targeted to (Figure 6). You also need to
provide passwords that will be used to login to the virtual machine.
Figure 6. Deployment information for image extension
- The last configuration step before the image extension process begins
involves the virtual machine’s hardware configuration. During this
step, you can optionally change the default size of the four different
virtual disks, and change the default number of network interfaces in
the virtual machine, which is 1 (Figure 7). If the software you are
adding is sizable, you will need to increase the target disk size
accordingly. Click OK to begin the process.
Figure 7. Hardware configuring for the extended image
- WebSphere CloudBurst automatically creates a standalone server pattern
based on the image being extended. That pattern is then deployed by
WebSphere CloudBurst into the private cloud to create a running
virtual machine that can be used to customize the operating system
environment. When the deployment of the pattern is complete, the
status of the new virtual image is updated to Draft (Figure 8). At
this point, you can log into the virtual machine that was created as
part of the deployment and make any desired customizations to the
virtual machine, with the exception, of course, of changes to the
WebSphere Application Server profiles space. To do this, click on the
WAS 188.8.131.52 with ITM Agent link that appears in the In
the cloud now field.
Figure 8. Extended image in Draft status
- The virtual system that was created during the deployment displays
(Figure 9). Expand the Virtual machines section and then
collapse the single virtual machine that appears under this section.
Figure 9. Logging into the virtual machine
- From here, you can either SSH into the virtual machine directly from the console using the provided links, or you can use your own SSH client to login to the host that is shown in the Located at field. In either case, once you have logged into the virtual machine you can start making any desired customizations. In this example, you will in fact be installing additional software into the virtual machine.
- The additional software you will be installing in this example is the
Tivoli Monitoring agent. To install this software, you first need to
get the Linux OS agent from IBM Tivoli Monitoring Version 6.2.1
Interim Fix 2 (184.108.40.206-TIV-ITM-IF0002). Specifically, you will
be using 220.127.116.11-TIV-ITM_TMV-Agents-IF0002.tar from this URL:
- Once you have the software image, you need to make it available on the
virtual machine that was created as a result of extending the
Hypervisor Edition image above. You have two options for making the
software image available:
- Copy the TAR file to the virtual machine and then untar it.
- Untar the file to a disk that is mountable by the Hypervisor Edition virtual machine.
- After making the software image available, navigate to the directory
that contains the unpacked contents of the original TAR file. Once in
the appropriate directory, you can run the installation from a
terminal window (Figure 10). Simply press Enter to accept the default
install location and Enter again to create the specified install
Figure 10. Installing the Tivoli Monitoring Linux OS Agent
- Next, you are presented with a list of options for how you want to
install the agent (Figure 11). Choose option 1 to install the
products to the local virtual machine.
Figure 11. Choosing installation mode
- On the next panel, select option 1 to accept the license agreement for Tivoli Monitoring Linux OS Agent.
- On the following three panels, you are prompted to choose an encryption key, operating system support, and operating system. In each case, press Enter to accept the default for those properties.
- Next, you are presented with a list of products that are available for
installation (Figure 12). Select the Monitoring Agent for Linux
OS by entering the number
6and pressing Enter.
Figure 12. Choosing a product to install
- Confirm your selection by pressing Enter again.
- When the agent installation and initialization is complete, you are
asked if you want to install additional products (Figure 13). Press
Enter to indicate that you do not wish to install additional
Figure 13. Finishing the ITM Linux OS Agent installation
At this point, the Tivoli Monitoring Linux OS Agent has been installed. Although the message indicates that you can now configure the installed agent, you do not need to do that at this time. You will include a script package in patterns built from this image that automates the configuration of the agent each time a virtual machine containing the agent is created.
- You can now capture the image to store it in the WebSphere CloudBurst catalog. To do this, navigate back to the Virtual Images section in the WebSphere CloudBurst catalog (Figure 14).
- Select the WAS 18.104.22.168 with ITM Agent virtual image. The image
should still be in Draft state, and you can capture it by clicking the
capture icon in the upper-right hand toolbar.
Figure 14. Capturing the extended image
- Click OK to confirm the capture request and begin the capture
process. During the capture, the updated virtual machine disks are
transferred back to the appliance. Because these virtual disks are
quite sizeable (~20 GB before any customizations), you should have a
1GB connection between your appliance and the hypervisors in your
cloud. When the capture is complete and stored in the WebSphere
CloudBurst catalog, the status message will be updated (Figure 15).
Figure 15. The captured image
- At this point, you can optionally make the image read-only by locking it. You can also assign access to the image as desired.
As a result of extending and capturing the customized virtual image, you have a new virtual image called WAS 22.214.171.124 with ITM Agent stored in the WebSphere CloudBurst catalog. You can now use this new image to create custom patterns, thus ensuring that all the nodes in the WebSphere Application Server cell created by deploying such a pattern will contain installed Tivoli Monitoring Linux OS Agent software. However, simply having the agent software installed in the virtual machines does not give you much unless you correctly configure the agents to report back to a monitoring server, specifically a Tivoli Enterprise Management Server instance.
As seen in Figure 16, as the objective of deploying a pattern based on your new virtual image -- besides having a running WebSphere Application Server environment -- is to have a Tivoli Monitoring ITM Linux OS Agent up and running in each machine and to have those agents correctly configured to communicate with an existing Tivoli Enterprise Management Server instance.
Figure 16. Deployed pattern with configured Tivoli Monitoring agent
To achieve this objective with a custom pattern, you must create a new script package that will be part of the pattern. The script package will include a shell script that will configure the Tivoli Monitoring Linux OS Agent in the virtual machine so that it reports to the desired Tivoli Enterprise Management Server. The contents of the script file is shown in Listing 1.
Listing 1. Tivoli Monitoring Linux OS Agent configuration script
#!/bin/sh # # For WebSphere CloudBurst Appliance # Script to change ITM agent config to point to correct ITM server # PROGNAME=`basename $0` BINDIR=`dirname "$0"` ITM_DIR=/opt/IBM/ITM ITM_RSP=$BINDIR/configITMAgent.rsp echo "----------------------------------------------" echo " Show environment variables" echo "----------------------------------------------" set echo "----------------------------------------------" echo " Stop ITM Agent" echo "----------------------------------------------" $ITM_DIR/bin/itmcmd agent stop lz echo "----------------------------------------------" echo " Build response file for config of ITM Agent " echo "----------------------------------------------" # Environment variable ITM_TEMS_HOSTNAME if [[ "$ITM_TEMS_HOSTNAME" = "" ]]; then echo "ITM TEMS hostname was not passed in! Default to localhost." ITM_TEMS_HOSTNAME=localhost fi echo "ITM TEMS Hostname is $ITM_TEMS_HOSTNAME" # remove old response file, if it exists rm -f $ITM_RSP # build new response file echo "#ITM Response File" >$ITM_RSP echo "CMSCONNECT=YES" >>$ITM_RSP echo "HOSTNAME=$ITM_TEMS_HOSTNAME" >>$ITM_RSP echo "NETWORKPROTOCOL=ip.pipe" >>$ITM_RSP echo "----------------------------------------------" echo " Change config for ITM Agent " echo "----------------------------------------------" $ITM_DIR/bin/itmcmd config -A -p $ITM_RSP lz #--------------------------------------------------- # remove response file rm -f $ITM_RSP echo "----------------------------------------------" echo " Start ITM Agent" echo "----------------------------------------------" $ITM_DIR/bin/itmcmd agent start lz echo "" echo "Done"
Notice that the shell script makes use of a variable called ITM_TEMS_HOSTNAME. This variable represents the hostname of the existing Tivoli Enterprise Management Server installation, and will become part of the script package definition in WebSphere CloudBurst.
To create a new script package:
- Compress the shell script inj Listing1 into a file called itm_agent_config.zip.
- Navigate to the Script Packages section of the WebSphere
CloudBurst catalog and click the green cross in the upper left corner
to add a new script package (Figure 17). Name the script package
Configure ITM Agent, as shown in the figure.
Figure 17. Creating agent configuration script package
- Upload the itm_agent_config.zip file containing the shell script to configure the Tivoli Monitoring Linux OS Agent.
- Define the variable for the Tivoli Enterprise Management Server
hostname, and provide information that tells WebSphere CloudBurst how
to invoke the script within the .zip file. In the script package
definition (Figure 18), you can see the ITM_TEMS_HOSTNAME variable is
defined. You will supply the value for this variable when deploying a
pattern that contains this script package. In addition, a value for
the working directory field is supplied. This directory will be the
location to which the script package .zip file is unzipped. Finally,
the command that should be used to invoke the script package is
provided in the Executable field. With this information
specified, you can begin to use this script package to build custom
Figure 18. Defining the ITM agent configuration script package
- You can now create a pattern based on your custom virtual image. Navigate to the Patterns page and select an
existing pattern to clone. For this example, use the existing
WebSphere single server pattern (although any pattern could
be used). To clone the pattern, click the clone button in the upper
right toolbar. A panel will display that asks for information about
the new pattern you are creating (Figure 19).
Figure 19. Creating the custom pattern
In this example, the pattern is named WAS single server - ITM and, most importantly, the WAS 126.96.36.199 with ITM Agent is selected as the virtual image on which to base the pattern. This ensures that all virtual machines created as a result of deploying this pattern will be based on the custom virtual image you created earlier. In this case, that means all of the virtual machines will have the Tivoli Monitoring Linux OS Agent installed and running upon activation.
- Click on the pencil icon (directly to the left of the clone icon) to display the Pattern Editor (Figure 14), where you can update your pattern as desired. In this case, you will be including the Configure ITM Agent script package that you created earlier.
- Select Script Packages in the drop-down menu
displayed in the left side of the browser, then drag and drop the
Configure ITM Agent script package onto the Standalone
server part within the pattern as seen in Figure 20.
Figure 20. Updating the custom pattern
Again, although the WebSphere single server pattern was cloned in this example, any pattern can be cloned and configured with the Tivoli Monitoring Linux OS Agent. For multi-part patterns (for example, a WebSphere cluster), simply include the Configure ITM Agent script package on each part in the pattern. This will ensure that each virtual machine created during deployment is configured to report back to your Tivoli Enterprise Management Server instance.
- Click Done editing to return to the main pattern page. Here, you can optionally lock the pattern and grant access to the appropriate users and user groups. The pattern is now ready to be deployed into your private cloud.
To deploy the pattern:
- From the Patterns page on the WebSphere CloudBurst console, select the WAS single server - ITM pattern, and click the Deploy button in the center of the panel.
- Provide a unique name for the pattern deployment and click on the
Configure virtual parts link (Figure 21).
Figure 21. Pattern deployment panel
- Configure the standalone server virtual part for deployment. Part
of the configuration information you provide will be the value for the
variable that specifies the hostname for the Tivoli Enterprise
Management Server. In Figure 22, the hostname for the Tivoli
Enterprise Management Server is set to
Figure 22. Configuring virtual parts
The ITM_TEMS_HOSTNAME deployment parameter value will be passed down to the virtual machine created as part of this deployment. This means the script you included on the pattern part will have access to this information, thus the agents running in the virtual machine can be correctly configured to report to the Tivoli Enterprise Management Server. Know that communication between the deployed virtual machine and the Tivoli Enterprise Management Server implies the virtual machine created by WebSphere CloudBurst can successfully establish network communication with your Tivoli Enterprise Management Server instance. Verify before deployment that there are no firewalls between the virtual machines in your WebSphere CloudBurst private cloud and the Tivoli Enterprise Management Server instance. If there are firewalls, you will need to provide the proper means for your virtual machines to communicate with the Tivoli Enterprise Management Server instance.
- When the virtual part has been configured, simply click OK
to deploy the pattern. From this point, WebSphere CloudBurst takes
over and decides where to place the virtual machine in your cloud. The
status of your virtual system in the WebSphere CloudBurst console will
be updated once the WebSphere Application Server cell is up and
running. (Figure 23)
Figure 23. Deployed virtual system
At this point, you are ready to confirm the correct configuration of the Tivoli Monitoring Linux OS Agent in your virtual machine.
- Check the trace files associated with the configuration script. You
can do this from the Virtual Systems page in WebSphere CloudBurst.
Collapse the Virtual machines section, and then collapse the
section for the specific virtual machine (Figure 24).
Figure 24. Trace logs for the Configure ITM Agent script package
- In the details for the virtual machine, locate the section labeled Script Packages and click on the remote_std_out.log for the Configure ITM Agent script package. This log file should contain the messages present in the configuration script (Listing 1). Most notably, you should see a message that specifies the Tivoli Enterprise Management Server hostname supplied during deployment, and the last message in the log should indicate that the agent was successfully started.
- In addition to the script package logs, make note of the hostname
in the Located at field under the General information section
above. In this example, the hostname is
cbvm-111.rtp.raleigh.ibm.com. If you have access to a
Tivoli Enterprise Portal Server, a shortened form of this new hostname
should appear in the console in a minute or two. From the Tivoli
Enterprise Portal Server console, you can view a graphical
representation of the data being reported to and collected by the
Tivoli Enterprise Management Server. In addition, sub-entries for each
reporting agent will show Linux operating system statistics. In Figure
25, the disk usage for the virtual machine (cbvm-111) created as a
result of deploying the custom pattern is displayed in the Tivoli
Enterprise Portal Server console.
Figure 25. Virtual machine in the Tivoli Enterprise Portal Server
The WebSphere CloudBurst Appliance was designed with the knowledge that WebSphere Application Server users build application environments that encompass customizations at multiple layers. One such layer of customization is the operating system environment. By using the image extension and capture facilities provided by the appliance, you can very easily extend base virtual images, install customizations, and capture those customized images. Once in the WebSphere CloudBurst catalog, these customized images can be used to construct as many different patterns as needed. These patterns can then be dispensed by appliance users, and each virtual machine created as a result of deployment will be created from the customized virtual image. The ability to create, capture, and utilize custom WebSphere Application Server Hypervisor Edition virtual images in WebSphere CloudBurst can be leveraged to ensure a consistent, yet customized operating system configuration for your application environments.
- More in this series
- Part 1: Creating highly customized private clouds
- Part 2: Using WebSphere CloudBurst to customize a WebSphere middleware environment
- Part 3: Using script packages for customizing above and beyond patterns
- Cloud computing for the enterprise
- Part 1: Capturing the cloud
- Part 2: WebSphere sMash and DB2 Express-C on the Amazon EC2 public cloud
- Part 3: Using WebSphere CloudBurst to create private clouds
CloudBurst Appliance product information
Cloud Computing Journal
there value in cloud computing?
WebSphere Cloud Computing for Developers
WebSphere CloudBurst Appliance videos
WebSphere CloudBurst Appliance Forum
A view from the clouds: Cloud computing for the WebSphere developer
Follow us on
Dustin Amrhein joined IBM as a member of the development team for the WebSphere Application Server. While in that position, Dustin worked primarily on web services infrastructure and web services programming models. In addition, Dustin worked on the development of a RESTful services framework for Java runtimes. In his current role Dustin is a WebSphere Client Technical Professional.
Ken Klingensmith is a Certified IT Specialist and one of the founders of Worldwide WebSphere, an IBM Software Group team providing technical sales support and enablement globally since 1998. Ken specializes in the WebSphere Application Server, WebSphere Virtual Enterprise and WebSphere CloudBurst products, enabling field technical sales in emerging versions, working with customers, and helping guide product direction. Before joining IBM, Ken was a Senior Systems Engineer with Transarc Corporation supporting the Encina Online Transaction Processing product.
Chris Ahl is an Advisory Software Engineer in IBM's Software Group, Tivoli division and works in the Autonomic Computing and Component Technologies area. During his 20 years in software development at IBM, he has been involved in many software projects dealing with network management, systems management, device management and installation technologies. He received a Bachelor's degree in Computer Science from RIT (Rochester Institute of Technology).