AIX 6.1 introduced a new software virtualization feature called Workload Partitions (WPARs). WPARs provide a software solution to create virtualized operating system environments for managing multiple workloads within a single AIX operating system instance. Each WPAR can host an application and is completely isolated from processes and applications executing within other WPARs. WPARs also have the capability to be actively relocated (or migrated) from one AIX logical partition (LPAR) to another AIX logical partition.
The relocation of a WPAR involves moving its executable code from a source LPAR to a destination LPAR, while keeping application data on common Network File Systems (NFS) that are visible and accessible to both source and destination LPARs. AIX operating system binaries can be stored in file systems local to the hosting logical partition.
|WPAR file system||File system location|
|/usr||Global environment/NFS mounted|
|/opt||Global environment/NFS mounted|
|Application file systems||NFS mounted|
Example of NFS mounted WPAR migration
Let us consider a WPAR migration example. Figure 1 below shows three AIX logical partitions: Node_A, Node_B and Node_C. Node_A is a source logical partition which is hosting a system workload partition, WPAR1. Node_B is the destination logical partition where WPAR1 will be migrated. And Node_C is a NFS server required to support workload partition mobility.
Before creating WPAR1, create its filesystems (/, /var, /tmp, /home and application filesystems) on the NFS server. These filesystems are exported to Node_A, Node_B and WPAR1. While creating WPAR1, its filesystems are mounted on Node_A and the WPAR1. When WPAR1 migrates from Node_A to Node_B, its file systems is mounted on Node_B and unmounted from Node_A. This way, WPAR migration has to rely on common NFS filesystems hosted on a separate NFS server.
Figure 1. WPAR migration illustration
Drawbacks of NFS-based WPAR mobility
Although NFS-based WPAR mobility is a great feature, it has some drawbacks. Some applications, such as Oracle® database, do not support data access over NFS. These applications cannot be hosted on NFS-based WPARs and can not be relocated. We also need an additional NFS server to support WPAR mobility and the customer base for NFS-based WPARs has shown to be limited.
Rootvg WPARs as the solution
To eliminate the need of NFS services for WPAR mobility, AIX started supporting SAN-based system WPARs from AIX 6.1 TL4 and later versions. With this feature, we can assign (or export) SAN storage disks to system WPARs while creating the WPAR. root filesystems ( /, /usr, /opt, /home, /tmp and /var filesystems) of the WPAR are created on the storage disks that are assigned to the WPAR. This means a WPAR can have its own rootvg. From here on, SAN-based system WPARs are referred as rootvg WPARs.
A simple rootvg WPAR configuration is illustrated in Figure 2. Node_A and Node_B are two LPARs at AIX 6.1 TL4 level. SAN disks are allocated to both nodes in shared mode (that means disks are seen on Node_A and Node_B) using fibre channel (FC) adapters. WPAR1 is a rootvg WPAR on Node_A. Two SAN disks are exported to WPAR1. The rootvg of WPAR1 resides on these SAN disks. To migrate WPAR1 from Node_A to Node_B, the SAN disk should be accessible on the destination node also. In this configuration, we do not have to rely on NFS server for system WPAR migration.
Figure 2. SAN-based system WPAR illustration
Keep in mind that the operating system level on the LPAR should be at AIX 6.1 TL4 or above, and that only SAN disks accessible using fibre channel adapters are supported.
Configuring and administrating SAN-based system WPARs
Now that we know what rootvg WPARs are, the following example shows how to create and administer these workload partitions. For the purpose of the demonstration, we are using LPAR thick04, which is at AIX 6.1 TL4 level. To showcase WPAR migration, we use another LPAR, thick03, which is also at AIX 6.1 TL4 level.
Make sure that the LPAR has SAN disks allocated to it. In Figure 3, we see that thick04 has several SAN disks accessed through an FC adapter.
Figure 3. SAN disk connected through an FC adapter
Creation of rootvg WPAR
We create the rootvg WPAR thick04cor03 using the
mkwpar command. We should use
rootvg=yes along with the
-D option to specify that we are
creating a rootvg WPAR. In this example, we are creating thick04cor03 on hdisk5.
The following snapshot shows how to create rootvg WPAR.
Figure 4. Creation of rootvg WPAR
Listing of rootvg WPAR
lswpar command lists the WPAR that we just created. Note that the output of the
lswpar command has an additional column which says if a WPAR is a rootvg WPAR or not.
Figure 5. Listing the rootvg WPAR
After logging (using telnet or clogin) in to thick04cor03 (which is a rootvg WPAR), we see that it has its own rootvg.
Figure 6. Inside the rootvg WPAR
Adding extra disks to rootvg WPAR
Additional disks can be exported to rootvg WPARs using the
chwpar command as in the
example that follows. Disks that are assigned using
chwpar are seen as free disks
inside the rootvg WPAR. Use these disk to create user defined volume groups.
Figure 7. Adding disk to the rootvg WPAR
The disks that are assigned to rootvg WPARs will not be accessible to the global LPAR.
lswpar command with the
-D option shows the disks that are assigned to a rootvg WPAR.
Figure 8. Listing the disks of the rootvg WPAR from the global
Rootvg WPAR migration using IBM Director 6.1.2 with WPAR manager plug-in.
Now that we have created a rootvg WPAR, let us migrate it to another LPAR using IBM Director 6.1.2 with the WPAR manager plug-in. The destination LPAR used is thick03. As mentioned before, the source and destination LPARs should share disks that are used to create rootvg WPARs. This means the SAN disks that are accessible on thick04 should also be accessible on thick03.
IBM Director 6.1.2 with WPAR manager plug-in is installed on LPAR reno01.upt.austin.ibm.com. IBM Director console can be opened using the link http://IBM_director_server:8422/ibm/console. Before we could create or administer WPARs, we should register our global LPARs thick03 and thick04 (also called WPAR agents) with IBM Director. An additional fileset, wparmgt.agent.rte, should be installed on thick03 and thick04. Following snapshots show the stepwise procedure to register WPAR agents.
After WPAR agents are discovered on IBM Director, we should collect the inventory so that we can see all the WPARs that exist on WPAR agents.
Discovering WPAR agents on IBM Director console
Figure 9 shows the view when we open IBM Director console on any of the browsers. As shown in Figure 9, we need to click on Inventory on the left side navigation bar. After clicking on inventory, we need to click on system discovery.
Figure 9. IBM Director console view
Figure 10 shows system discovery on the IBM Director console. After clicking on system discovery, we need to give IP address of WPAR agents (thick04, thick03) and click on discover. Then, we will see WPAR agents on the IBM Director console.
Figure 10. System discovery on IBM Director console
Collecting Inventory of WPAR agents on IBM Director
After the WPAR agents are discovered on IBM Director, we should collect the inventory so that we can see all the WPARs that exist on WPAR agents.
Figures 11, 12, and 13 show step-by-step on how to perform collect inventory of WPAR agents. After WPAR agents are discovered, we need to click on Navigate resources on the left side navigation bar (shown in Figure 9) and then click on All systems as shown below in Figure 11. We need to search for WPAR agents named thick04, thick03, and then click on the Actions button as shown below in Figure 12. After clicking on Actions, we will get a drop down menu. There, we will click on Inventory and then Collect inventory.
Figure 11. Collecting inventory of WPAR agents from IBM Director (Step 1)
Figure 12. Collecting inventory of WPAR agents from IBM Director (Step 2)
Figure 13. Collecting inventory of WPAR agents from IBM Director (Step 3)
To view WPARs on IBM Director console
To view/administer WPARs, we should launch "WPAR Manager" console. We need to install WPAR Manager Plugin on IBM Director to view and administer WPARs. Here, we can see the rootvg WPAR (thick04cor03) that we have created in the above example.
Figure 14 and Figure 15 shows step by step on how to view WPARs on IBM Director console. Figure 12 shows the view when we open IBM Director console and we need to click on WPAR Manager and we will further get WPAR Manager window. To view WPARs, we need to click on view workload partitions in WPAR Manager window. Figure 13 shows view of WPAR Manager on IBM Director. After clicking view workload partitions, we will see all workload partitions which are there on WPAR agents thick04 and thick03. As shown in below figures, Currently we have two WPARs thick04cor01 and thick04cor03 (We have created in previous example).
Figure 14. To view WPARs on IBM Director console (Step 1)
Figure 15. To view WPARs on IBM Director console (Step2)
Migrating rootvg WPAR
Now let us migrate thick04cor03 from thick04 to thick03.
Figure 16, Figure 17 and Figure 18 shows step by step on how to do migration of rootvg WPAR using IBM Director. As shown in Figure 15 click on thick04cor03 and click on Actions button. After clicking on Actions button, we will get drop menu. Thier, we need to select "Relocate". Then, Select the destination managed system (thick03 in our case) from the window which is shown in Figure 16. Then, we need to select relocation method (Live in our case) as shown in Figure 17 and then we will get summary. Click on Finish to start the migration process. Figure 18 shows percentage of progress of migration that has been taken place.
Figure 16. rootvg WPAR migration using IBM Director (Step 1)
Figure 17. rootvg WPAR migration using IBM Director (Step 2)
Figure 18. rootvg WPAR migration using IBM Director (Step 3)
After successful WPAR migration, we see that thick04cor03 is on thick03 LPAR.
Figure 19 below shows thick04cor03 is on thick03 LPAR after successfull migration.
Figure 19. WPAR at arrival machine at thick03
In this article, we started with traditional WPAR migration using NFS services. Then, we introduced the concept of rootvg WPARs and WPAR migration using SAN-based data model to overcome some of the drawbacks of NFS-based WPARs. We also discussed WPAR migration using IBM Director V6.1 with WPAR manager plug-in.
- "AIX 6.1 Workload Partitions" (developerWorks November 2007): An article that helps you in deciding whether WPARs are right for your AIX workloads.
- Introduction to Workload Partition Management in IBM AIX Version 6.1. provides an introduction and “how to” guide for system administrators and architects using workload partitions.
Get products and technologies
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
- Follow developerWorks on Twitter.
- Get involved in the My developerWorks community.
- Participate in the AIX and UNIX® forums:
Dig deeper into AIX and Unix on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.