Automating deployment and activation of virtual appliances for IBM AIX and Power Systems

Server virtualization enables you to rapidly provision new environments by using libraries of virtual image templates, or virtual appliances. Automated provisioning requires the management of operating system, network, and application-specific customization. This article provides a sample framework for automating virtual image deployment and activation on Power Systems™, with a downloadable example that demonstrates how to provision a virtual appliance made up of IBM® WebSphere® Application Server V7.0 running on AIX® V5.3.

Share:

Yee Ja (yja@us.ibm.com), Software Engineer, IBM

Yee Ja is a software engineer in AIX product development. He is involved in various virtualization efforts within IBM, including AIX virtual appliances, its lifecycle management, and cloud computing initiatives.



Julie Craft (jcraft@us.ibm.com), Architect, IBM

Julie Craft is an architect in AIX product development. Her specific areas of expertise include AIX installation, maintenance, and systems management.



29 April 2009

Introduction

One significant advantage of server virtualization is the ability to rapidly provision new environments by using libraries of virtual image templates or virtual appliances. Automated provisioning requires the management of operating system, network, and application-specific customization. This article provides a sample framework for automating virtual image deployment and activation on Power Systems, including step-by-step instructions and sample code for quickly and easily provisioning a virtual appliance composed of IBM WebSphere Application Server Network Deployment V7.0 running on AIX V5.3 TL8 SP1.

This article delves into the process of creating and deploying a virtual appliance, which is a process that generally requires a broad set of skills, including the ability to install and configure the operating system and any additional software products, plus interact with the hypervisor. In an attempt to simplify the process, this article pares away some tasks and provides step-by-step instruction for others. In general, this article is targeted towards AIX Network Installation Manager (NIM) administrators.

The technique presented should also be equally applicable for virtual appliances for IBM DB2® ESE 9.5 and Virtual I/O Server.


Automatic virtual machine deployment

Installing, configuring, and tuning a system correctly is a time consuming task, as it involves the separate installation, configuration, and tuning of multiple products; in the case of this example, that includes the operating system and WebSphere Application Server. In addition, the process is often more complicated than simply installing these products because it also typically involves:

  • Installing the AIX patch levels required by WebSphere Application Server.
  • Adjusting operating system parameters.
  • Adjusting file systems sizes.
  • Tuning TCP/IP parameters.
  • Creating user accounts.
  • Installing additional required software.

The advent of the virtual appliance is an attempt to solve the administrative complexity involved with creating a new system. Instead of installing, configuring, and tuning the various software products for every new instance of the same server, a system is captured as a virtual appliance and the appliance is installed and configured as a whole whenever a new instance of the server is needed. Since the purpose of the system is well known, the appliance can be pre-configured with optimal settings. As a result, instance-specific customization of the virtual appliance can be limited to a handful of simple paramaters, such as network settings, user passwords, and so on. In fact, many of the settings can be agnostic with respect to the underlying operating system and made common for equivalent appliances that are targeted for different platforms (for example, WebSphere Application Server on AIX vs Windows®).

The virtual appliance model is a virtualization concept that has much appeal. However, even with the virtual appliance created, the task of actually deploying the appliance can be time consuming. Power virtualization can involve interacting with the hypervisor from multiple interfaces:

  • Virtual I/O Server (VIOS)
  • Hardware Management Console (HMC) or Integrated Virtualization Manager (IVM)
  • Network Installation Manager (NIM).

This article is primarily limited to the steps for creating a sample WebSphere Application Server virtual appliance and interactions with NIM, which is sufficient for installing and reconfiguring the virtual appliance onto an existing logical or full-system partition, the high level steps for which are illustrated in Figure 1.

Hopefully limiting interactions with NIM will be sufficient to jumpstart your efforts in this new world of virtualization, as well as illustrate the benefits of using virtual appliances. Some of which are:

  • Quick provisioning of a virtual appliance.
  • The ability to share a system or logical partition as needs arise; for example, use the system as an application server one week, and as a database server the next.

Fully automating all interactions with the hypervisor is ideal, but it can also be more complex. The HMC (or IVM) is responsible for:

  • LPAR management (create/delete, on/off, partition profile).
  • Virtual resource creation and allocation.
  • Physical resource allocation (CPU, memory, disks, devices).

The VIOS is responsible for:

  • Virtual to physical resource mapping.
  • Virtual device configuration.
  • Shared Ethernet Adapter creation.
Figure 1. High level flow
Figure 1. High level flow

Figure 1 illustrates the high level flow for creating a virtual appliance from a system and then using NIM and the target system’s HMC to install the virtual appliance onto that target system. The NIM master is configured as the bootstrap protocol (BOOTP) configuration server for the target system, while the HMC causes the target system to boot up and initiate the BOOTP request.

Following the numbered steps in Figure 1, you would:

  1. Create the virtual image template, which involves:
    • Install AIX.
    • Install WebSphere Application Server.
    • Install activation engine plus plug-ins.
  2. Create a mksysb of the system, which is a backup image of the system created from step 1.
  3. Copy the mksysb to the NIM master.
  4. Configure NIM for deployment.
  5. Initiate a BOOTP of the target system, using either the System Management Services (SMS) console, or lpar_netboot from the HMC.

On completion, the target system should be a newly provisioned instance of the virtual image template. Detailed instructions that correspond to the above steps are presented below. The steps excluded from the above flow are related to building the hosting environment (next), which occurs as a precursor to creating a virtual image template.


Building the hosting environment

The hosting environment for a Power virtual machine is a partition, either a logical or full system partition. Building the hosting environment equates to interacting with the HMC or IVM, and possibly the VIOS, if it exists for the partition. No additional work, such as resource allocation and configuration, is required if the Power server does not support partitioning; in this case, all resources for the server will automatically be allocated to the single partition.

A hosting environment is required for both creating and deploying the virtual image. Therefore, either one or two partitions must be created, depending on whether you decide to use the same partition for both purposes. If you are not proficient with the AIX or WebSphere Application Server installation process, it might be easier for you to have two separate partitions because you might need to go through several iterations of modifying the virtual image template system and capturing the image. Installation to a partition is destructive to that partition. Using a single partition for both purposes -- creation of the virtual appliance as well as its deployment -- carries the risk of inadvertently creating an image that will not install and cause you to restart the whole virtual appliance creation process again. (Describing the steps for building the hosting environment is beyond the scope of this article. See Resources for more information.)


Creating a virtual image template

The major steps to create a virtual image template include:

  1. Build the image
  2. Capture the image
  3. Deploy the image
  4. Configure NIM
  5. Initiate BOOTP

These steps are described in detail in the next sections.

1. Build the image

The virtual image template (which will be the deployable image) is a new installation that requires you to install this software on the hosting system:

  • AIX V5.3 TL8 SP1
  • WebSphere Appication Server Network Deployment V7.0
  • Activation engine, plus the AIX and WebSphere Application Server Network Deployment activation engine plug-ins.

The activation engine is software embedded in the virtual appliance that is activated during the first boot of the appliance following deployment. The activation engine and customization plug-ins can be written and provided to configure the virtual appliance to the target system. The purpose of the activation engine and plug-in code is to make the instance of the virtual appliance usable within the new environment; for example, the new system should be configured for the new network settings.

An activation engine is passed customization metadata in Extensible Markup Language (XML) format. The XML schema utilized can be user defined or it can conform to that utilized by the Open Virtualization Format (OVF) environment file, which is an open standard for defining virtual appliances. Essentially, the file specifies keyword and value pairs that the activation engine and its plug-ins know how to parse and consume. For the purpose of this article, you can either create your own activation engine or use the sample provided.

In addition to installing the software products and the files related to the activation engine, other system customization and tuning should be performed at this time; for example, set the paging space size. File systems might also need to be sized appropriately; for example, you might need to increase available freespace. The installation program for WebSphere Application Server (and other WebSphere products) will indicate which file systems will need to be larger to accommodate the product; however, these space requirements usually reflect the minimal amounts. Also, if many users are expected to login to use the system, then additional /home space might be desired.

To build the image:

  1. Obtain AIX and perform a typical installation. When complete, create a new user ID virtuser:staff by invoking this command:

    mkuser –a groups=staff virtuser

    Set the password to "password" with this command:

    echo "virtuser:password" | chpasswd -c

    This new ID will be used for the administrator user ID for the WebSphere Application Server installation, next.

  2. Install WebSphere Application Server Network Deployment V7.0 (hereafter referred to as Network Deployment) according to the installation documentation; however, the install directory and owning user ID and group must match those specified here if you plan to run the sample code, as the sample activation engine and customization plug-in for WebSphere Application Server was written with those values encoded.

    Network Deployment can be installed on AIX Version 5.3 Technology Level (TL) 8 and Service Pack (SP) 1. To perform the install:

    1. Log onto the system being installed as virtuser. The target installation location is the /opt/IBM/WebSphere/AppServer directory. As a precursor to this step, since the target directory is a directory normally owned by root, you must explicitly alter the owner of the installation location for the installation to succeed. Run these commands as root to perform this operation:
      # mkdir /opt/IBM/WebSphere
      # chown virtuser:staff /opt/IBM/WebSphere
    2. To perform a silent install, create an installation response file with the options below specified. The installation response file is used in the next step as an option to the WebSphere Application Server install command:
      -OPT noValidation="true"
      -OPT silentInstallLicenseAcceptance="true"
      -OPT allowNonRootSilentInstall="true"
      -OPT disableOSPrereqChecking="true"
      -OPT disableNonBlockingPrereqChecking="true"
      -OPT installType="installNew"
      -OPT profileType="none"
      -OPT feature="noFeature"
      -OPT PROF_enableAdminSecurity="false"
      -OPT installLocation="/opt/IBM/WebSphere/AppServer"
    3. Run the WebSphere Application Server install command as virtuser (using product media or from the expanded install archive):

      /tmp/was7/install -options "/tmp/was7/responsefile.nd.txt" –silent

      Since you are performing the installation as virtuser, installation files must be readable or owned by virtuser if the install files are located on the local file system. Also, run the install command using a fully qualified path for the response file. In the example, the response file was created as /tmp/was7/responsefile.nd.txt. Since you are performing a silent install, you can check the ~virtuser/waslogs directory for the active log file:

      # tail -f ~virtuser/waslogs/log.txt

      The log.txt file will be renamed after the install command completes, whether it is successful or not. Usually, the installation will fail, indicating, for example, that certain file systems need to be expanded, so it is quite normal to enter into a repetitive cycle of issuing the install command, viewing the log, and making the necessary adjustments to the system, until the install completes successfully.

    4. Install the zip file utility for AIX, which is used by the WebSphere Application Server install program. Download the RPM Package Manager (rpm) software package and install (as root) using:

      # rpm –install ZipRPMPathName

    5. Create WebSphere Application Server profiles. The activation engine plug-in provided in the sample code expects these profiles to exist within the virtual appliance.
  3. Install the sample activation engine provided with the sample code included with this article, along with a plug-in that is appropriate for reactivating the WebSphere Application Server on AIX installation created above. The activation engine should be installed in the /opt/IBM/AE directory of the system by the root user. The sample activation engine is installed by running the commands below. The first creates the installation directory and the second extracts the included archive file, which contains the sample activation engine:
    cd /opt/IBM/AE
    tar –xvf AE.tar

    Invoke this command to complete the installation process:

    sh /opt/IBM/AE/ae -a /opt/IBM/AE/AL/wasv7.al

    This command creates /etc/rc.d scripts that will be run during init processing for runlevel 2 (normal boot up), based on the runlevels specified in the /opt/IBM/AE/AL/wasv7.al file. This file specifies configuration options for the sample activation engine; for example, which activation engine plug-in scripts should be run during reconfiguration of the virtual appliance. The activation engine is run during system initialization time. The runlevel corresponds to the state of the system for which the initialization is occurring. Run level 2 is the default system startup state for normal boot up of AIX.

    The activation engine registers the activation engine plug-ins, which automatically run during boot time to reconfigure or customize the provisioned instance of the virtual image template. Reconfiguration metadata is made available to the activation engine plug-ins within the virtual image template when a new instance of the image is provisioned. The metadata is in the XML format shown in Listing 1, where the virtual-image, software-resource, and configuration element names and the name attribute corresponds to the equivalent XML structure in the /opt/IBM/AE/AL/wasv7.al file (Listing 2).

    Listing 1
    <?xml version="1.0" encoding="UTF-8"?>
    <virtual-image name="WASv7">
      <software-resource name="AIX_V_5_3">
        <configuration name="ConfigLicense">
          <parameter name="accept" value="yes" />
        </configuration>
        <configuration name="ConfigPWD_ROOT">
          <parameter name="username" value="root" />
          <parameter name="password" value="password" />
        </configuration>
        <configuration name="ConfigPWD_USER">
          <parameter name="username" value="virtuser" />
          <parameter name="password" value="password" />
        </configuration>
      </software-resource>
      <software-resource name="WAS_7">
        <configuration name="ConfigWAS">
          <parameter name="type" value="default" />
          <parameter name="password" value="password" />
          <parameter name="autostart" value="true" />
        </configuration>
      </software-resource>
    </virtual-image>
    Listing 2
    <virtual-image name="WASv7">
      <software-resource name="AIX_V_5_3">
        <configuration name="ConfigLicense">
          <script file="AS/ConfigLicense" />
          <service name="activation.ConfigLicense">
            <runlevel value="2" />
          </service>
        </configuration>
        <configuration name="ConfigPWD_ROOT">
          <script file="AS/ConfigPWD" />
          <service name="activation.ConfigPWD_ROOT">
            <runlevel value="2" />
          </service>
        </configuration>
        <configuration name="ConfigPWD_USER">
          <script file="AS/ConfigPWD2" />
          <service name="activation.ConfigPWD_USER">
            <runlevel value="2" />
          </service>
        </configuration>
      </software-resource>
      <software-resource name="WAS_7">
        <configuration name="ConfigWAS">
          <script file="AS/ConfigWAS" />
          <service name="activation.ConfigWAS">
            <runlevel value="2" />
          </service>
        </configuration>
      </software-resource>
    </virtual-image>

    The parameter names and values for each configuration in the metadata is passed to the script file specified in the respective configuration of the /opt/IBM/AE/AL/wasv7.al file during rc.d processing; in this case, boot time.

    As you can see, new plug-ins for the activation engine can be easily added if further reconfiguration is needed; for example, for user created applications.

  4. Make sure that enough free space is available in the file system where the activation engine metadata will be written; in this example, the /opt/IBM/AE/AP directory. The amount of space is dependent on the size of the metadata file. In this example, the size of the metadata file is less than 4 KB, so free space will probably not be an issue unless the file system is already full.

2. Capture the image

You will capture the virtual appliance as a mksysb image. A mksysb image file is a backup of the root volume group. This image file constitutes the virtual appliance in this example, which you will later try to deploy. As part of the mksysb command, you can create a /etc/exclude.rootvg file using the grep regexp format to exclude files from being captured in the mksysb image. Since you are providing a virtual appliance intended to be installed multiple times, it might be desirable to scrub the image of some files. Display the content of the /etc/exclude.rootvg file used in the example with this command:

cat /etc/exclude.rootvg

and you will see:

^./tmp/
^./mksysb_images/
^./etc/hosts
^./etc/resolv.conf
^./etc/fb_[0-9_]*
^./etc/exclude.rootvg
^./.sh_history
^./.vi_history
^./.rhosts
^./smit

To ensure that the mksysb file size will not exceed the file size limit set in your environment, issue this command from the shell prompt:

ulimit -f unlimited

Capture the mksysb image using the –i option to generate the /image.data file. This file is needed to save the existing logical volume and file system sizes which will be used when restoring the mksysb:

mksysb -e -i /mksysb_images/aix_5381_was_7_mksysb

The mksysb image can be restored to a different system using the NIM bos_int operation, the function of which is to enable the NIM server as a BOOTP server for the system to be installed. A modified image.data file can be supplied to the NIM mksysb bos_inst operation as an image_data resource to dynamically resize logical volumes. This makes it possible to resize file systems and even paging space.

The ability to use a single AIX mksysb image for various disk sizes -- and to possibly change the paging size -- enables each image to be used for different system capacities and configurations.

3. Deploy the image

After creating and capturing the mksysb image, copy the file from the captured system to the NIM master. You can use a File Transfer Protocol (FTP) utility or an alternative method. For FTP, begin by logging into the NIM master system as root. Again, you will need to make sure that the file size will not be limited by the current environment settings. Change to the directory in which you want to place the mksysb image file; in the example, the /export/nim/mksysb directory is used. Use the FTP command to copy the file from the captured system to the NIM master. From the shell prompt, issue:

ulimit -f unlimited
cd /export/nim/mksysb

ftp CapturedSystemHostname
cd /mksysb_images
get aix_5381_was_7_mksysb
quit

The mksysb is now almost ready to be deployed. Deployment consists primarily of the NIM configuration and using the SMS console or the target system’s HMC to boot the system using BOOTP (the bootstrap protocol).

4. Configure NIM

NIM configuration could be a complex endeavor if you are not familiar with the objects that need to be defined to the NIM master. The various objects utilized are:

  • mksysb
  • spot
  • standalone machine
  • fb_script or script
  • bos_int

and optionally:

  • bosinst_data
  • image_data
  • resolv_conf

Some of these objects are likely obvious; for example, the mksysb image (your installation image) and the standalone machine (which identifies the system to which you will install the image). Essentially, all the objects are passed to the bos_inst object, which transforms the NIM master into the BOOTP server for the target install system. The other objects either specify additional configuration and installation parameters to NIM or they provide additional installation time resources to the system being installed via the Network File System (NFS) protocol:

  • A SPOT object identifies the Shared Product Object Tree (SPOT), which defines the boot image provided by the NIM master in its role as the BOOTP server for the system being installed. The SPOT is subsequently used during the install process as it provides the equivalent of the /usr file system (that is, standard AIX operating system functionality) to the installing system.
  • The fb_script and script objects provide a mechanism for deploy time command invocation. In other words, the bos_inst operation has pre-defined exit points in the installation process that enable user commands to be invoked.
  • The bosinst_data object is used to pass installation specific options to the bos_inst object.
  • The image_data object points to an image.data file, which contains the logical volume and file system definitions for the root volume group.
  • The resolv_conf object points to a resolv.conf file that should be installed onto the system. This file contain additional network information, such as domain and nameserver listing.

As you can see, the process is highly configurable which has many benefits. For example, you can resize the paging space with a script resource or by supplying an image.data file for the installation. However, because there are so many options available, the task of defining and managing all these objects can be daunting.

On top of that, NIM has the ability to manage resources on additional servers. These servers are termed NIM resource servers. For simplicity in this example, you will have a single NIM server; a NIM master with no NIM resource servers. (If you had been wondering why the VIOS and HMC were excluded from this article on virtual appliances for Power Systems, hopefully you can now understand -- if not appreciate -- this decision.)

Next are the enumerated steps for configuring the NIM master as a BOOTP server for the target system:

  1. To define a NIM mksysb object, issue this command:
    nim -o define -t mksysb \
       -a location=MksysbPathName \
        MksysbName

    For this example, you could issue:

    nim -o define -t mksysb \
       -a location=/export/nim/mksysb/aix_5381_was_7_mksysb \
       aix_5381_was_7_mksysb

    where /export/nim/mksysb/aix_5381_was_7_mksysb is where you copied the mksysb file onto the NIM master. For simplicity, the mksysb filename is used here as the NIM mksysb object name; they do not need to be the same, however.

  2. For deployment of a mksysb, you will need to define a NIM SPOT object. You should be able to utilize a SPOT whose oslevel_r value matches that of the mksysb. The oslevel_r value corresponds to the operating system revision level, which is analogous to the output of the oslevel –r command issued on a running AIX system. All mksysb and SPOT resources have this value. Because of the NIM installation requirement for the mksysb and the SPOT to have matching oslevel_r values, it might be safer to create an extracted SPOT from the mksysb. An extracted SPOT is just a SPOT created from the contents of a mksysb. This is easily done by issuing this command:
    nim -o define -t spot \
       -a source=MksysbName \
       -a location=SpotParentDir \
       -a auto_expand=yes \
       SpotName

    For this example, you could issue:

    nim -o define -t spot \
       -a source= aix_5381_was_7_mksysb
       -a location=/export/nim/spot \
       -a auto_expand=yes \
       aix_5381_was_7_spot
  3. To define the target system to NIM, the following command is all that is needed if the network for the target system is already defined or common with the NIM master:

    nim -o define –t standalone \
    		-a if1=”find_net HostName MacAddr” \
    		MachineName

    The HostName is preferably the fully qualified hostname (including domain name) of the system. The MAC address, MacAddr, is only required if there exists more than one network card for the target system. The addition of the MAC address helps NIM distinguish between the multiple network adapters on those systems. The MAC address provides additional granularity for the NIM master to respond to BOOTP requests from client systems’ network adapters.

    If the NIM network is not already defined for the target system, then issue this command to define a network for the target system:

    nim -o define -t NetworkType \	
    -a Attribute=Value ... MachineName

    For this example, you could issue:

    nim -o define –t standalone \
    		-a if1=”find_net herb.austin.ibm.com” \
    		-a cable_type1=N/A \
    		-a netboot_kernel=mp \
    		-a net_definition=”ent 255.255.255.0” \
    		-a connect=shell \
    		-a net_settings1=”100 full” \
    		herb

    The above command will actually serve both purposes: find the NIM network for the system, or define one (with the specified attributes) if one can not be found.

    The net_settings1 value specifies the network speed and duplex settings. The net_definition specifies the network type and subnet mask. The MAC address is not specified (for the if1 attribute) since you only have a single network adapter for your system. Also, for simplicity, the short hostname (hostname -s) for the NIM object name is used -- in this case, herb.

  4. As mentioned earlier, the fb_script and script resource objects specify commands that can be run at predefined exit points in the install process. The commands specified by the script resources are invoked after the mksysb has been copied and restored on the target system, but before the system reboots. The commands specified by the fb_script resources are invoked during this initial reboot of the newly installed system.

    Specifically, commands of an fb_script resource are processed during firstboot processing in the init process, which should also occur prior to rc.d processing. The order of these actions can be verified by examining the /etc/inittab file of the captured system from which the mksysb was created. (See the System p® Information Center for details.)

    Customization information or metadata will be supplied to the activation engine and plug-ins via a NIM script or fb_script resource. Both exit points are prior to the invocation of the activation engine, so both are suitable as a file delivery mechanism. The drawback of using a fb_script resource is that the file systems for the /etc directory must also satisfy the same free space requirement specified in Step 1d.

    The NIM fb_script/script file resource and the activation engine are written such that the script delivers the activation engine metadata to a known or expected location prior to the activation engine accessing that data. In this case, the known location is the /opt/IBM/AE/AP directory.

    The fb_script/script content for metadata delivery is essentially a here-document specified as a Korn shell input redirection command. This basically means that you can specify a command as input to that command, all as a single command.

    For this example, create a /export/nim/script/create_metadata.sh file containing the code in Listing 3.

    Listing 3
    cat > /opt/IBM/AE/AP/was.ap << ‘EMBED_FILE_END’
    <?xml version="1.0" encoding="UTF-8"?>
    <virtual-image name="WASv7">
      <software-resource name="AIX_V_5_3">
        <configuration name="ConfigLicense">
          <parameter name="accept" value="yes" />
        </configuration>
        <configuration name="ConfigPWD_ROOT">
          <parameter name="username" value="root" />
          <parameter name="password" value="password" />
        </configuration>
        <configuration name="ConfigPWD_USER">
          <parameter name="username" value="virtuser" />
          <parameter name="password" value="password" />
        </configuration>
      </software-resource>
      <software-resource name="WAS_7">
        <configuration name="ConfigWAS">
          <parameter name="type" value="default" />
          <parameter name="password" value="password" />
          <parameter name="autostart" value="true" />
        </configuration>
      </software-resource>
    </virtual-image>
    EMBED_FILE_END

    Change the password parameter values to your own desired values. (For simplicity, all passwords in the example are set to "password.") The execution of the script will create the /opt/IBM/AE/AP/was.ap file on the target system. The contents of the file are the lines between the first line and last lines, delimited by "EMBED_FILE_END."

    Define the script to NIM as either an fb_script or script resource using:

    nim -o define -t ScriptType \
       -a location=/export/nim/ScriptType/ScriptName \
       ScriptName

    For this example:

    nim -o define -t script \
       -a location=/export/nim/script/create_metadata.sh \
       create_metadata

    For simplicity, the NIM script resource was named using the file name of the script, minus the file extension.

  5. (Optional step) The NIM bosinst_data resource is optional depending on the method used to invoke the BOOTP for the target system and whether there are any additional installation parameters that must be set for the subsequent bos_inst operation (Step 4i). If an lpar_netboot is being performed (by the HMC or IVM), then a non-prompted installation is required. This is indicated by PROMPT = no in the control_flow stanza of the bosinst.data file.

    The need to install on different systems will also necessitate the use of a bosinst_data resource. By default, the bos_inst operation will use the disk information from the captured system for the target system. In other words, NIM will normally limit the viability of an installation to a disk that differs in size from the original mksysb captured disk. So, unless the captured and target systems are the same, the bos_inst could likely fail unless you reset the values of the target_disk_data stanza in the bosinst.data file, as shown below.

    For the purpose of this example, create a /export/nim/bosinst_data/nonprompted_bosinst_data file containing:

    • control_flow:
      CONSOLE = Default
          INSTALL_METHOD = overwrite
          PROMPT = no
          EXISTING_SYSTEM_OVERWRITE = yes
          INSTALL_X_IF_ADAPTER = yes
          RUN_STARTUP = no
          RM_INST_ROOTS = no
          ERROR_EXIT =
          CUSTOMIZATION_FILE =
          TCB = no
          INSTALL_TYPE =
          BUNDLES =
          RECOVER_DEVICES = no
          BOSINST_DEBUG = no
          ACCEPT_LICENSES = yes
          DESKTOP = NONE
          INSTALL_DEVICES_AND_UPDATES = yes
          IMPORT_USER_VGS =
          ENABLE_64BIT_KERNEL = Default
          CREATE_JFS2_FS = Default
          ALL_DEVICES_KERNELS = yes
          GRAPHICS_BUNDLE = yes
          MOZILLA_BUNDLE = no
          KERBEROS_5_BUNDLE = no
          SERVER_BUNDLE = no
          REMOVE_JAVA_118 = no
          HARDWARE_DUMP = yes
          ADD_CDE = no
          ADD_GNOME = no
          ADD_KDE = no
          ERASE_ITERATIONS = 0
          ERASE_PATTERNS =
    • target_disk_data:
      LOCATION =
          SIZE_MB = largest
          HDISKNAME =
    • locale:
      BOSINST_LANG =
          CULTURAL_CONVENTION =
          MESSAGES =
          KEYBOARD =

    To verifiy the contents of the newly created bosinst.data file, run this command:

    /usr/lpp/bosinst/bicheck /export/nim/bosinst_data/nonprompted_bosinst_data

    Invoke:

    nim -o define -t bosinst_data \
       -a location=BosinstDataPathName \
       BosinstDataName

    For this example:

    nim -o define -t bosinst_data \
       -a location=/export/nim/bosinst_data/nonprompted_bosinst_data \
       nonprompted_bosinst_data

    Again, the NIM bosinst_data resource is given the same name as the actual file name for simplicity.

  6. (Optional step) An image.data file describes how physical disks and file systems should be configured in the root volume group during installation. By default, the /image.data file within the mksysb will be used unless an alternative is defined to NIM and supplied to the bos_inst operation (Step 4i).

    If the sum of the logical volume sizes in the root volume group of the system from which the mksysb was captured is small enough such that the mksysb image is deployable to all desired disk sizes of potential target systems, then a NIM image_data resource is optional. If this is not the case, then a NIM image_data resource can be created to facilitate dynamic resizing of the file systems to scale down the available free space. The /image.data file within the mksysb image should be used as the basis of an image_data resource supplied to the bostinst operation.

    On the NIM master, the image.data file created as part of the mksysb capture (Step 2) can be extracted using the restore command:

    restore -xvqf MksysbPathName ./image.data

    The extracted image.data file should contain this stanza:

    logical_volume_policy:
            SHRINK= no
            EXACT_FIT= no

    The values for these parameters are correct for the purpose of this example. The SHRINK=yes parameter is not a desirable option for provisioning the mksysb (the virtual image template) since that option would install the image with just enough space on each file system to accommodate the existing files in the image. If file system freespace is limited, there is no guarantee that a NIM fb_script resource will be successfully copied to the /etc file system during the bos_inst operation, or that the /opt/IBM/AE/AP/was.ap metadata file will be created by the NIM fb_script or script resource.

    Move the image.data file to an appropriate location. For this example:

    mv image.data /export/nim/image_data/ image_data_1

    This image.data file can then be modified and defined to NIM as an image_data resource (see the System p Information Center for more):

    nim -o define -t image_data \
       -a location=ImageDataPathName \
       ImageDataName

    For this example:

    nim -o define -t image_data \
       -a location=/export/nim/image_data/image_data_1 \
       image_data_1
  7. (Optional step) A resolv.conf file can be defined for the bos_inst operation such that a specified /etc/resolv.conf file will be installed on the newly provisioned system for the bos_inst operation (Step 4i). As mentioned earlier, the resolv.conf file is used to provide the domain name and nameservers to the target system. The /etc/resolv.conf file on the NIM master can be copied and modified for use by the target system. Here is an example of the contents of a resolv.conf file:
    nameserver      9.0.7.1
    domain  austin.ibm.com

    To define the NIM resolv_conf object, issue this command:

    nim -o define -t resolv_conf \
       -a location=ResolvConfPathName \
       ResolvConfName

    For this example:

    nim -o define -t resolv_conf \
       -a location=/export/nim/resolv_conf/resolv_conf_1 \
       resolv_conf_1

    Again, for simplicity, the NIM resolv_conf resource has the same name as the actual file name.

  8. (Optional step) A boot image is provided by the NIM master to the target system in response to the BOOTP request. If the if_prebuild attribute for the NIM master was set to "no" when the SPOT was created, then provisioning the same mksysb to additional LPARs might necessitate the creation of additional network boot images. When a BOOTP request is initiated, NIM will respond with a matching boot image based on the platform, kernel, and network types for the NIM definition of the target system. If a matching boot image cannot be found, the BOOTP request will fail. Therefore, to rebuild the list of machine types and networks that must be supported by network boot images, issue this command:

    nim -o change -a if_discover=yes master

    To rebuild the network boot images from the spot, issue this command:

    nim -Fo check SpotName

    The above steps are unnecessary if all required boot images (for current and all future bos_inst of the same mksysb image) were created when the SPOT was defined or extracted.

  9. This is the final NIM configuration step and it utilizes all the previously create NIM objects. A NIM bosint operation is invoked by specifying:
    nim -o bos_inst \
       -a source=mksysb \
       -a accept_licenses=yes \
       -a mksysb=MksysbName \
       -a spot=SpotName \	
       -a bosinst_data=BosinstDataName \
       -a script=ScriptName \
       -a resolv_conf=ResolvConfName \
       -a image_data=ImageDataName \
       -a boot_client=no \
       StandaloneMachineName

    For this example, the following values were used to set the command that follows:

    • MksysbName: aix_5381_was_7_mksysb
    • SpotName: aix_5381_was_7_spot
    • BosinstDataName: nonprompted_bosinst_data
    • ScriptName: create_metadata
    • ResolvConfName: resolv_conf_1
    • ImageDataName: image_data_1
    • StandaloneMachineName: herb
    nim -o bos_inst \
       -a source=mksysb \
       -a accept_licenses=yes \
       -a mksysb=aix_5381_was_7_mksysb \
       -a spot=aix_5381_was_7_spot \
       -a bosinst_data=nonprompted_bosinst_data \
       -a script=create_metadata \
       -a resolv_conf=resolv_conf_1 \
       -a image_data=image_data_1 \
       -a boot_client=no \
       herb

    The bos_inst operation will result in the NIM master being enabled to be a BOOTP server for the LPAR. The next step is to have the target system make a BOOTP request to the NIM master.

    Figure 2. NIM enabled as BOOTP server
    Figure 2. NIM enabled as BOOTP server

5. Initiate BOOTP

If an HMC or IVM is available, then an lpar_netboot can be performed. The lpar_netboot command is run from the HMC or IVM, and triggers the specified partition to make a BOOTP request to the NIM master.

If an HMC or IVM is unavailable, a BOOTP can be initiated from the SMS console of the target machine. A system’s SMS console provides various configuration and startup options, one of which is the ability to boot from a network device. Whichever method is used, you are causing the same action. The target system makes a BOOTP request to the NIM master that you earlier configured to be the corresponding BOOTP server for that system.

From the HMC, you need to set the boot mode of the LPAR to normal:

chsyscfg -r prof -m CecName \	
-i "name=LparProfileName,lpar_name=LparName,boot_mode=norm"

then:

lpar_netboot -x -v -i -f -D -t NetworkType \
-s NetSettingsSpeed -d NetSettingsDuplex \
-S NimMasterIpAddr -G Gateway \
-C IpAddr –K SubnetMask \	
"LparName" "LparProfileName" "CecName"

Older versions of the HMC might not support the -K option; for example, pre-HMC V7.3.2.0. From the HMC, you can identify the version by running this command:

lshmc -V -F base_version

As an alternative, also from the HMC, you can query the lpar_netboot command directly:

lpar_netboot --help | grep 'Subnetmask IP address' | grep -- -K

Either command should give you an indication as to whether the –K option should be specified for the lpar_netboot command.

Equivalent commands are available for IVM if an HMC is unavailable to perform an lpar_netboot operation. In addition, Flexible Service Processors (FSPs) and blade management modules should also have similar functionality.


Activating the system

AIX is automatically activated by a successful NIM bos_inst operation and corresponding lpar_netboot from the HMC or IVM.

Once the bos_inst operation completes and the virtual machine has been installed with an instance of the virtual image template, the system should be available for use. If the WAS_7 autostart parameter within the /opt/IBM/AE/AP/was.ap customization parameters or metadata file is set to "false," then WebSphere Application Server will need to be started.

From the newly installed virtual machine, log in with user ID virtuser and its respective password. From a command prompt, run:

/opt/IBM/WebSphere/AppServer/bin/startServer.sh server1 \
-profileName DefaultAppSrv01

or:

/opt/IBM/WebSphere/Profiles/DefaultAppSrv01/bin/startServer.sh server1

From a Web browser, you can launch the administrative console:

http://ipv4-073.austin.ibm.com:9060/ibm/console

and also log in with user ID virtuser and the proper password.


Summary

Server virtualization is not a new concept, especially on Power Systems. In addition, the capture and restoration of mksysb images is a well established process for utilizing AIX-based virtual image templates. However, outside of the basic AIX system and network reconfiguration (which NIM manages during a mksysb bos_inst operation), additional steps are required if you want to use a mksysb image as a virtual image template for more complex systems or deployments.

Using a system with IBM WebSphere Application Server Network Deployment V7.0 running on AIX 5.3 TL8 SP1 as an example, this article described a method for utilizing mksysb images as virtual image templates. This included:

  • The steps required for creating a virtual image template.
  • The steps for deploying that virtual image template and the activation of its various components.

For the latter, you made use of existing NIM APIs to perform the various tasks required for deploying and activating a mksysb virtual image template. The article also touched briefly on various issues regarding the use of mksysb images as a virtual image template; for example, dynamic resizing of logical volumes, security concerns, and so on.

Creating and using virtual image templates or virtual appliances is not for everyone. For some organizations, though, their usage can greatly simplify the process of provisioning systems and increase utilization of existing resources.

Hopefully, the steps and sample code presented here will illustrate how rapid provisioning can be accomplished on Power Systems and help you jumpstart your efforts in this endeavor.


Appendix

The sections that follow provide supplemental information to help you perform the activities described in this article:

  1. Downloading the sample
  2. Product levels
  3. "Just enough" AIX
  4. Create profile commands
  5. Security concerns
  6. Sample activation engine and plug-ins
  7. Sample NIM management script

A. Downloading the sample

The nimae.tar file should be downloaded to the NIM master. Move the file into a desired install directory. Any directory should suffice; an example of such would be /usr/ibm/systemp/nimae. From that directory, issue the following command to extract the archive.

tar –xvf nimae.tar

The AE.tar file referenced in Step 2c is created from a directory of the extracted nimae.tar file when you issue this command:

tar –cvf AE/* AE.tar

B. Product levels

AIX V5.3 TL8 SP1 and IBM WebSphere Application Server Network Deployment V7.0, which are used in this article, have been tested to produce working, deployable virtual appliances and are known to be compatible. In addition, working, deployable virtual appliances have also been created using AIX V6.1 TL1 SP1 and IBM DB2 ESE V9.5. ITM Agent V6.2 can also be packaged in combination with these products.

C. "Just enough" AIX

Systems based on the full AIX install are prevalent, but with the advent of the virtual appliance concept, it is usually more desirable to only provide "just enough operating system" (commonly termed JeOS) such that the maintenance and footprint of the image are reduced. Only the installed components need to be upgraded and, for example, only those daemons which are required need to be installed, resulting in less disk size as well as reduced memory requirement due to the daemon not running.

There is no advocated method of creating a “just enough” AIX system other than selectively installing desired bundles. Also, since there usually does not exist product prerequisite checking at the AIX bundle/fileset level, it is necessary that you have thorough knowledge of the product dependencies on AIX. What needs to be installed is dependent on the final usage of the system. For example, the AIX Java™ bundles are unnecessary in this scenario, as WebSphere Application Server installs and utilizes its own Java Runtime Environment (JRE).

D. Create profile commands

The activation engine customization plug-in for WebSphere Application Server is matched to a WebSphere Application Server virtual appliance with the profiles below defined. The commands shown here are issued to create the various WebSphere Application Server profiles. Run each from the /opt/IBM/WebSphere/AppServer/bin directory, except for reset profile creation, which is to be performed last.

Listing 5. Admin Agent profile
# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh \
-create \
-profileName DefaultAdminAgent01 \
-profilePath /opt/IBM/WebSphere/Profiles/DefaultAdminAgent01 \
-templatePath ../profileTemplates/management/ \
-serverType ADMIN_AGENT \
-nodeName DefaultAdminAgentNode01 \
-cellName DefaultAdminAgentCell01 \
-adminUserName virtuser \
-adminPassword password \
-enableAdminSecurity true \
-defaultPorts \
-webServerCheck true \
-webServerType IHS \
-webServerOS aix \
-webServerInstallPath /opt/IBM/HTTPServer \
-webServerPluginPath /opt/IBM/HTTPServer/Plugins
Listing 6. Cell profiles
# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh \
-create \
-profileName DefaultCellDmgr01 \
-profilePath /opt/IBM/WebSphere/Profiles/DefaultCellDmgr01 \
-templatePath ../profileTemplates/cell/dmgr \
-nodeName DefaultCellDmgrNode01 \
-cellName DefaultCellDmgrCell01 \
-adminUserName virtuser \
-adminPassword password \
-enableAdminSecurity true \
-defaultPorts -nodeDefaultPorts \
-nodeProfilePath \
/opt/IBM/WebSphere/Profiles/DefaultCellAppSrv01 \
-appServerNodeName DefaultCellAppSrvNode01 \
-samplesPassword password \
-omitAction samplesInstallAndConfig

# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh \
-create \
-profileName DefaultCellAppSrv01 \
-profilePath /opt/IBM/WebSphere/Profiles/DefaultCellAppSrv01 \
-templatePath ../profileTemplates/cell/default \
-nodeName DefaultCellDmgrNode01 \
-cellName DefaultCellDmgrCell01 \
-adminUserName virtuser \
-adminPassword password \
-enableAdminSecurity true \
-defaultPorts \
-nodeDefaultPorts \
-dmgrProfilePath \
/opt/IBM/WebSphere/Profiles/DefaultCellDmgr01 \
-appServerNodeName DefaultCellAppSrvNode01 \
-webServerCheck true \
-webServerType IHS \
-webServerOS aix \
-webServerInstallPath /opt/IBM/HTTPServer \
-webServerPluginPath /opt/IBM/HTTPServer/Plugins
Listing 7. Custom profile
# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh \
-create \
-profileName DefaultCustom01 \
-profilePath /opt/IBM/WebSphere/Profiles/DefaultCustom01 \
-templatePath ../profileTemplates/managed/ \
-nodeName DefaultCustomNode01 \
-cellName DefaultCustomCell01 \
-adminUserName virtuser \
-adminPassword password \
-enableAdminSecurity true \
-defaultPorts -webServerCheck true \
-webServerType IHS \
-webServerOS aix \
-webServerInstallPath /opt/IBM/HTTPServer \
-webServerPluginPath /opt/IBM/HTTPServer/Plugins
Listing 8. Default profiles
# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh \
-create \
-profileName DefaultAppSrv01 \
-profilePath /opt/IBM/WebSphere/Profiles/DefaultAppSrv01 \
-templatePath ../profileTemplates/default/ \
-nodeName DefaultAppSrvNode01 \
-cellName DefaultAppSrvCell01 \
-adminUserName virtuser \
-adminPassword password \
-enableAdminSecurity true \
-defaultPorts \
-samplesPassword password \
-webServerCheck true \
-webServerType IHS \
-webServerOS aix \
-webServerInstallPath /opt/IBM/HTTPServer \
-webServerPluginPath /opt/IBM/HTTPServer/Plugins

# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh \
-create \
-profileName DefaultAppSrvAA01 \
-profilePath /opt/IBM/WebSphere/Profiles/DefaultAppSrvAA01 \
-templatePath ../profileTemplates/default/ \
-nodeName DefaultAppSrvNodeAA01 \
-cellName DefaultAppSrvCellAA01 \
-adminUserName virtuser \
-adminPassword password \
-enableAdminSecurity true \
-omitAction samplesInstallAndConfig deployAdminConsole \
-webServerCheck true \
-webServerType IHS \
-webServerOS aix \
-webServerInstallPath /opt/IBM/HTTPServer \
-webServerPluginPath /opt/IBM/HTTPServer/Plugins \
-omitAction samplesInstallAndConfig

# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh \
-create \
-profileName DefaultAppSrvAA02 \
-profilePath /opt/IBM/WebSphere/Profiles/DefaultAppSrvAA02 \
-templatePath ../profileTemplates/default/ \
-nodeName DefaultAppSrvNodeAA02 \
-cellName DefaultAppSrvCellAA02 \
-adminUserName virtuser \
-adminPassword password \
-enableAdminSecurity true \
-omitAction samplesInstallAndConfig deployAdminConsole \
-webServerCheck true \
-webServerType IHS \
-webServerOS aix \
-webServerInstallPath /opt/IBM/HTTPServer \
-webServerPluginPath /opt/IBM/HTTPServer/Plugins \
-omitAction samplesInstallAndConfig

# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh \
-create \
-profileName DefaultAppSrvAA03 \
-profilePath /opt/IBM/WebSphere/Profiles/DefaultAppSrvAA03 \
-templatePath ../profileTemplates/default/ \
-nodeName DefaultAppSrvNodeAA03 \
-cellName DefaultAppSrvCellAA03 \
-adminUserName virtuser \
-adminPassword password \
-enableAdminSecurity true \
-omitAction samplesInstallAndConfig deployAdminConsole \
-webServerCheck true \
-webServerType IHS \
-webServerOS aix \
-webServerInstallPath /opt/IBM/HTTPServer \
-webServerPluginPath /opt/IBM/HTTPServer/Plugins \
-omitAction samplesInstallAndConfig

# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh \
-create \
-profileName DefaultAppSrvAA04 \
-profilePath /opt/IBM/WebSphere/Profiles/DefaultAppSrvAA04 \
-templatePath ../profileTemplates/default/ \
-nodeName DefaultAppSrvNodeAA04 \
-cellName DefaultAppSrvCellAA04 \
-adminUserName virtuser \
-adminPassword password \
-enableAdminSecurity true \
-omitAction samplesInstallAndConfig deployAdminConsole \
-webServerCheck true \
-webServerType IHS \
-webServerOS aix \
-webServerInstallPath /opt/IBM/HTTPServer \
-webServerPluginPath /opt/IBM/HTTPServer/Plugins \
-omitAction samplesInstallAndConfig
Listing 9. DMGR profile
# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh \
-create \
-profileName DefaultDmgr01 \
-profilePath /opt/IBM/WebSphere/Profiles/DefaultDmgr01 \
-templatePath ../profileTemplates/management/ \
-serverType DEPLOYMENT_MANAGER \
-nodeName DefaultDmgrNode01 \
-cellName DefaultDmgrCell01 \
-adminUserName virtuser \
-adminPassword password \
-enableAdminSecurity true \
-defaultPorts \
-webServerCheck true \
-webServerType IHS \
-webServerOS aix \
-webServerInstallPath /opt/IBM/HTTPServer \
-webServerPluginPath /opt/IBM/HTTPServer/Plugins
Listing 10. Job Manager profile
# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh \
-create \
-profileName DefaultJobManager01 \
-profilePath /opt/IBM/WebSphere/Profiles/DefaultJobManager01 \
-templatePath ../profileTemplates/management/ \
-serverType JOB_MANAGER \
-nodeName DefaultJobManagerNode01 \
-cellName DefaultJobManagerCell01 \
-adminUserName virtuser \
-adminPassword password \
-enableAdminSecurity true \
-defaultPorts \
-webServerCheck true \
-webServerType IHS \
-webServerOS aix \
-webServerInstallPath /opt/IBM/HTTPServer \
-webServerPluginPath /opt/IBM/HTTPServer/Plugins
Listing 11. Create Reset profile
# cd /opt/IBM/WebSphere/Profiles
# mkdir -p /opt/IBM/WebSphere/Profiles/.ibm
# zip -r /opt/IBM/WebSphere/Profiles/.ibm/profiles.reset.zip *

E. Security concerns

During the initial boot of the newly provisioned virtual machine, the network daemon processes are activated prior to init.d/rc.d processing. This is a concern in that the activation engine is run during init.d/rc.d processing. Since an activation engine plug-in modifies the passwords to their new values, there exists a window in which it is possible for someone to log into the system using a user ID and the pre-modified password. The problem is not solved by randomizing the passwords during the virtual image template creation step. Discovery of the random password used is possible thereby exposing all virtual systems using the image.

A solution is to utilize a script or fb_script resource to set passwords to a random value or values. This solves the problem since both resources are invoked prior to the network being started.

Another solution is to disable remote access for all the user IDs during the creation of the virtual image template, then re-enabling remote access after the passwords are modified.

F. Sample activation engine and plug-ins

A sample activation engine is provided with this article, along with sample plug-ins for:

  • WebSphere Application Server Network Deployment V7.0
  • DB2 Enterprise Server Edition V9.5
  • AIX V5.3 and V6.1
  • ITM Agent V6.2

G. Sample NIM management script

Sample code is provided with this article to automate the tasks described. The code is written in Perl such that it should work on any AIX V5.3 TL7 and higher (V5.3 TL8 and V6.1) NIM master. The code contains NIM Perl modules and a script that can be located in any directory on the NIM master. The NIM Perl modules will perform the necessary NIM configuration steps and utilizes SSH to invoke lpar_netboot on the HMC. The script performs additional automation steps related to the sample activation engine and plug-ins. Essentially, the NIM Perl modules perform these generic tasks:

  • Configure NIM for deploying a mksysb image to a target system.
  • Invoke lpar_netboot to an HMC if one exists and SSH is available.
  • Monitor completion status of a bos_inst_operation.
  • Deliver metadata to the newly instantiated virtual machine to a know location.

Some advanced functionality also included are:

  • Automatic NIM mksysb definition and spot extraction.
  • Support for concurrent deployments utilizing file locks, where needed.
  • Dynamic image.data file extraction and modification to support installations to smaller disks.
  • Resize (larger or smaller) paging space during installation (for simple paging space logical volume schemes).
  • Deliver the base activation engine, plus plug-ins, to the target system along with the metadata during bos_inst.

Delivery of the activation engine and plug-ins, during bosint eliminates the need to actually install the activation engine on the virtual image template system (Step 1c), but more free space must be made available (Step 1d) to the file system of the /opt/IBM/AE directory (and also that of the /etc directory if a NIM fb_script resource is used instead of a script resource). The additional free space is required because the activation engine and its plug-ins are also installed along with the metadata.

With the supplied sample script, the only task required is the creation of the virtual image template system (minus Step 1c), capturing the image as a mksysb, copying the mksysb to the NIM master, and invoking the script with the required input. Most tasks required for configuring NIM for a system installation are handled automatically.

You can invoke the script with this command:

nimae –o deploy \
   –image NimMksysbName \
   –lpar NimMachineName\
   –config password=mypw > nim.xml

where NimMksysbName and NimMachineName are defined in the XML input (nim.xml). For this example, the NimMachineName is the short hostname (minus domain). The following is sample XML input:

Listing 12
<?xml version="1.0"?>
<pauto>
  <config>
    <lpar>
      <type>aix</type>
      <name>aix58</name>
      <profile>aix58</profile>
      <cec>SystemU2</cec>
      <hmc>ipv4-004.austin.ibm.com</hmc>
      <hmc_user>hscroot</hmc_user>
      <hostname>ipv4-078</hostname>
      <ip_addr>9.3.108.78</ip_addr>
      <domain>austin.ibm.com</domain>
      <nameservers>9.0.6.11 9.0.7.1</nameservers>
	<disk_size>10240</disk_size>
	<paging_space_size>1024</paging_space_size>
    </lpar>
    <image>
      <type>mksysb</type>
      <name>aix_5381_was_7_mksysb</name>
      <location>/export/nim/mksysb/aix_5381_was_7_mksysb</location>
      <ae_dir>/tmp/samples/AE</ae_dir>
      <ae_xml>/tmp/samples/AE/AP/was.ap</ae_xml>
      <ae_cmd>sh /opt/IBM/AE/ae -a /opt/IBM/AE/AL/wasv7.al</ae_cmd>
    </image>
  </config>
</pauto>

The nimae script will check for the XML input on standard input followed by a check for the existence of a NIM.xml file in the current working directory, if standard input is not specified. In the XML input to the script, lpar and image information can be specified as sub-elements under config.

For the lpar sub-element, you can specify these items:

Table 1
NameDescription
typePartition type (aix or vios). If unspecified, defaults to aix.
namePartition name
profilePartition profile name
cecCEC name
hmcHMC hostname; if specified, the script will attempt to invoke the appropriate lpar_netboot command via SSH.
hmc_userHMC user ID used to invoke the lpar_netboot command via SSH; defaults to hscroot, if unspecified.
hostnameHostname of the target system
nim_machine_nameNIM machine name; defaults to the short hostname (minus the domain), if unspecified.
nim_typeNIM machine type; defaults to standalone, if unspecified.
platformNIM platform; defaults to chrp, if unspecified.
netboot_kernelNIM netboot kernel; defaults to mp, if unspecified.
cable_typeNIM cable type; defaults to N/A, if unspecified.
connectNIM connect mechanism. Possible values are nimsh and shell; defaults to shell, if unspecified.
net_settingsNIM net settings; space separated speed and duplex values. For example, "100 full." Defaults to "auto auto," if unspecified.
mac_addrMAC address; should only be necessary to specify if more than one network adapter is available for the new system.
ifCorresponds to the if attribute of the NIM standalone object; should be unnecessary to specify this value since the script will invoke NIM to set the correct value. The existence of this lpar configuration element is as a user-specified override.
ip_addrIP address
gatewayGateway
network_typeNetwork type; defaults to ent, if unspecified.
subnet_maskSubnet mask
domainDomain name; might be unnecessary if the hostname includes the domain name.
nameserversSpace separated list of nameserver IP addresses
disk_sizeThe desired size (in MB) of the root volume group for the new system This option causes the script to calculate the minimum disk size required for the image. If the new disk size is less than the minimum size required, an image_data resource will be created in an attempt to reclaim available file system freespace such that the image can fit on the new disk.
paging_space_sizeDesired size (in MB) of the paging space for the new system; if unspecified, the paging space is left unchanged.

For the image sub-element, you can specify these items:

Table 2
NameDescription
nameNIM object name corresponding to the mksysb
locationPath name of the mksysb file on the NIM master; if unspecified, the value defaults to the NIM mksysb location if the mksysb is already defined to NIM.
ae_dirRoot directory of the activation engine code on the NIM master
ae_xmlMetadata file template that will be updated by the script and provided to the new system; metadata file templates are provided as part of the sample activation engine code under the AP subdirectory of the specified ae_dir.
ae_cmdThis is essentially the activation engine install command from Step 1c; for example: sh /opt/IBM/AE/ae -a /opt/IBM/AE/AL/wasv7.al

The –config option for the script is used to customize the metadata file template to create a deploy-specific metadata file. The value for the option takes the form of PropertyKey=PropertyValue. The PropertyKey takes the form of ConfigurationName.ParameterName matching the metadata file template. The PropertyValue will be the deploy-specific value for the PropertyKey. The –config option can be specified multiple times on the script command line. The following are examples illustrate the use of this option:

	-config ConfigPWD.password=mypw
	-config ConfigWAS.autostart=true

To apply the same value for all configurations with the same ParameterName, you can specify, for example: -config password=mypw

Additional documentation is embedded in the Perl script and module files in perldoc format. Create and invoke a script similar to the following, from the root directory in which the script and module files are located, to extract the documentation:

Listing 13
#!/usr/bin/perl

use File::Path;
use FileHandle;
use File::Basename;

my @pm_files = `find . -name "*.p[lm]"`;
foreach my $pm_file (@pm_files)
{
  chomp($pm_file);
  
  my $dir_name = dirname($pm_file);
  my $file_name = basename($pm_file);
  
  mkpath("html/$dir_name");
  $file_name =~ s/\.p[lm]$//;

  print "pod2html $pm_file > html/$dir_name/$file_name.html\n";
  `pod2html $pm_file > html/$dir_name/$file_name.html`;
}
print "pod2html nimae > html/nimae.html\n";
`pod2html nimae > html/nimae.html`;

Download

DescriptionNameSize
Code sample0904_ja_sample.zip59 KB

Resources

Learn

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, AIX and UNIX, Multicore acceleration
ArticleID=386194
ArticleTitle=Automating deployment and activation of virtual appliances for IBM AIX and Power Systems
publish-date=04292009