IBM Books

Installation and Migration Guide


Post-migration activity

This section discusses the activities you should perform after a successful migration. It also discusses recovery procedures you should perform if the migration process was not successful.

Remove obsolete files and resources

After migrating the control workstation to |PSSP 3.4, you may be supporting nodes at mixed levels of AIX and PSSP for a period of time. Once all the nodes have been migrated to AIX level n and PSSP level p and none of the PSSP levels that you are still supporting are dependent on AIX level n-1, you can remove all NIM resources and files associated with this old level of AIX and PSSP. You may want to back up these files prior to removing them if there is any chance that you may one day need to reinstall nodes at this level of AIX and PSSP. You can remove the files listed in the following list:

Note:
|If you do not plan on supporting back-level system partitions from |the control workstation after migrating to PSSP 3.4, you should remove |the ssp.jm file set from the control workstation. |

For example, if you completed migrating all of your nodes from |PSSP 2.4 and AIX 4.2.1 to |PSSP 3.4 and AIX 4.3.3 and you do not have any nodes that are running on AIX 4.2.1, you may now remove the following NIM resources and files. Assume that your mksysb image is named bos.obj.ssp.421 and that your lppsource is stored in the directory named AIX421.

  1. Remove the NIM resources associated with AIX 4.2.1; the lppsource, spot, and mksysb. To remove the lppsource resource, issue the command:
    nim -o remove lppsource_AIX421
    
  2. Remove the spot and all files that NIM generated for this spot by issuing the following command:
    nim -o remove spot_AIX421
    
  3. Remove the mksysb resource by first displaying a list of all resources of type mksysb by issuing the command:
    lsnim -t mksysb -l
    

    Determine which mksysb is associated with bos.obj.ssp.421. For example, if after examining the output of the previous command, you see that bos.obj.ssp.421 is associated with mksysb_x, then remove the mksysb_x resource by issuing the command:

    nim -o remove mksysb_x
    

    If the resource removal fails, you may first need to deallocate the resources from all clients using the unallnimres command.

    Then, remove the AIX files associated with AIX 4.2.1 (lppsource, mksysb) and |PSSP 2.4 by issuing the following commands:

    |rm -r /spdata/sys1/install/AIX421
    |rm -r /spdata/sys1/install/images/bos.obj.ssp.421
    |rm -r /spdata/sys1/install/pssplpp/PSSP-2.4
    
    

Recovery procedures

If you encounter a migration failure which you cannot resolve, you can call an IBM service representative for additional help. In addition, refer to the following list for a basic set of instructions for recovering your system. You may use the backups you made prior to the migration.

Recovering from a PTF migration failure

Recovering from a control workstation migration failure

If you are recovering from a control workstation migration failure, perform the following steps:

  1. Insert the tape, the mksysb backup, that you created in Step 10: Back up your control workstation.
  2. Change the key to the service position. If your control workstation is a PCI-based RS/6000, press the F1 or F2 key (depending on the model) at boot time. This provides a menu. From this menu, select the tape as boot device and press Enter. If your control workstation is a microchannel-based RS/6000, follow the instructions on the screen.
  3. Select the disks to install the rootvg volume group.
  4. Reinstall the control workstation using the mksysb install option.
  5. Wait for the control workstation to reboot.
  6. Login as root user after successful completion of the restore.
  7. Authenticate as the Kerberos V4 Administrative Principal by issuing the k4init command. For example:
    k4init root.admin
    
  8. Complete the PSSP installation on the control workstation by issuing the command:
    install_cw
    
  9. Check to see if your SDR is correct by issuing the spmon -d command and the splstdata command. If the SDR is corrupt, you may restore a previously archived SDR by issuing the command:
    sprestore_config SDR_archive_name
    
  10. Restore any other files that you may have saved.

Recovering from a node migration failure

If you are recovering from an SP node migration failure, perform the following steps:

  1. Place the SP node mksysb image file that you previously saved in Step 11: Back up your nodes into the directory /spdata/sys1/install/images.
  2. Update the SDR to match the proper settings for the SP node being restored. Issue the spchvgobj command with -r volume_group_name, -v old_lppsource_name, -p old_code_version, -i old_install_image -l node_list and spbootins with -s no, -l node_list -c volume_group -r install for the node.
  3. SP User Management changes some AIX file attributes. These changes must be undone or errors will occur later. To undo the changes, do the following:
  4. Network boot the SP node using the nodecond command or Perspectives. This will reinstall the SP node back to the same AIX and PSSP level of the backup mksysb image.
    Note:
    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.
    nodecond -G frame_id slot_id &
    
  5. Restore any other user volume groups or files that were saved in Step 11: Back up your nodes.
  6. Change the state of usermgmt_config to what it was previously.


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