IBM Books

Installation and Migration Guide

Task E. Power on and install the nodes

This section describes the steps you take to power on the nodes to be installed.

Step 68: Network boot optional boot/install servers

Note:
If you have set up system partitions, do this step in each partition.

Follow the instructions in the following table to network boot the optional boot/install servers which install and customize the nodes you selected. To monitor installation progress by opening the node's read-only console, issue: 

s1term frame_id slot_id

If you have more than eight boot/install servers on a single Ethernet segment, you should network boot those nodes in groups of eight or less. See the "IP performance tuning" section in RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment for more information.

Notes:

  1. For systems with boot/install server nodes, the tuning.cust file must first be propagated to the server node before attempting to propagate it to the client node.

  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.

If using: Do this:
Perspectives

SELECT
The Hardware Perspective icon by double clicking

SELECT
The Nodes pane

SELECT
Actions > LCD and LED display
  • The LCD and LED display appears.

SELECT
Nodes to be netbooted

SELECT
Actions > Network Boot

SELECT
Apply
  • All selected nodes are booted.

If you had the Hardware Perspective up before you added the required node information, you should delete and re-add the Nodes Pane. If you had the Hardware Perspective up before you partitioned your system, you should delete and re-add the CWS/System/Syspars Pane and then delete and re-add the Nodes Pane.

nodecond Enter: 
nodecond frame_id slot_id &

Enter: 

spmon -Led nodenode_number

or 

spled &

to check the LCD and LED display for each node.

Network installation progress

When a network installation is in progress, the LED for the nodes involved show various values. These values indicate the installation stage. Since the node installation process can be long, it is hard to determine where you are in that process. Refer to PSSP: Diagnosis Guide for a complete list of PSSP-specific LED values.

Step 69: Verify that System Management tools were correctly installed on the boot/install servers

Now that the boot/install servers are powered up, run the verification test from the control workstation to check for correct installation of the System Management tools on these nodes.
If using: Do this:
Perspectives

SELECT
smit SP_verify on CWS from the Launch Pad.

From this point, you can follow the rest of the SMIT steps described in the next row of this table.


SMIT

TYPE
smit SP_verify
  • The RS/6000 SP Installation/Configuration Verification Menu appears.

SELECT
System Management

SYSMAN_test Enter: 
SYSMAN_test

After the tests are run, the system creates a log in /var/adm/SPlogs called SYSMAN_test.log.

See the section on "Verifying System Management installation" in PSSP: Diagnosis Guide for information on what this test does and what to do if the verification test fails.

Step 70: Network boot the remaining RS/6000 SP nodes

Note:
If you have set up system partitions, do this step in each partition.

Repeat the procedure used in Step 68: Network boot optional boot/install servers to network boot and install, or customize the remaining nodes. You may need to ensure that all setup_server processes have completed on the boot/install nodes prior to issuing a network boot on the remaining nodes. Refer to the /var/adm/SPlogs/sysman/node.console.log file on the boot/install node to see if setup_server has completed.

If any of your boot/install servers have more than eight clients on a single Ethernet segment, you should Network Boot those nodes in groups of eight or less. See the "IP performance tuning" section in RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment for more information.

Using a token ring-bridge gateway

If you are using a token ring through a bridge as your default gateway to your nodes and the token ring bridge is not on the same segment as your LAN, you must change the value of the broadcast field in the ODM for each node. The default value is set to No (confine broadcast to local token-ring) each time you install or customize a node. However, when you boot the nodes with this bridge setup, the network is unusable.
If using: Do this:
SMIT

TYPE
smit chinet
  • The Available Network Interfaces menu appears.

SELECT
tr0 Token Ring Network Interface

TYPE
Yes in the Confine BROADCAST to LOCAL Token-ring field.

chdev Enter: 
chdev -P -l tr0 -a allcast=off

Step 71: Verify node installation

If you have set up system partitions, select a global view to do this step.

Check hostResponds and powerLED indicators for each node.
If using: Do this:
Perspectives

SELECT
The Hardware Perspective icon by double clicking
  • The Hardware Perspective appears.

SELECT
The Nodes Pane

SELECT
View > Show Objects in Table View.
  • The Set Table Attributes dialog box appears.

SELECT
The Power table column.

SELECT
The hostResponds column while pressing the CTRL key on the keyboard.

PRESS
Ok
  • All of the table attributes should now be colored green.

    Check the table cells. All of the table cells in the Power and hostResponds columns should be solid green. If any are not, see the section in PSSP: Diagnosis Guide.


spmon Enter: 
spmon -d -G

Step 72: Verify node expansion configuration information (optional)

Use the splstdata -x command to verify that the connection information for an SP expansion I/O unit is correct. For example, issue: 

splstdata -x

|Step 73: Enable s1_tty on the SP-attached server (SAMI hardware protocol only)

If you just installed an SP-attached server, you must ensure that the s1_tty is enabled on the server. Until the login is enabled on the tty, the s1term command from the control workstation to the SP-attached server will not work.

On the SP-attached server, determine which tty is mapped to 01-S1-00-00. For example, issue the following: 

lsdev -C -c tty0

In response, the system displays something similar to: 

tty0 Available 01-S1-00-00 Asynchronous Terminal
tty1 Available 01-S2-00-00 Asynchronous Terminal

In the previous example, tty0 is mapped to 01-S1-00-00.

Set the login to enable. For example, issue the following: 

chdev -l tty0 -a login=enable

|Step 74: Update authorization files in restricted mode for boot/install servers (optional)

| | |

|Once the node is installed, or as part of firstboot.cust, |the remote command authorization files on the node serviced by the non-control |workstation boot/install server need to be updated |depending on the setting of auth_root_rcmd. Add the |following: |

|standard
|An entry for the boot/install server node host name in |/.rhosts

|k4
|An entry for the boot/install server node rcmd principal in |/.klogin |

|dce
|An entry for the self-host and the spbgroot principal |for the /.k5login boot/install server node |

Step 75: Run verification tests on all nodes

If you have set up system partitions, do this step in each partition.

This step directs you to run a series of verification tests that check for correct installation of your selected options on all the nodes.
If using: Do this:
Perspectives

SELECT
smit SP_verify on CWS from the Launch Pad.

From this point, you can follow the rest of the SMIT steps described in the next row of this table.


SMIT

TYPE
smit SP_verify
  • The RS/6000 SP Installation/Configuration Verification Menu appears.

SELECT
System Management

SYSMAN_test Enter: 
SYSMAN_test

After the tests are run, the system creates a log in /var/adm/SPlogs called SYSMAN_test.log.

See the section on "Verifying System Management installation" in PSSP: Diagnosis Guide if the verification test fails.

Step 76: Start the optional switch


If using: Do this:
Perspectives

SELECT
The smit cluster_mgmt icon
  • The SP Cluster Management menu appears.

SELECT
Perform Switch Operations

From this point, you can follow the rest of the SMIT steps described in the next row of this table.


SMIT

TYPE
smit switch_ops
  • The Perform Switch Operations menu appears.

SELECT
Start Switch

Estart Enter: 
Estart
If -p is not specified, the default behavior is to perform this action on all planes.

Step 77: Verify that the switch was installed correctly

Run a verification test to ensure that the switch is installed completely.
If using: Do this:
Perspectives

SELECT
smit SP_verify on CWS from the Launch Pad.

From this point, you can follow the rest of the SMIT steps described in the next row of this table.


SMIT

TYPE
smit SP_verify
  • The RS/6000 SP Installation/Configuration Verification Menu appears.

SELECT
The Communication Subsystem option

PRESS
Enter

CSS_test Enter: 
CSS_test

After the tests are run, the system creates a log in /var/adm/SPlogs called CSS_test.log.

If the verification test fails, see the section on "Diagnosing switch problems" in PSSP: Diagnosis Guide.

Check the switchResponds and powerLED indicators for each node.
If using: Do this:
Perspectives

SELECT
The Hardware Perspective icon by double clicking

SELECT
The Nodes Pane
  • The Nodes Pane receives focus.

SELECT
View > Set Monitoring
  • The Set Monitoring for Nodes dialog box appears.

SELECT
The switchResponds condition

PRESS
Apply
  • The nodes should now be colored green. Check the node icons. All node icons should be solid green. If they are not, refer to PSSP: Diagnosis Guide for further information.

spmon Enter: 
spmon -d -G

Step 78: Create DCE principals for the switch adapter host name (optional)

To allow k5 remote command operation between nodes on the switch adapter, additional DCE configuration is needed.

  1. You must be root to perform this task.
  2. All adapters must have an ftp and a host account defined in the DCE database.
  3. To add adapters to a DCE-configured node, perform the following steps:
    1. Login to the node or use dsh
    2. Run kerberos.dce -type local

Refer to IBM Distributed Computing Environment for AIX: Administration Commands Reference for more information on the kerberos.dce command.

Step 79: Tune the network adapters

Various models of the network adapters can have different values for transmit queue sizes. To get peak performance out of the network adapters, increase the transmit and receive queue sizes to their maximum. See Step 5: Tune all control workstation network adapters for valid queue size settings.

If the adapter you are changing is also the adapter for the network you are logged in through, you will have to make the changes to the database only. Then reboot the node for the changes to become effective.
If using: Do this:
Perspectives

SELECT
smit devices from the Launch Pad.
  • The Devices menu appears

From this point, you can follow the rest of the SMIT steps described in the next row of this table.


SMIT

TYPE
smit devices
  • The Devices menu appears

SELECT
Communication
  • The Communication menu appears

SELECT
The adapter you want to reset (for example, Ethernet Adapter)
  • The Ethernet Adapter menu appears

SELECT
Adapter
  • The Adapter menu appears

SELECT
Change / Show Characteristics of an Ethernet Adapter
  • An Ethernet Adapter window appears

SELECT
An adapter from the list shown
  • The Change / Show Characteristics of an Ethernet Adapter window appears

CHANGE
The HARDWARE TRANSMIT queue size. (See note 2 below.)

CHANGE
Apply change to DATABASE only to yes. (Press F4 and select yes.)

PRESS
Ok to apply the changes to the database.

chdev Enter 

chdev -P -l ent0 -a xmt_que_size=512
  1. You must reboot the node in order for the changes to take effect.
  2. To determine the name of the TRANSMIT queue size, issue: 
    lsattr -l adapter_name -E

    In response, a list of all of the values for the different variables, what they are, and the name of the variable will be displayed. In the previous example, an MCA adapter with AIX 4.2.1 or later was used.

|Step 80: Authorize the SP administrative principals for remote command access

| | |

|If you created an SP administrative principal in Step 22.3: Create SP administrative principals, you may also need to authorize that principal to remotely |run commands on nodes within the system. This is to ensure that SP |commands which both write to the SDR and remotely access the nodes (via AIX |and PSSP remote commands like dsh and rsh) are authorized to |perform such actions. The SP commands that require this type of |authorization include chauthpar, chauthpts, and |spsitenv.

|You must authorize the SP administrative principal to do remote commands by |adding it to the /.k5login file on the control workstation and |on the nodes. The entry format is: 

|principal@dce_cell_name
|Note:
|If you are running with a secure remote command method enabled, you |do not have to perform this task. See Step 30: Enter site environment information. |

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

| | | |

|Software maintenance (PTFs) may now be applied to the ssp and |rsct file sets installed on the nodes. If you installed |software maintenance to the control workstation in Step 27: Apply PSSP PTFs (optional), you must install the service updates to the nodes |now. Refer to Installing updates on a per node basis for detailed instructions.

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