IBM Books

Installation and Migration Guide


BOS node migration install

Before proceeding with the steps in this section, be sure you have selected the correct migration path. |A BOS node migration is used when you are changing your AIX version |or release, for example, from AIX 4.3.3 to AIX 5L |5.1.

Step 1: Enter node configuration data

You need to properly set the appropriate SDR node object attributes for lppsource_name, code_version, bootp_response, and pv_list for each node being migrated. Use the spchvgobj and spbootins commands to update these fields. If you are migrating nodes in more than one system partition, you will need to issue these commands in each system partition. For a complete description of the flags associated with these commands, refer to PSSP: Command and Technical Reference.

Note:
|Even though it is not necessary to specify -i |install_image flag on the spchvgobj command during |migration, it is suggested at this point to avoid future problems. |

For example, to migrate nodes 1 and 2 to |AIX 5L 5.1 and |PSSP 3.4 where lppsource was placed in |/spdata/sys1/install/aix510/lppsource, issue the following two commands:

|spchvgobj -r selected_vg -p PSSP-3.4 -v aix510 -h 00-00-00-0,0 \
|          -l 1,2 -i bos.obj.ssp.510
| 
|spbootins -s no -r migrate -l 1,2

For example, to migrate nodes 1 and 2 to |AIX 5L 5.1 where lppsource was placed in |/spdata/sys1/install/aix510/lppsource, issue the following two commands. |Note that because this example does not include the |-p flag, the nodes must already be migrated to PSSP |3.4. This sets up for an AIX migration only.

|spchvgobj -r selected_vg -v aix510 -h 00-00-00-0,0 -l 1,2 \
|          -l 1,2 -i bos.obj.ssp.510
| 
|spbootins -s no -r migrate -l 1,2

Step 2: Verify installation settings

Make sure that the SDR has the appropriate values specified in the following attributes for each of the nodes. Issue the following command to display the values:

splstdata -G -b -l node_list

Make sure that /tftpboot/script.cust and /tftpboot/firstboot.cust have been properly updated for |PSSP 3.4 modifications. See Appendix E, User-supplied node customization scripts for additional information.

Step 3: Run setup_server to configure the changes

Note:
Do not run setup_server on any nodes defined as a boot/install server until the boot/install servers have been migrated.

The setup_server command must be run to properly set up NIM on the control workstation by issuing the following command:

setup_server 2>&1 | tee /tmp/setup_server.out

The output will be saved in a log file called setup_server.out.

If you have a node defined as a boot/install server, you must also run setup_server out on that server node.

dsh -w boot/install_node "/usr/lpp/ssp/bin/setup_server \
    2>&1" | tee /tmp/setup_server.boot/install_node.out

|Step 4: Refresh RSCT subsystems

The SDR has now been updated to reflect the new nodes that will run |PSSP 3.4. You now need to refresh the |RSCT subsystems on the control workstation and all nodes to pick up these changes. Run syspar_ctrl on the control workstation to refresh the subsystems on both the control workstation and on the nodes.

syspar_ctrl -r -G
Note:
You can ignore any messages that you receive from the nodes you are migrating at this point because the migration process is not yet complete. Once the migration is complete, you should no longer receive error messages.

Step 5: Disable nodes from the switch

If you do not have a switch in your SP system, skip this step.

If you want to bring the switch down for all nodes, issue the Equiesce command for each system partition.

Note:
|If you are using the Switch Admin daemon for node recovery, stop it |by issuing stopsrc -s swtadmd on SP Switch systems or stopsrc -s |swtadmd2 on SP Switch2 systems before issuing the Equiesce |command. |

If you use the Equiesce command, you will need to later restart the switch using the Estart command. Issue the Estart command prior to the step where you "Verify the nodes."

If you are migrating a few nodes, you must disable these nodes from the switch (if appropriate, first reassign the primary node or primary backup node). To determine if one of the nodes you are migrating is a primary or primary backup node, issue the Eprimary command. If you need to reassign the primary or primary backup node, issue the Eprimary command with appropriate options. Then issue the Estart command to make your choices effective. You must then issue the Efence command to disable the nodes you are migrating from the switch.

Efence -G node_number node_number

Step 6: Shut down the node

To shut down the node gracefully, issue the following command:

cshutdown -F -G -N node_number

Step 7: Network boot the node

Notes:

  1. If you have any boot/install servers in your system, you need to migrate them before migrating their clients. You should not netboot more than eight nodes with the same server at a time.

  2. For MCA nodes, the nodecond command remotely processes information from the initial AIX firmware menus. You should not change the language option on these menus. The language must be set to English in order for the nodecond command to run properly.

Network boot each node that you are migrating by using Perspectives or by using the nodecond command.

nodecond -G frame_id slot_id &

You should notice that the node has been properly installed when the LED's become blank, and the host_responds is active.

Verify that the bootp_response has been set to disk by issuing the following command:

splstdata -G -b

Step 8: Rejoin the nodes to the switch network

If you disabled all nodes in Step 5: Disable nodes from the switch using the Equiesce command, you must now issue the Estart command in each system partition to rejoin the nodes to the current switch network.

Note:
|If you are using the Switch Admin daemon for node recovery, start it |by issuing startsrc -s swtadmd on SP Switch systems or startsrc |-s swtadmd2 on SP Switch2 systems before issuing the Estart |command. |

If you disabled only a few nodes using the Efence command, you must now issue the Eunfence command to bring those nodes back to the switch network.

Step 9: Run verification tests

Verify that the nodes are running properly by issuing the following commands:

SYSMAN_test
CSS_test              * run only if you have a switch
spverify_config       * run only if your system is partitioned
st_verify             * run only if Job Switch Resource Table Services
                        is installed

Verify that host_responds and switch_responds, if you have a switch, are set to yes by issuing the following command:

spmon -d -G
Note:
If you are migrating nodes in more than one system partition, you need to run CSS_test in each of the system partitions.

|Step 10: Apply PSSP PTFs to nodes (optional)

| |

|Software maintenance (PTFs) may now be applied to the PSSP file sets |installed on the nodes. If you installed software maintenance on the |control workstation before the node migration, you must install the service |updates to the nodes now. Refer to Installing updates on a per node basis for detailed instructions.

|Note:
At this point, refer back to High-level migration steps to determine your next step in the migration |process. |

|


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]