Installation and Migration Guide

Step 39: Verify that the Ethernet addresses were acquired

This step verifies that Ethernet addresses were placed in the SDR node object.

If using:	Do this:
Perspectives	SELECT smit config_data on CWS from the Launch Pad The SP Configuration Database Management menu appears. SELECT List Database Information The List Database Information 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 list_data The List Database Information menu appears. SELECT List Node Database Information The List Node Database Information menu appears. SELECT List Node Boot/Install Information A window appears listing the node Ethernet information. TYPE The Start Frame, Start Slot, and Node Count OR Node Group OR Node List PRESS Ok
splstdata	Attention: If your system is large, splstdata returns great quantities of data. You may want to pipe the command output through a filter to reduce the amount of data you see. To display SDR boot/install data, enter: splstdata -b

Step 40: Configure additional adapters for nodes

Perform this step if you have a switch or if you require any additional adapters.

If you are configuring more than eight of one particular adapter type, you must change the ifsize parameter in the tuning.cust file.

Be sure to have your switch configuration worksheet on hand with all the switch information completed before attempting to perform this step. RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment explains how to fill out your worksheet.

This step creates adapter objects in the SDR for each node. The data in the adapter objects is used during the customization or installation steps to configure the adapters on the nodes. You can configure the following adapter types with this procedure:

• Ethernet (en)
• FDDI (fi)
• Token ring (tr)
• |css

To configure adapters such as ESCON and PCA, you must configure the adapter manually on each node, using dsh, or modify the firstboot.cust file.

Note:

Ensure that all additional adapters listed previously are configured before performing the following operations:

• Node installation
• mksysb install
• Node migration
• Node customization

During the preceding operations, psspfb_script is run which unconfigures and reconfigures all adapters found in the SDR. If additional adapters are not registered in the Adapter class of the SDR, they will not be configured after psspfb_script completes.

This requirement also includes any ATM LAN Emulator adapters that are defined as enX. Those adapters must also be defined in the SDR, otherwise psspfb_script will unconfigure them during the preceding operations.

Configuring the switch adapters

To configure your switch adapters for use with the RS/6000 SP system, use SMIT or issue the spadaptrs command. RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment contains additional information on IP addressing for the switch.

If using:	Do this:
Perspectives	SELECT smit config_data on CWS from the Launch Pad. The SP Configuration Database Management menu appears. SELECT Enter Database Information The Enter Database Information menu appears. SELECT Node Database Information The Node Database Information 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 node_data The Node Database Information menu appears. SELECT Additional Adapter Information The Additional Adapter Database Information window appears. TYPE The data in the fields. Refer to your worksheet as needed. PRESS Ok to store the data. PRESS Cancel to exit SMIT. The default css adapter attributes are: Skip IP Addresses for Unused Slots? no Enable ARP for the css Adapter? yes Use Switch Node Numbers for css IP Addresses? yes Note: The default is yes for SP Switch systems and no for SP Switch2 systems. If you want to select yes next to Skip IP Addresses for Unused Slots?, you must set the Use Switch Node Numbers to no. If you set the Use Switch Node Numbers to no, you must set Enable ARP to yes. Note: You cannot set Enable ARP to no with SP Switch2 systems. For css adapters, if you select yes next to Use Switch Node Numbers for css IP Addresses?, you must use the Start Frame, Start Slot, and Node Count fields. Start Slot must be set to 1. For css adapters, you must specify the adapter name, css0 or css1, in the Adapter Name field. Enter the following information for each consecutive block of nodes. Start Frame, Start Slot, and Node Count OR Node Group OR Node List Adapter Name (css0 or css1) Starting Node's IP Address or Hostname Netmask Token Ring Data Rate (required only when configuring a token-ring adapter.) Skip IP Addresses for Unused Slots? Enable ARP for the css Adapter? Use Switch Node Numbers for css IP Addresses? Starting Slot is always relative to the frame and not to the system. This means that the first slot in the second, third, and fourth frames is still slot 1 rather than slots 17, 33, and 49. For example, for the first frame you might enter: Start Frame 1 Start Slot 1 and for a second frame, you might enter: Start Frame 2 Start Slot 1 Node List is used to specify a group of node numbers separated by commas. Node numbers can be referenced for systems with more than one frame. (Node number 17 would be used for frame 2 slot 1.) For example: 1,5,7,9,15,17,19 You can also specify a file that contains a single line of data containing the node list, separated by commas. Enter the full-path name, unless the file is in your current directory. For example, if you have a list of nodes in /tmp/node_list, enter the following in the Node List field: /tmp/node_list
spadaptrs	This example adds SDR information for a css (SP Switch and SP Switch2) network of 30 nodes (frame 1 slot 1 to frame 2 slot 16, with a wide node as the first node in each frame and the rest thin nodes, and a switch on each frame) with IP addresses from 129.33.34.1 to 129.33.34.30, and a netmask of 255.255.255.0. The IP addressing corresponds to the slots in the frame, with each wide node incrementing by 2 and each thin node incrementing by 1, and each high node by 4. If you specify the -s flag to skip IP addresses when you are setting the css switch addresses, you must also specify -n no to not use switch numbers for IP address assignment, and -a yes to use ARP. spadaptrs -s yes -n no -a yes 1 1 30 css0 129.33.34.1 255.255.255.0

Note:

|On systems containing an SP Switch2, PSSP will only install the |ssp.css file set on nodes that have CSS switch adapters that |are defined in the SDR. Nodes with no CSS switch adapters defined in |the SDR will not have the ssp.css file set installed. |

Configuring other additional adapters

To configure other additional adapters, for example Ethernet (en), token ring (tr), or FDDI (fi), you must select the Additional Adapter Database Information. For these adapters you can select either the Start Frame, Start Slot, and Node Count fields, or the Node List field.

Notes:

1. When using the token ring (tr) adapter, you must select the token ring rate (4 MB or 16 MB).

2. To ensure proper operation, exit SMIT and return to the Additional Adapter panel for each different type of adapter. This clears any extraneous values left behind in the panel.

3. Enter a correct value for Ethernet speed (10, 100, 1000, or auto), Duplex (full, half, or auto), and Type (bnc, dix, tp, fiber, or NA) for every Ethernet adapter on each node.

4. |For pSeries 690 servers, specifying the adapter by its physical |location code and adapter type is suggested, especially if there is more than |one adapter of that type present in the node. The physical location |code for an adapter can be determined in one of the following ways: |
   • |Run the spadapter_loc command for the node. The command |will return a list of all of the SP supported adapters installed on the |node. If you ran this command as part of Step 37: Enter the required node information and saved the results of the command in a file, you may |already have this information available to you.
   • |Visually locate the adapter on your server and look up the physical |location code in the hardware publications distributed with the server.
   • |If AIX is installed and running on the server, run the AIX lscfg |-p command to list the physical location codes of all of the hardware |devices installed on your system. |

The distribution of your IP addresses determines how many times you perform this step. You may have to do it more than once if:

• There are gaps in your IP addresses not caused by wide nodes or high nodes or SP-attached servers.
• You want to set up alternate default routes or netmasks for certain IP address ranges

spadaptrs -s yes 1 1 30 fi0 129.33.34.1 255.255.255.0

spadaptrs -l 1 -r 16 tr0 129.33.35.1 255.255.255.0

spadaptrs -P U1.9-P2-I2/E4 -t tp -d auto -f auto 5 2 1 en \
          129.33.35.66 255.255.255.0

|Step 41: Configure the aggregate IP interface for nodes (SP Switch2 only)

|To use the ml0 interface for running jobs over the switch, use |Perspectives, SMIT, or issue the spaggip command.

|Note:

This step is optional for an SP Switch2 system. |

spaggip -i css0,css1 -1 7 9.114.66.20 255.255.255.0

|Step 42: Configure the number of switch planes (SP Switch2 only)

|You only need to perform this step if you are configuring more than one |plane on your system. The default is automatically set to one |plane. To configure an SP Switch2 |two plane system, use Perspectives, SMIT, or issue the spswplane |command. To check the number of planes defined, issue:

|splstdata -e

spswplane -p 2

Step 43: Configure initial host names for nodes

Do this step if:

• |You do not want the default host name to match the SP Ethernet |administrative LAN adapter name. The SP Ethernet administrative LAN |adapter name is the default.
• You are using short host names. The default is long host names.

This step changes the default host name information in the SDR Node Objects used during customization to set up the host name on each node, and allows you to indicate how you want to name your RS/6000 SP nodes. The default is the long form of the |SP Ethernet administrative LAN adapter host name, which is how the |spadaptrs command processes defaulted host names.

You can indicate an adapter name other than |the SP Ethernet administrative LAN for the node host names to be used, as well as whether the long or short form should be used. |When determining whether you want the nodes' host name to be |either in long or short form, be consistent with the host name resolution on |the control workstation. If the host command returns the short |form of a host name, you should choose the short form for the node's |initial host name.

Multibyte host names are not supported on the SP.

If using:	Do this:
Perspectives	SELECT smit config_data on CWS from the Launch Pad. The SP Configuration Database Management menu appears. SELECT Enter Database Information The Enter Database Information menu appears SELECT Node Database Information The Node Database Information menu appears SELECT Hostname Information From this point, you can follow the rest of the SMIT steps described in the next row of this table.
SMIT	TYPE smit node_data The Node Database Information menu appears. SELECT Hostname Information The Hostname Information window appears. TYPE Start Frame, Start Slot, Node Count OR Node List OR Node Group Also type the adapter name or adapter physical location for initial hostname and whether you are using short or long hostnames. PRESS Ok to store the data.
sphostnam	This command indicates that the host name of each node is the long (fully qualified) form of the host name of the css0 adapter, for a system with two frames and 32 nodes. sphostnam -a css0 1 1 32

RS/6000 SP security installation and configuration

The following list outlines the steps necessary to configure and customize the SP selected authentication and authorization methods:

• Select Security Capabilities Required on Nodes
• Create DCE hostnames
• Update SDR with DCE Master Security and CDS Server Hostnames
• Configure DCE Clients (Admin portion)
• Configure SP Trusted Services to use DCE authentication
• Create SP Trusted Services DCE Keyfiles
• Select Authorization Methods for AIX Remote Commands
• Enable Authentication Methods for AIX Remote Commands
• Enable Authentication Methods for SP Trusted Services

Step 44: Select security capabilities required on nodes

This step sets the security capabilities to be installed on the nodes. If dce is selected, the DCE file sets will be installed on the nodes, and the security, CDS, clients, and RPC will be configured and started. The DCE file sets must be located in /spdata/sys1/install/name/lppsource on the control workstation to be installed automatically.

If k4 is selected, various Kerberos V4 configuration files will be installed.

Note:

By default, AIX standard authentication is part of the AIX BOS and, therefore, no installation is required on the node.

spsetauth -p partition1 -i dce

Step 45: Create DCE hostnames (required for DCE)

If you selected DCE as an authentication method, you must set a DCE hostname for each node in the SDR. This step uses the nodes' reliable hostname as the DCE hostname if a DCE hostname does not already exist.

If using:	Do this:
SMIT	TYPE smit spauth_config The RS/6000 SP Security menu appears. SELECT Create DCE hostnames
create_dcehostname	For example, enter: create_dcehostname

Step 46: Update the SDR with DCE master security and CDS server hostnames (required for DCE)

This step updates the SDR with DCE master security and CDS server hostnames.

If using:	Do this:
SMIT	TYPE smit spauth_config The RS/6000 SP Security menu appears. SELECT Update SDR with DCE Master Security and CDS Server Hostnames The Update SDR with DCE Master Security and CDS Server Hostnames menu appears. SELECT Master Security Server hostname Enter the full name of the host containing your DCE Master Security Server. SELECT CDS Server hostname Enter the full name of the host containing your DCE Initial Directory Server.
setupdce	For example, enter: setupdce -u -s c186cw.pok.ibm.com -d c186cw.pok.ibm.com

Step 47: Configure admin portion of DCE clients (required for DCE)

This step configures the admin portion of DCE clients.

Note:

You will be prompted for the cell administrator password.

setupdce -c cell_admin -l /.:/lan_profile

Step 48: Configure SP Trusted Services to use DCE authentication (required for DCE)

This step configures SP Trusted Services into the DCE database. Data is entered into both the DCE registry and the Security Server database. You must have cell administrator authority to run this step.

This step creates SP Trusted Services principals and accounts. It uses the /usr/lpp/ssp/config/spsec_defaults and /spdata/sys1/spsec/spsec_overrides files described in Step 22.1: Update the spsec_overrides file (optional).

If using:	Do this:
SMIT	TYPE smit spauth_config The RS/6000 SP Security menu appears. SELECT Configure SP Trusted Services to use DCE Authentication
config_spsec	For example, enter: config_spsec -v Note: To run this command off of the SP, you must set the SP_NAME environment variable on a remote workstation to point to the SDR of the SP system being configured. Refer to the config_spsec command in PSSP: Command and Technical Reference for a description of the -r (remote) flag.

Step 49: Create SP Trusted Services DCE keyfiles (required for DCE)

Note:

You must be root on the control workstation with default credentials to perform this step.

This step creates SP Trusted Services keyfiles. It uses the /usr/lpp/ssp/config/spsec_defaults and /spdata/sys1/spsec/spsec_overrides files described in Step 22.1: Update the spsec_overrides file (optional).

If using:	Do this:
SMIT	TYPE smit spauth_config The RS/6000 SP Security menu appears. SELECT Create SP Trusted Services Keyfiles
create_keyfiles	For example, enter: create_keyfiles -v

After running the create_keyfiles command, you should reacquire SP administrative credentials as described in Step 24: Obtain credentials.

Step 50: Select authorization methods for AIX remote commands

This step sets the authorization methods that will be used for AIX remote commands. It also calls updauthfiles to update security-related files such as /.k5login, /.rhosts, and /.klogin (as appropriate).

|A new option of none has been added to this menu. If |none is selected, no other authorization methods can be selected at |the same time for the selected system partition. The none |option can be selected only if all nodes are at PSSP 3.4 or |later.

|To enable none on any system partition, the secure remote |command method must have been enabled on the Site Environment Menu along with |the required restricted root access enablement.

|When none is selected, no PSSP entries are automatically |put in the .k5login, .rhosts, and |.klogin files by updauthfiles to enable root remote |command access for that system partition. If none is chosen |for all system partitions, there will be no PSSP entries in these |files. If some system partitions have authorization methods for AIX |remote commands defined, the .k5login, |.rhosts, and .klogin files will be created for |each of the authorizations enabled.

|Boot/install server nodes still require the rsh or |rcp capability if they are not the control workstation to use NIM |services. If none is selected as the AIX authorization method |for remote commands, it will be up to the administrator to add the |authorization methods necessary for boot/install activities.

|GPFS, IBM Virtual Shared Disk, Problem Management, and some |LoadLeveler functions (for example, llctl -g start or llctl -h |start) will not function with none enabled.

|Note:

You must select at least one method in this step. |

spsetauth -d -p partition1 dce

Step 51: Enable authentication methods for AIX remote commands

This step enables the authentication methods that will be used for AIX remote commands.

Notes:

1. If the authentication methods enabled for use by SP Trusted Services includes DCE, the authentication methods enabled for use by the AIX remote commands must include Kerberos V5.

2. If the authentication methods enabled for use by SP Trusted Services includes compatibility, the authentication methods enabled for use by the AIX remote commands must include Kerberos V4.

chauthpar -c -p partition1 k5 std

Step 52: Enable authentication methods for SP Trusted Services

Note:

|You can skip this step if you only have AIX standard security |enabled. |

This step enables the authentication methods that will be used for SP Trusted Services.

If using:	Do this:
SMIT	TYPE smit spauth_config The RS/6000 SP Security menu appears. SELECT Enable Authentication Methods for SP Trusted Services The Enable Authentication Methods for SP Trusted Services menu appears. SELECT Enable on Control Workstation Only Set to yes to enable the control workstation only. Note: You cannot specify yes to both Enable on Control Workstation Only and Force change on nodes. SELECT Force change on nodes Set to no to not force a change on the nodes. SELECT System Partition name Press List (F4) then move the cursor to the desired system partition and press Enter. SELECT Authentication Methods Press List (F4) then select one or more authentication methods and press Enter.
chauthpts	For example, enter: chauthpts -c -p partition1 dce

Step 53: Start the key management daemon (required for DCE)

If you selected DCE as an authentication method and enabled DCE in the previous security steps, you must start the key management daemon on the control workstation. The key management daemon manages the DCE passwords associated with the SP Trusted Services. This daemon is started automatically on a node that is configured to use DCE authentication.

To start the key management daemon, issue:

/usr/lpp/ssp/bin/spnkeyman_start

Step 54: Add an extension node (optional)

At this point, you can optionally add an extension node to your system. Refer to Chapter 10, Installing extension nodes for more information.

|Step 55: Start RSCT subsystems

The PSSP installation code sets up a single default system partition that includes all nodes in the system. This system partition is created automatically and is called the |default partition because it always exists, even on a system that |cannot be partitioned.

At this time you need to add and start the |RSCT subsystems. Topology Services (hats), host response (hr) are examples of |RSCT subsystems. |RSCT subsystems are managed by the syspar_ctrl command and are listed in the file /usr/lpp/ssp/config/cmi/syspar_subsystems. For a more complete description of |RSCT subsystems, refer to the "Managing system partition-sensitive subsystems using syspar_ctrl" section in PSSP: Administration Guide.

If using:	Do this:
Perspectives	SELECT syspar_ctrl -A from the Launch Pad. The syspar_ctrl -A command is run.
syspar_ctrl	syspar_ctrl -A

|Step 56: Verify that RSCT subsystems have started

If using:	Do this:
Perspectives	SELECT syspar_ctrl -E from the Launch Pad. The syspar_ctrl -E command is run.
syspar_ctrl	Enter: syspar_ctrl -E

Before continuing with the install, verify that the following subsystems have been started and have an "active" state.

• haem
• hags
• hats
• hr

To see if these subsystems have been successfully started, issue the following command:

lssrc -a | grep default_syspar_name

For example, if your default system partition name is k22s, issue:

lssrc -a | grep k22s

The preceding command returns the following output:

hags.k22s        hags             17134   active
hats.k22s        hats             22266   active
hr.k22s          hr               18228   active
haem.k22s        haem             21128   active
hagsglsm.k22s    hags             21338   active
haemaixos.k22s   haem             41000   active
Emonitor.k22s    emon                     inoperative

To continue with the install, the subsystems hags, hats, hr, and haem should all be active. If the subsystems are inactive, they should become active in a few minutes. Wait 3 minutes and check again.

If a single subsystem is inactive, simply try starting that particular subsystem by issuing:

syspar_ctrl -s subsystem_name

For example, if the subsystem is hags, issue:

syspar_ctrl -s hags

If more than one subsystem is inactive, stop and delete all of the |RSCT subsystems by issuing:

syspar_ctrl -D

Then try to add and start all of the |RSCT subsystems by issuing:

syspar_ctrl -A

If you still have inactive |RSCT subsystems, refer to PSSP: Diagnosis Guide for further information.

Step 57: Set up nodes to be installed

• Do this step if you want to change the default installation settings for any of the nodes. To find out the default settings of your nodes, use the splstdata command.
• Be aware that the root password is not set if you are installing from a minimal mksysb. For more information on setting a root password when installing from a minimal mksysb, refer to Step 61: Perform additional node customization.
• If the boot/install server will be forwarding packets from the control workstation to a client node, the boot/install server is acting as a gateway to the control workstation. Therefore, ipforwarding must be correctly enabled. To turn ipforwarding on, issue:

  /usr/sbin/no -o ipforwarding=1
  

• You cannot export /usr or any directories below /usr because an NFS export problem will occur.

  If you have exported the /spdata/sys1/install/image directory or any parent directory, you must unexport it using the exportfs -u command before running setup_server. You need to do this because NIM attempts to export /spdata/sys1/install/images/bos.obj.ssp.*, where bos.obj.ssp.* is the install image during setup_server processing. If you do not perform this task, you will receive an error. See the "Diagnosing NIM problems" chapter in PSSP: Diagnosis Guide for more information.

• Everything that is required in PSSP is installed on the nodes automatically, regardless of whether you use your own mksysb or the SP minimal mksysb.

This step does the following:

• Changes the default boot/install information for the node objects in the SDR so that you can indicate a different boot/install server configuration to the RS/6000 SP system
• Allows you to specify an alternate disk or disks to use when installing AIX on nodes

|Using multiple boot/install servers

|The default installation assumes one of the following: |

• |You have fewer than 40 nodes and the control workstation is configured to |act as the boot/install server.
• |You have more than 40 nodes, the control workstation and the first node in |each frame is configured to act as the boot/install server. |

|Note:

|Do not install cascading levels of boot/install servers. |

|You should establish an administrative principal that has the following |capabilities from the control workstation to the boot/install server nodes to |run commands such as spdelnode: |

• |Root authority on the control workstation
• |SP Trusted Services capability including hardmon
• |Remote command capability |

|If you want different nodes to be installed by a different boot/install |server, you must specify the target nodes and which node will serve as the |boot/install server. For example, the first node of your second frame, |node 17, will be a boot/install server for the remaining 15 nodes in the |second frame. Use the spchvgobj command to enter this |information into the SDR. The syntax used in the example specifies a |start frame of 2, a starting slot of 2, and a count of 15 nodes. |Perspectives or SMIT can also be used, as shown in the table at the end of |this step.

|spchvgobj -r selected_vg -n 17 2 2 15

|After network installation is complete, if you have restricted root access |(RRA) enabled, you must perform the following steps:

|On the boot/install server node, you need to edit |/etc/sysctl.conf to include the following entries: |

• |Include /usr/lpp/ssp/sysctl/bin/install.cmds
• |Include /usr/lpp/ssp/sysctl/bin/switch.cmds
• |Include /usr/lpp/ssp/sysctl/bin/firstboot.cmds, if |initiating a node install customization |

|Using multiple boot/install servers in RRA is not recommended and is not |automatically supported by PSSP. However, depending on the size of your |system and network loads, it may not be possible to install your system with a |single boot/install server.

|Boot/install servers are NIM masters and, therefore, require rsh |and rcp access to both the control workstation and to the nodes they |serve. PSSP will not automatically create the correct entries in the |authorization files to allow these commands to work.

|To use additional boot/install servers, follow the following procedure to |manually establish the correct authorizations on your system.

|On the control workstation, the authorization files must have the following |changes, depending on the setting of auth_root_rcmd: |

|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 boot/install |server node in /.k5login |

|Specifying your own image

|The default installation assumes your nodes have not been |preinstalled. If you want to have them installed with your own install |image, you must specify the following: |

• |Which nodes you are installing with your own install image
• |The name of the installation image you are using if you do not want to use |the default image. |

Selecting an installation disk

There are |five ways you can specify the disk or disks to use for installation.

1. The hardware location format

   IBM strongly suggests that you use this format |for SCSI devices. It ensures that you install on the intended disk by targeting a specific disk at a specific location. The relative location of hdisks can change depending on the hardware installed or possible hardware failures. You should always use this format when there are external disk drives present, because the manner in which the device names are defined may not be obvious. For example, to specify a single SCSI drive, enter:

   00-00-00-0,0
   

   or enter multiple hardware locations separated by colons:

   00-00-00-0,0:00-00-00-1,0
   

2. The device names format

   For example, to specify a single device name, enter:

   hdisk0
   

   or enter multiple device names separated by commas:

   hdisk0,hdisk1
   

3. |A combination of the parent and connwhere attributes for SSA devices

   |To specify the parent-connwhere attribute:

   |ssar//0123456789ABCDE

   |or to specify multiple disks, separate using colons as follows:

   |ssar//0123456789ABCDE:ssar//0123456789ABCDE

   |The parent-connwhere format should only be used for SSA drives.

   |For more information on acquiring ssar numbers, see AIX Kernel and |Subsystems Technical Reference, Volume 2.

4. |The PVID format

   |If a disk was previously configured as a physical volume in order for it to |be assigned to a volume group, a physical volume identifier (PVID) was |assigned to that disk by AIX. You can specify a disk by its PVID value |as a string of 16 hexadecimal characters. For example:

   |00d4c45202be737f

   |To specify multiple disks by their PVID values, separate the specifications |using colons:

   |00d4c45202be737f:00d4c452eb639a2c

   |Use the AIX lspv command to list the PVID values for the disks on |your system. For more information on making an available disk a |physical volume and setting its PVID, see AIX System Management |Guide: Operating System and Devices.

5. |The SAN target and logical unit identifier format

   |Fibre channel attached disks are identified by a worldwide port name and a |logical unit identifier (LUN ID). To specify the SAN_DISKID, combine |the two values into a single string separated by "//". For example, if |the SAN target worldwide port name for a fibre channel attached disk is |0x50060482bfd12c9c and the LUN ID is 0x8000000000000000, the SAN_DISKID |specification would be:

   |0x50060482bfd12c9c//0x8000000000000000

   |To specify multiple fibre channel disks, separate the specifications using |colons:

   |0x50060482bfd12c9c//0x8000000000000000:0x50060482bbffd7cb//0x0

   |Use the AIX lsattr -EH -l hdisk command to determine the |worldwide port name and LUN ID for a disk.

|The hardware location, SSA parent-connwhere, PVID, and SAN_DISKID |formats can be used together. Specify multiple mixed format disk values |using colons to separate the specifications as follows:

00-00-09-0,1:ssar//0123456789ABCDE:00d4c45202be737f

|The device names format cannot be combined with any of the other |format types.

For more information on alternate root volume groups, see the "Managing root volume groups" appendix in PSSP: Administration Guide.

Note:

|The AIX alt_disk_install function is not related to the SP |alternate root volume group support and is not supported with PSSP |installation. |

Mirroring the root volume group

One way to significantly increase the availability of the SP system is to set up redundant copies of the operating system on different physical disks using the AIX disk mirroring feature. Mirroring the root volume group means that there will be multiple copies of the operating system image available to a workstation or node. Mirrored system images are distributed so that a node can remain in operation even after one of the mirrored units fail.

When installing a node, you have a choice of how many copies of the root volume group you would like. AIX allows one (the original), two (the original plus one), or three (the original plus two) copies of a volume group. IBM strongly suggests that the root volume group be mirrored for a total of at least two copies. PSSP provides commands to facilitate root volume group mirroring.

You can specify how many copies and which disks to use with the spchvgobj command. Care should be taken when specifying disks so that no other single point of failure is introduced. For example, the specified disks should not be attached to the same adapter.

The default setting for the number of copies is based on the node type. The default is one copy for all nodes except the POWER3 Symmetric Multiprocessor (SMP) High Node, which has a default of two copies. These nodes are assumed to contain dual internal disk drives as a standard configuration. The disks will automatically be used for mirroring. If these nodes were not configured with the dual internal disks or you do not want mirroring, use the spchvgobj command to change the settings before installing the node.

For a complete description of how mirroring is handled by PSSP, see the "Managing root volume groups" appendix in PSSP: Administration Guide.

|Changing volume group information in the SDR

|Change the default volume group information in the SDR to specify a |different boot/install server, your own installation image, a different target |installation disk or disks, or mirror root volume groups.

If using:	Do this:
Perspectives	SELECT smit config_data on CWS from the Launch Pad. The SP Configuration Database Management menu appears. SELECT Enter Database Information The Enter Database Information menu appears SELECT Node Database Information The Node Database Information 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 node_data The Node Database Information menu appears. SELECT Change Volume Group Information The Change Volume Group Information window appears. TYPE The data in the fields. Refer to your worksheet as needed. In addition to the node range, you must supply the boot/install server node identifier. If you are not using the default image, you must supply the network install image name. If your AIX lppsource name is "default", you must enter the correct name in the lppsource field (for example, aix433 or aix51). See Step 12: Create the required /spdata directories. To specify an alternate installation disk or disks, fill in the Physical Volume List field, using device names. PRESS Ok to store the data. The distribution of the nodes to be served and the number of different servers you want determines how many times you must perform this step. You may have to do it more than once if you want to define more than one server for different groups of nodes.
spchvgobj	You can use the spchvgobj command using the hardware location format for disk locations 00-07-00-0,0 and 00-07-00-1,0 for node 9 and set the number of copies to two. For example: spchvgobj -r selected_vg -h 00-07-00-0,0:00-07-00-1,0 -1 9 -c 2 If you need to change the lppsource_name from default to a new lppsource_name such as aix433 for nodes 1 through 16, issue: spchvgobj -r selected_vg -v aix433 1 1 16 If you need to change the install_image_name from default to a new install_image_name such as bos.obj.ssp.433 for nodes 17, 18, 21, 22, issue: spchvgobj -r selected_vg -i bos.obj.ssp.433 -v aix433 -l 17,18,21,22

Step 58: Verify all node information

This step verifies that all the node information has been correctly entered into the SDR.

If using:	Do this:
Perspectives	SELECT smit config_data on CWS from the Launch Pad. The SP Configuration Database Management menu appears. SELECT List Database Information. From this point, you can follow the rest of the SMIT steps described in the next row of this table.
SMIT	Check each of the List Database panels for correct information. If you find any incorrect data, return to the following steps to make corrections: Data Step Frame data Step 32: Enter SP or multiple NSB frame information and reinitialize the SDR Node data Step 37: Enter the required node information Additional adapters Step 40: Configure additional adapters for nodes TYPE smit list_data The List Database Information window appears. SELECT Each panel listed. Verify all information is correct. PRESS Done to exit SMIT.
splstdata	To display SDR: Enter: Site environment data splstdata -e Frame data splstdata -f Node data splstdata -n Adapter data splstdata -a Boot/install data splstdata -b SP expansion I/O data splstdata -x SP security settings splstdata -p Switch data splstdata -s
If your system is large, splstdata returns great quantities of data. You may want to pipe the command output through a filter to reduce the amount of data you see.

Step 59: Verify extension node information

At this point, you can optionally verify extension node information. Refer to Chapter 10, Installing extension nodes for more information.