Versioned Workload Partitions

Preparation and requirements for versioned WPARs


Using IBM AIX 5.3/5.2 Workload Partitions for AIX 7, you can now run legacy applications on AIX 5.3 or AIX 5.2 in an AIX WPAR. This program provides the capability to create a WPAR that provides an AIX 5.3 or AIX 5.2 runtime environment for the workload running in the WPAR. This allows a simple migration path for an AIX workload running on older hardware to move to IBM POWER7® processor-based systems. All that is required is to create a mksysb image of the system and then provide this image when creating the versioned WPAR on AIX 7.1 running on the POWER7 hardware.


  • Adds a kernel compatibility layer that allows AIX 5.3/5.2 commands and libraries running in the WPAR to function correctly (emulating AIX 5.3/5.2 behavior) when run on AIX 7.1 .
  • Enables you to take advantage of the latest IBM Power Systems™ hardware enhancements sooner by running your legacy applications in a virtualized WPAR environment.

When to use

The AIX 5.3/5.2 WPARs product is primarily intended for client workloads that have a long-term requirement to continue running the application on AIX V5.3/5.2. For workloads that cannot be upgraded to a later level of AIX, AIX 5.3/5.2 WPARs provide an easy way to take advantage of the latest generation of IBM POWER® processor-based servers. This allows more time to be able to move to different applications at a later time.

When not to use

There are a couple of times that you might not want to use a versioned WPAR and I will just elaborate on this for your consideration. I will not cover this in too much detail, but will provide an overview about the system that you will be migrating on to this environment.


When security in your business is important, you need to first assess if versioned WPARs would actually work. In many cases, you can gain access to any system using the global logical partition (LPAR) and as seen later in this article, you can allow rlogin or can use clogin to gain access.

Do not despair if you put strict controls in place in the global LPAR, Hardware Management Console (HMC), and other systems in your environment; this will enable you to be secured.


If your environment has a problem, you lose the global AIX system or you are performing maintenance on the global LPAR, then every versioned WPAR defined will be affected. You can overcome this by planning the system in more detail. Create more than one global LPARs. This will then allow you to move system versioned WPARs from one system to the another in case you need to take down the global LPAR. Just remember that storage must be visible to both to allow this.


I am extremely conservative when it comes to production. I like to run a production system within its own LPAR (but that is just me).

I would have to say that there are some application vendors who support an LPAR but not necessarily support the product in a versioned WPAR. Now, I am not saying that it would not run, but you have to consider the consequences of support for a production environment.

Physical devices

Device support is limited to devices directly supported in WPAR (and on POWER7 processor-based servers).

Kernel extensions and applications

Also be aware that a WPAR has no access to the system kernel information, or the ability to install kernel extensions or have access to kernel extensions provided by the parent LPAR. All of this has to be done by the Global LAPR and will effectively place the same settings on all versioned WPARs running on this system. So, you might have an issue where one application on a versioned WPAR requires a patch that is not supported by the second application on a different versioned WPAR. You must also look at the support for application with restrictions on binary compatibility issues later in this article.

Limitations of a versioned WPAR

The operating environment for an AIX 5.3 Workload Partition for AIX 7 is a WPAR on an AIX 7 system. Some AIX functionality is limited within a WPAR; therefore, that same functionality is limited from within an AIX 5.3 Workload Partition on AIX 7.1. These restrictions include but are not necessarily limited to the following areas:

  • IBM PowerHA® software is not supported within a WPAR but can be implemented at a global level, which drastically reduces manpower.
  • Reliable Scalable Cluster Technology (RSCT) is not supported within a WPAR.
  • Network File System (NFS) server is not supported within a WPAR but you can mount it at the global level and add it to the WPAR.
  • Workload Manager (WLM) controls are not supported within a WPAR but done at Global level for sanity reasons.
  • WPARs cannot be created within a WPAR.
  • Only a subset of symbols referenced through /dev/kmem is accessible from the processes within a WPAR.
  • Kernel performance tunables are not modifiable from within a WPAR.

Versioned WPAR software install requirements

There is no need to install software into the existing systems before making a system as a versioned WPAR. There is a process in place to install the required component in the recovery process from a maksysb to a versioned WPAR.

The global LPAR needs to have the file sets for 5.3/5.2 versioned WPARs loaded.

  • AIX5.3 WPAR licenced file sets to be installed into the target system (global AIX):
    • bos.wpars
    • vwpar.53.rte
    • wio.common

    Note: No need to install any additional filesets onto the source v5.3/v5.2 LPARs.

  • Global LPAR: AIX V7.1 TL01 SP05 (recommended) SP04 (minimum)
  • Versioned WPAR: AIX V5.3 TL12 SP05 (minimum) / AIX V5.2 TL10 SP08 (minimum)
    • Limited 64-bit kernel extension is supported for a vWPAR.
    • Extensions should be installed on the global LPAR.
  • There is not a vision of versioned WPAR for any other AIX at this time.

Installing support for versioned WPAR

To install support for versioned WPARs from a CD, use the following command:

installp -acXY -d /dev/cd0 vwpar.images

If you have IBM Systems Director with the Workload Partition Manager plugin and plan to use Live Application Mobility (LAM), then all of the vwpar.images files from the same level of versioned WPAR must be installed on any system to which a vWPAR is to be moved.

Support requirements

  • Support for the versioned WPAR filesets in the global LPAR is included in AIX 7.1 when using versioned WPARs on the systems.
  • No extended support of the AIX 5.3/5.2 image is provided under the AIX 7.1 Software Maintenance (SWMA).
  • The versioned WPAR 5.3/5.2 support is meant to be instead of the Extended Support for running AIX 5.3/5.2.
  • AIX 5.2 and AIX 5.3 versioned WPAR software are separate licensed products. AIX 5.3 versioned WPAR licensed program product (LPP) does not provide AIX 5.2 versioned WPAR file sets (and AIX 5.2 versioned WPAR file sets does not provide AIX 5.3 versioned WPAR LPP).

WPAR copy requirements

The following list shows you the requirements before migrating to a versioned WPAR. Before creating the final mksysb image to generate the WPAR, it is recommended to complete the following tasks on the system that will be migrated.

  • There is no direct HMC console login available to a WPAR, so rlogin for the root user must be enabled in order to clogin to the WPAR from the global LPAR.

    chuser rlogin=true root

  • Auditing should be disabled before taking the mksysb image (PMR: 06708,021,866).
  • Versioned WPARs cannot be an NFS server. Disable or remove the NFS exported entries using the following command.

    rm /etc/exports && >/etc/xtab && chmod 400 /etc/xtab

  • A versioned WPAR can adjust its own time zone only.
  • Versioned WPARs cannot adjust their system clocks. Disable Network Time Protocol (NTP) and rename it.


  • Versioned WPARs cannot run dump activities. Disable the dumpcheck function.

    /usr/lib/ras/dumpcheck -r


This requirements list must be considered as an impact to the existing environments. Because of this, you might have to take a staged approach for creating the versioned WPARs when you have systems that do not allow you to turn off any of the functions mentioned in this list.

Staged approach

A system that has any of the items in this requirement list necessary for running production, can be staged to allow for the protection of production environments until the system is moved. So what can be done?

Instead of changing production, we can follow a staged approach to migrate the environment.

  • Restore the source mksysb image to a staging system where the OS is changed inflight and then this will be used to create the new mksysb image.
  • Import a mksysb of the changed system into the versioned WPAR.

Restrictions and limitations within a versioned WPAR

A versioned WPAR provides a different version runtime environment than the global system. Versioned WPARs have some limitations when compared to local system WPARs.

Functions within a versioned WPAR include the following limitations:

  • File systems cannot be shared with other WPARs.
  • Commands and features not supported by the AIX version of the runtime environment are not supported in the WPAR, even though they might be available in the global system.
  • Adapters cannot be exported to a versioned WPAR.
  • Storage adapters are not supported for export to versioned WPARs.
  • If a root volume group (rootvg) WPAR is created, the standard journaled file system (JFS) file systems are not supported. When the file systems are created on a WPAR-owned rootvg, the JFS file systems from the system image are converted to enhanced journaled file systems (JFS2) file systems.
  • Some commands from the AIX 7.1 environment replace the commands from the original AIX environment that are used to populate the versioned WPAR, including (but not limited to) the following types of commands:
    • File system commands
    • Logical volume commands
    • System performance commands

File system support


You should change file systems to JFS2. The reason for not using JFS is as follows: Should you need to change the file system size, you have to do it on the AIX 7.1 host, as version WPARs do not support the manipulation of JFSs. The only other option is to delete the file system and re-create it as JFS2.

If local storage devices are used for the WPAR, JFS file systems are not supported. JFS for rootvg will be converted to JFS2 as the system is built. The JFS file systems from the AIX 5.3/5.2 environment will not be automatically converted to JFS2 file systems.

Nested mount points

If your mksysb image contains multiple mount points on top of /usr /var and so on, then unless you have the latest interim fix there might be issues in creating the actual versioned WPAR.

Restrictions and limitations of migration versioned WPARs

  • A versioned WPAR cannot be converted back to a stand-alone AIX system. It is recommended that any mksysb image used to create the versioned WPAR is retained in the event that a stand-alone environment is required at a later date.
  • A versioned WPAR cannot (currently) be updated to a later version of AIX. TL/SP updates for the current version are supported.

To view the files within a versioned WPAR that are replaced by local or alternative programs, run the following command within the versioned WPAR:

ODMDIR=/usr/lib/objrepos odmget file_overlay | awk '$1=="path" {print $3}'

Application and database binary compatibility

Refer to this website for more details about restriction on applications and support for them when it comes to 32-bit software in versioned WPARs.


Here are a few useful links in to the AIX manual for versioned WPARs

Here are some more references with useful information.

Downloadable resources


Sign in or register to add and subscribe to comments.

Zone=AIX and UNIX
ArticleTitle=Versioned Workload Partitions