The article uses the term "virtual appliance" to refer to one or more files needed to instantiate a virtual machine using a virtualization technology and a description of these files along with their contents in an OVF standard-based metadata file. Most of the article focuses on AIX virtual appliances built on a basis of an mksysb image for instantiation of a System p® logical partition (LPAR). A subset of a single System p machine can be organized as an LPAR that contains hardware resources and operates as an independent system. The mksysb image format is a backup format for the AIX main volume group, a logical disk capable of encapsulating one or more physical storage disks. In the scenario described by this article, mksysb will be used to clone a server. Network Installation Manager (NIM) is the AIX technology used to convert an instance of a source LPAR environment into an mksysb image file and to create a different, destination LPAR instance from the image.
Note that to perform the steps described in the article, we used the AIX V6.1 operating system running on a System p PowerPC 5 physical server with eight dual-core 2 GHz CPUs, 64 GB (2 GB per LPAR) of RAM and a low seek-rate hard disk. Figure 1 provides an overview of the steps for building the appliance and the changes made to the source environment by each of the steps.
Figure 1. Overview of the source environment including the node and LPARs for creation of the virtual appliance
Prepare the source LPAR environment
The AIX virtual appliance source environment mentioned earlier in the article is an LPAR instance created specifically to be converted into an mksysb image using NIM. Assuming that the physical server chosen to host the source environment is named snode, then before the mksysb image can be created, snode should host at least two LPARs:
- An instance with the installation of the NIM component (we assume it has nim_lpar as the hostname). The AIX version for NIM on this instance should be at equal or greater version than the AIX version on snode. NIM is included in AIX and NIM server software and can be installed as part of bos.sysmgt.nim.master fileset (See Resources for the chapter "Setting up a basic NIM environment").
- A mksysb source environment instance for an installation of Application Server (we'll use was_src_lpar for the hostname)
The source LPAR should be defined as a NIM client before NIM can convert it to an mksysb image. To create the definition, login as root to nim_lpar, run:
smitty nim_mkmac |
and provide the host name of the source LPAR environment as value of Host name of machine field (for instance, was_src_lpar). It is also possible to use the nim -o define command (See Resources for the example "Creating a non-/usr SPOT from a NIM lpp_source").
A SPOT (Shared Product Object Tree) resource must exist to allow NIM to restore an image to the destination LPAR. SPOT is a NIM hierarchy of the /user file system. Before proceeding, ensure you are logged in as root to nim_lpar and create a SPOT file (See Resources for the chapter "Defining NIM clients"). In this article, we assume that the created file is saved to /tmp/was_mksysb_spot.
An fb_script is a file that is used to configure the destination LPAR environment (we call it was_dst_lpar) after the OS installation process is completed on the LPAR and when NIM is booting was_dst_lpar for the first time. In our case, fb_script needs to create a new Application Server profile using the following command:
/usr/IBM/WebSphere/AppServer/bin/manageprofiles.sh -create -profileName AppSrv01 |
Save this command to a shell script file on nim_lpar. We use /tmp/fb_script to refer to the name of this file throughout this article.
Install WebSphere Application Server
The default installation of Application Server configures the application server with a profile tied to the concrete network settings of the operating system instance where Application Server is installed. Since the network settings of the destination and source LPARs will differ, the default installation cannot be used directly in the process of creating the Application Server appliance. In this section we provide a high-level overview of the Application Server installation and describe the changes that must be made to the Application Server installation in the source environment to prepare for building the appliance.
To start, create a default installation of Application Server (See Resources for the article "Installing your application serving environment" in the WebSphere InfoCenter) and ensure that the installation completed successfully. Application Server relies on a configuration profile to store server configuration information (such as, hostname), so the default profile that was created during the installation should be removed. To check the name of the profile, login as root to was_src_lpar, change to $WAS_HOME/bin (by default Application Server is installed to /usr/IBM/WebSphere/AppServer/) and run:
manageprofiles.sh -listProfiles |
The default profile name in Application Server 7 should be AppSrv01 and we use this name in our examples. Delete the default profile by executing:
manageprofiles.sh -delete -profileName AppSrv01 |
Once the delete operation exits, it is possible to confirm that the profile was deleted by using the listProfiles option again.
While it is possible to use SMIT, command line tools or web-based system management to create the mksysb image, this article focuses on the steps using SMIT:
- Login as root to nim_lpar,
run smitty nim_mkresfastpath and select mksysb as resource type to be defined. - On the next screen provide the required information:
- Resource Name (we'll use was_mksysb_image)
- Server of Resource (master if you would like to store the mksysb file on the LPAR with the NIM server)
- Location of Resource (file path to the was_mksysb_image file on Resource Server, we'll assume /tmp)
- NIM Client to backup (name of server with WAS installed, e.g. was_src_lpar)
- Create system backup image should be set to yes
Create the image and exit SMIT.
- Note that mksysb and SPOT must be at the same level. Check the level using the following commands from the shell:
lsnim -l /tmp/was_mksysb_spot lsnim -l /tmp/was_mksysb_image
Ensure that oslevel_r field in the output of both commands is the same.
It is also possible to create SPOT from an existing mksysb image, which can be useful
if the image was downloaded from an external repository and there is no corresponding
SPOT on the NIM server. While logged in as root to nim_lpar, enter smitty nim_mkres from the shell and select SPOT as the Resource type.
On the next screen, specify the prepared mksysb image as the value of filed Source of
Install Images. For more information about SPOT file preparation see "Creating a
non-/usr SPOT from a NIM lpp_source" example in Resources.
An OVF metadata file can be used to facilitate sharing of the virtual appliances by providing a technology-independent description of the appliance content and the requirements for instantiating the appliance. The OVF standard requires that the OVF file reside in the same directory as the virtual machine image. As shown on lines 3-7, the OVF content starts with a listing of the files used by the appliance. Lines 25-59 specify the operating, network and file system settings of the guest instantiated by the image and identify the quantities of disk space, memory, and processor frequency needed to run the instantiated guest.
|--------10--------20--------30--------40--------50--------60--------70--------80--------|
001:<?xml version=“1.0” encoding=“UTF-8”?>
002:<ovf:Envelope xmlns:ovf=“http://www.vmware.com/schema/ovf/1/envelope”
xmlns:rasd=“http://schemas.dmtf.org/wbem/wscim/1/cim-
schema/2/CIM_ResourceAllocationSettingData”
xmlns:vssd=“http://schemas.dmtf.org/wbem/wscim/1/cim-
schema/2/CIM_VirtualSystemSettingData”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” ovf:version=“0.9”>
003: <References>
004: <File ovf:href=“was_mksysb_image” ovf:id=“img” ovf:size=“4376576000”/>
005: <File ovf:href=“was_mksysb_spot” ovf:id=“spot” ovf:size=“32762”/>
006: <File ovf:href=“fb_script” ovf:id=“fbs” ovf:size=“80”/>
007: </References>
008: <Section xsi:type=“ovf:NetworkSection_Type”>
009: <Info>List of networks</Info>
010: <Network ovf:name=“Network 1”>
011: <Description>The “Network 1” network</Description>
012: </Network>
013: </Section>
014: <Content ovf:id=“Virtual Appliance” xsi:type=“ovf:VirtualSystem_Type”>
015: <Info>A virtual machine</Info>
016: <Section ovf:required=“false” xsi:type=“ovf:AnnotationSection_Type”>
017: <Info>An annotation</Info>
018: <Annotation>AIX 6.1 with WebSphere Application Server 7.
019: </Annotation>
020: </Section>
021: <Section ovf:id=“93” ovf:required=“false”
xsi:type=“ovf:OperatingSystemSection_Type”>
022: <Info>Guest Operating System</Info>
023: <Description>AIX 6.1</Description>
024: </Section>
025: <Section xsi:type=“ovf:VirtualHardwareSection_Type”>
026: <Info>2048 MB Memory, 1000MHZ CPU, 10GB HDD reservation</Info>
027: <System>
028: <vssd:VirtualSystemType>OpenVZ</vssd:VirtualSystemType>
029: </System>
030: <Item>
031: <rasd:Caption>2048 MB Memory reservation</rasd:Caption>
032: <rasd:InstanceId>0</rasd:InstanceId>
033: <rasd:ResourceType>4</rasd:ResourceType>
034: <rasd:AllocationUnits>MB</rasd:AllocationUnits>
035: <rasd:Reservation>2048</rasd:Reservation>
036: </Item>
037: <Item>
038: <rasd:Caption>1000MHZ CPU reservation</rasd:Caption>
039: <rasd:InstanceId>0</rasd:InstanceId>
040: <rasd:ResourceType>3</rasd:ResourceType>
041: <rasd:AllocationUnits>MHz</rasd:AllocationUnits>
042: <rasd:Reservation>1000</rasd:Reservation>
043: </Item>
044: <Item>
045: <rasd:Caption>10GB HDD reservation</rasd:Caption>
046: <rasd:InstanceId>9</rasd:InstanceId>
047: <rasd:ResourceType>20</rasd:ResourceType>
048: <rasd:AllocationUnits>GB</rasd:AllocationUnits>
049: <rasd:Reservation>10</rasd:Reservation>
050: <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
051: </Item>
052: <Item>
053: <rasd:Caption>Ethernet adapter on “Network 1”
</rasd:Caption>
054: <rasd:InstanceId>7</rasd:InstanceId>
055: <rasd:ResourceType>10</rasd:ResourceType>
056: <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
057: <rasd:Connection>Network 1</rasd:Connection>
058: </Item>
059: </Section>
060: <Section xsi:type=“ovf:ProductSection_Type” ovf:required=“false”
ovf:instance=“1” ovf:id=“102”>
061: <Info>WebSphere Application Server 7</Info>
062: <Product ovf:required=“false”>WebSphere Application Server
</Product>
063: <Version ovf:required=“false”>7</Version>
064: </Section>
065: </Content>
066: </ovf:Envelope>
|
Reuse the Application Server virtual appliance
Consider two alternative scenarios for reuse of the Application Server virtual appliance. The first scenario involves sharing of the appliance within the same network. The second scenario incorporates the implications of using the Internet to distribute and share the appliance.
The first scenario is possible if the appliance used to create an LPAR instance at a destination physical server resides in the same network as the source physical server (such as, snode). This scenario is also less involved, since the NIM installation used to create the appliance (installed on nim_lpar on Figure 2) can be used to instantiate the appliance to a destination LPAR (was_dst_lpar on Figure 2).
Figure 2. Scenario for reuse of the Application Server virtual appliance when source and destination LPARs share a local area network(LAN)
Earlier in the article, we described the steps for defining an LPAR as a NIM client.
In this scenario, before the Application Server virtual appliance can be instantiated, follow the
steps from the Prepare the source LPAR environment section to
create a client definition with the destination LPAR host name (in our example,
was_dst_lpar) as the value of the hostname of the machine field. Note that these steps must be
performed from nim_lpar by using smitty nim_mkmac command.
Next, instantiate the destination LPAR from the virtual appliance:
- Login as root to nim_lpar.
- From the AIX shell, start smitty using
smitty nim_bosints. - Select destination LPAR as the target for installation (for instance, was_dst_lpar)
- Select mksysb as the installation type and specify the values for the mksysb image,
SPOT, and fb_script files which in this article are respectively:
- /tmp/was_mksysb_image
- /tmp/was_mksysb_spot
- /tmp/fb_script
- Make sure that the license-related fields are set to yes.
- To monitor the mksysb installation progress use:
lsnim -l was_dst_lpar
Once the destination LPAR is instantiated with the contents of the appliance, you can verify that the process was successful and Application Server is available by using the Installation Verification Tool. See the Resources section.
To support the second scenario based on sending the appliance across the Internet, it is required that a separate NIM server (shown on Figure 3 as nim_lpar on dnode physical server) exists on the same network as the destination LPAR (was_dst_lpar on Figure 3). Follow the steps in the Prepare the source LPAR environment section to create the destination NIM installation.
Figure 3. Scenario for reuse of the virtual appliance when source and destination LPARS are on separate networks connected using the Internet
Once NIM is configured at the destination, the Application Server virtual appliance files must be transferred over the Internet to the nim_lpar. The remaining steps for instantiation of the virtual appliance are identical to the steps from the first scenario.
In the article, we have described an approach for building and instantiating a WebSphere Application Server 7.0 virtual appliance using AIX mksysb and NIM technologies. The appliance can be used to accelerate Application Server deployments by reducing the installation time and automation of the installation steps. The use of a single virtual appliance for all Application Server deployments in an organization also enables reduced Application Server support costs.
Learn
- Learn more about logical partitioning (LPAR).
- Read the following chapters in NIM from A to Z in AIX 5L Redbook:
- Chapter 3.1 “Setting up a basic NIM environment”
- Chapter 3.1.2 "Defining NIM clients", Example 3-40
- Chapter 3.3.2 Basic setup of the NIM master resources, Example 3-33
- Chapter 5.4.7 mksysb installation
- Review WebSphere InfoCenter articles
-
The AIX and UNIX developerWorks
zone provides a wealth of information relating to all aspects of AIX systems
administration and expanding your UNIX skills.
-
New to AIX and UNIX?
Visit the New to AIX and UNIX page to learn more.
-
Browse the technology
bookstore for books on this and other technical topics.
Discuss
-
Check out developerWorks blogs
and get involved in the developerWorks
community.
-
Participate in the AIX and UNIX forums:
- AIX Forum
- AIX Forum for developers
- Cluster Systems Management
- IBM Support Assistant Forum
- Performance Tools Forum
- Virtualization Forum
- More AIX and UNIX Forums
- AIX Networking

Dr. Alexey Miroshkin has published several scientific publications in the area of distributed computing and multimedia search engines. He has solid experience in design and development of distributed systems, Web services, and applications. His current focus is on virtualization and virtual infrastructure management. He is a member of the Innovation Development Team in the IBM laboratory in Moscow.

Carl Osipov is an experienced software architect with the Strategy and Technology organization in IBM Software Group. His skills are in the area of distributed computing, speech application development, and computational natural language understanding. He has published and presented on Service-Oriented Architecture and conversational dialog management to peers in the industry and academia. His current focus is on design of reuse techniques for composite business services.




