IBM Books

Command and Technical Reference, Volume 2

sysparaid

Purpose

sysparaid - Creates a layout for a new system partition configuration of an SP system.

Syntax

sysparaid
[-h] [ -i] [-s layout_name | a_fully_qualified_path]
 
[-t tmpdir] input_file [topology_file]

Flags

-h
Displays usage information. If the command is issued with the -h flag, the syntax description of the command and the startup guidelines are displayed to standard output and no other action is taken (even if other valid flags are entered along with the -h flag).

-i
Creates a switch-map file (spa.sysinfo) for the current SP system if a System Data Repository (SDR) is present. If an SDR is not available, it will generate the file for the system described by the topology_file . If the -s flag is entered along with the -i flag, it will be ignored.

-s
Saves the newly generated layout in the system partition directory tree (/spdata/sys1/syspar_configs/...) if a layout_name is specified; otherwise, it will be saved under the directory specified by the fully qualified path given.

-t
Saves the snapshot, performance, and intermediate files under tmpdir.

Operands

input_file
Specifies the file containing the system partition configuration requirement.

topology_file
Specifies the topology file for the system to be partitioned. This operand is required only when the topology file for the system to be partitioned is not under /spdata/sys1/syspar_configs/topologies . It is also required with the -i flag when there is no SDR or when the switch-map file for a system not represented by the SDR is desired.

Description

Use this command to invoke the System Partitioning Aid, a tool for generating new system partition configuration layouts. |The sysparaid command is not valid on a system with an SP |Switch2 switch or on a switchless clustered enterprise server |system.

When invoked with the -i flag, it creates a switch-map file that will help the user to generate the input_file for creating a layout for a desired system partition configuration. When invoked with no flags or with the -s or -t flags, it attempts to partition the system according to the input requirement. If the attempt is unsuccessful, it will output appropriate error messages to the log and exit. If the attempt is successful and the -s flag is specified, the newly created layout will be saved at the desired location specified by the flag argument.

Prerequisite Information

The sysparaid command uses a set of built-in rules to create a layout for a desired system partition configuration. The following startup guidelines will help to generate an acceptable input to the command:

  1. The nodes can be identified by either using node_numbers or switch_port_numbers. While both schemes are permitted for partitioning a system defined by an SDR, switch_port_numbers is the only allowed choice when running the tool without an SDR. Also, the numbering schemes cannot be mixed when both schemes are allowed.
  2. Identify the four nodes linked to any switch chip to place them in the same system partition. If an SDR is present, the identity of the switch chips linked to the nodes in the system can be obtained by issuing the following command:
    sysparaid -i -t spa_dir
    

    This command places a spa.sysinfo file in the spa_dir if the -t flag is used; otherwise, it places it in the current directory. If an SDR is not present, issue the following command:

    sysparaid -i -t spa_dir topology_file
    

    where topology_file is the name of the topology file for the system to be partitioned.

    Note:
    In this case, only the switch_port_numbers are provided. No node_numbers are available.
  3. The keyword "remaining_nodes" can be used for the last system partition provided all nodes or switch ports not in the last system partition were placed in other system partitions. Therefore, the keyword cannot be used with the node_number numbering scheme for systems with empty input switch ports.
  4. Nodes on a switch board can be part of a maximum of two multichip system partitions.
  5. The input file must be formatted according the the template provided in /spdata/sys1/syspar_configs/bin/inpfile_template.

Standard Input

This command requires an input file when invoked with no flag or the -s flag. The template for the input file can be found in /spdata/sys1/syspar_configs/bin .

Standard Output

Informational messages are written to standard output.

Standard Error

Error messages are written to standard error.

Output Files

This command creates spa.snapshot and spa.metrics under tmpdir (if specified) or under the current working directory. If the -s flag is specified and the attempt is successful, it creates the following under the layout directory:

layout.desc
spa.snapshot
nodes.syspar and a system partition directory for each system partition in the layout. Under each system partition directory, it creates the following:
node list
topology
spa.snapshot
spa.metrics

When invoked with the -i flag, the command creates spa.sysinfo under tmpdir (if specified), or under the current working directory.

Security

Any user can run this command. Only users authorized to write to the system partitioning directory can save a generated layout under it.

Location

/usr/lpp/ssp/bin/sysparaid

Related Information

The spsyspar command provides the graphical user interface (GUI) for the System Partitioning Aid.

Examples

  1. The following is an example of an input file with the switch port number option (all switch ports linked to nodes):
    Number of Nodes in System: 32
    Number of Frames in System: 2
    Frame Type: tall
    Switch Type: HiPS
    Number of Switches in Node Frames: 2
    Number of Switches in Switch Only Frames: 0
    Node Numbering Scheme: switch_port_number
    Number of Partitions: 3
    Partition Name: part1
    Number of Nodes in Partition: 8
    0 - 7
    Partition Name: part2
    Number of Nodes in Partition: 8
    8 - 15
    Partition Name: part3
    Number of Nodes in Partition: 16
    remaining_nodes
    

    To use /tmp as the working directory, enter:

    sysparaid -t /tmp inpfile
    

    You should receive a message similar to the following:

    A layout, for the desired system partition configuration or an
    equivalent, can be created.
    To save this layout, invoke the command again with -s option.
    

    To save the layout for this configuration under /spdata/sys1/syspar_configs/2nsb0isb/config.8_8_16/layout.myconfig, enter:

    sysparaid -s myconfig inpfile
    

    To save the layout for this configuration under /tmp/custom/config1, enter:

    sysparaid -s /tmp/custom/config1 inpfile
    
  2. The following is an example of an input file with the switch port number option (not all switch ports in the system are linked to nodes):
    Number of Nodes in System: 87
    Number of Frames in System: 6
    Frame Type: tall
    Switch Type: SP
    Number of Switches in Node Frames: 6
    Number of Switches in Switch Only Frames: 4
    Node Numbering Scheme: switch_port_number
    Number of Partitions: 2
    Partition Name: ProductionPartition
    Number of Nodes in Partition: 82
    0
    4
    16 - 95
    Partition Name: TestPartition
    Number of Nodes in Partition: 5
    2
    6
    8
    10
    12
    

    If you enter the sysparaid -s myconfig inpfile command, this configuration will be saved under /spdata/sys1/syspar_configs/6nsb4isb/config.12_84/layout.myconfig. Note that the nine unspecified switch port numbers have been allocated to one of the two system partitions.

  3. The following is an example of an input file with the node number option (not all switch ports are linked to nodes):
    Number of Nodes in System: 8
    Number of Frames in System: 2
    Frame Type: tall
    Switch Type: SP
    Number of Switches in Node Frames: 1
    Number of Switches in Switch Only Frames: 0
    Node Numbering Scheme: node_number
    Number of Partitions: 3
    Partition Name: part1
    Number of Nodes in Partition: 2
    25
    29
    Partition Name: part2
    Number of Nodes in Partition: 4
    1
    5
    17
    21
    Partition Name: part3
    Number of Nodes in Partition: 2
    3
    7
    

    This input file for a particular SP system returned the location of an existing layout:

    The layout for the desired/equivalent system partition configuration is
    under /spdata/sys1/syspar_configs/1nsb0isb/config.4_4_8/layout.2
    
  4. The spa.sysinfo file for the system in Example 3 that was generated using the sysparaid -i command follows:
    switch_number   switch_chip   switch_port_number   node_number
          1              4                  9              25
          1              4                 13              29
          1              5                  0               1
          1              5                  1              17
          1              5                  4               5
          1              5                  5              21
          1              6                  2               3
          1              6                  6               7
    
  5. The following is an example of an input file for a switchless system:
    Number of Nodes in System: 32
    Number of Frames in System: 2
    Frame Type: tall
    Switch Type: NA
    Number of Switches in Node Frames: 0
    Number of Switches in Switch Only Frames: 0
    Node Numbering Scheme: switch_port_number
    Number of Partitions: 2
    Partition Name: part1
    Number of Nodes in Partition: 14
    2 - 5
    10
    11
    13
    15
    19
    24 - 25
    29 - 31
    Partition Name: partition2
    Number of Nodes in Partition: 18
    remaining_nodes
    

    To save the layout for this configuration under /spdata/sys1/syspar_configs/2nsb0isb/config.14_18/layout.myconfig, enter:

    sysparaid -s myconfig inpfile
    

s1term

Purpose

s1term - Opens a connection to an SP node's S1 serial port.

Syntax

s1term [-G] [-w] frame_ID slot_ID

Flags

-G
Allows specification of nodes outside the current system partition.

-w
Opens the connection in read/write mode.

Operands

frame_ID
Specifies the number of the frame containing the node.

slot_ID
Specifies the number of the slot containing the node.

Description

Use this command to open a connection to the S1 serial port of the SP node contained in the slot specified by the frame_ID and slot_ID operands. The specified node must be in the current system partition unless the -G flag is also specified. By default, the connection is read only. As data arrives from the serial port, it is written to standard output. When the connection is read/write and standard input is a terminal, the terminal is placed in raw mode, that is, canonical processing is turned off in the terminal driver. As data is read from standard input, it is sent to the S1 serial port. Standard input and output can be files or pipes.

When the connection is read only, the command terminates upon receipt of a signal, usually generated by the terminal Interrupt key. When in read/write mode, the command terminates when either the termination character or End-of-File is read from standard input. The termination character is Ctrl-x by default. Another termination character can be used by setting the S1TERMESC environment variable to the octal (denoted by leading 0), decimal or hexadecimal (denoted by leading 0x) value of the desired termination character.

Note:
The termination character must only be one byte.

To execute this command, the user must be authorized to access the Hardware Monitor subsystem and, for the frame specified to the command, must be granted S1 permission. Since the Hardware Monitor subsystem uses SP authentication services, the user must execute the k4init command prior to executing this command. Alternatively, site-specific procedures can be used to obtain the tokens that are otherwise obtained by k4init.

|If you currently have a virtual terminal (vterm) session open |through the Hardware Management Console (HMC) interface, the s1term |command will fail when opening a console session to an IBM e(logo)server |pSeries 690 server or logical partition (LPAR). Close all HMC vterm |sessions before running this command.

Security

To execute the s1term command, you must be authorized to access the Hardware Monitor subsystem and must be granted "S1" permission for the hardware objects (frames, slots) specified in the command. Commands sent to hardware objects for which the user does not have "S1" permission are ignored.

Location

/usr/lpp/ssp/bin/s1term

Related Information

Commands: hmcmds, hmmon

Examples

  1. To open an interactive connection to the S1 serial port of the node in slot 8 in frame 12, enter:
    s1term -w 12 8
    
  2. To write the output of the S1 serial port of the node in slot 2 in frame 9 to a file, enter:
    s1term 9 2 > s1term.output
    

tecad_pssp

Purpose

tecad_pssp - Forwards PSSP events.

Syntax

tecad_pssp
[-l path/filename] [-Cc]
 
[-m text] [-a tiv_admin_name]
 
[-s severity] [-p port]

Flags

-l path/filename
Specifies the path/filename of the configuration file. The default value is /usr/lpp/ssp/donfig/tecad_pssp.cfg. The only required value in this file is the ServerLocation parameter, which should be one of the following:

Consult the TME 10 EIF User's Guide for the correct values of the other configuration parameters.

-C
Specifies the connection-oriented protocol.

-c
Specifies a connectionless protocol (the default).

-m text
Adds text to the message field of the event.

-a tiv_admin_name
Adds admin in the T/EC_administrator field of the event.

-s severity
Sets the severity of the event to severity. The following strings are the legal values for severity:

 
FATAL

 
CRITICAL

 
WARNING

 
MINOR

 
HARMLESS

If an incorrect value is used, the default UNKNOWN is used.

-p port
Sets the communication port number to port. Note that you can also set the port number in the configuration file.

Operands

None.

Description

The tecad_pssp command was designed to be executed by the PSSP Problem Management subsystem. It should not be executed by any other subsystem, since it depends on environment variables that are exported by the Problem Management daemon, pmand. Therefore, to forward PSSP events using the tecad_pssp command, you need to make a Problem Management subscription using either the SP Event Perspective, or using Problem Management directly. In either case, you should select tecad_pssp as the command to run for that subscription, and provide the appropriate parameters.

Prerequisite Information

Integrating TME 10 on the RS/6000 SP

Location

/usr/lpp/ssp/tecad_pssp

Related Information

Commands: pmandef, wtdumprl

Examples

This example creates event subscriptions using the pmandef command:

pmandef -s example1
        -e "AnyResourceVariable;Any InstanceVector;AnyPredicate"
        -c "$AGENT_PATH/tecad_pssp -l $CONF_PATH/tecad_pssp.cfg"
        -r "AnyRearmPredicate"
        -C "$AGENT_PATH/tecad_pssp -l $CONF_PATH/tecad_pssp.cfg"
        -n 0

ucfghsd

Purpose

ucfghsd - Makes a hashed shared disk unavailable.

Syntax

ucfghsd {-a | hsd_name...}

Flags

-a
Specifies that all the hashed shared disks defined are to be unconfigured.

Operands

hsd_name
Specifies the name of a specific hashed shared disk that is unconfigured.

Description

This command unconfigures the already defined hashed shared disks. This command does not change the definition of the hashed shared disks; it makes the hashed shared disks unavailable on one node.

Security

You must be in the AIX bin group to run this command.

Prerequisite Information

PSSP: Managing Shared Disks

Location

/usr/lpp/csd/bin/ucfghsd

Related Information

Commands: cfghsd, defhsd, hsdatalst, lshsd, undefvsd

Examples

To unconfigure the hashed shared disk hsd1, enter:

ucfghsd hsd1
 

ucfghsdvsd

Purpose

ucfghsdvsd - Stops the virtual shared disks that comprise a hashed shared disk and makes the hashed shared disk and the virtual shared disks unavailable.

Syntax

ucfghsdvsd -a | {hsd_name...}

Flags

-a
Specifies that all the hashed shared disks defined on this system or system partition are to be unconfigured.

hsd_name
Specifies the names of defined hashed shared disks that are to be unconfigured. This command unconfigures the underlying virtual shared disks as well.

Operands

None.

Description

Use this command to unconfigure hashed shared disks and their underlying virtual shared disks. This command does not change the definition of the hashed shared disks and virtual shared disks; it just makes them unavailable to the node on which this command is run. The underlying virtual shared disks do not have to be in the stopped state for this command to work. The virtual shared disks will be stopped and then unconfigured.

You can use the System Management Interface Tool (SMIT) to run this command. To use SMIT, enter:

smit hsd_mgmt

and select the Unconfigure an HSD and its Underlying Virtual Shared Disks option.

Security

You must have access to the virtual shared disk subsystem via the sysctl service to run this command.

Prerequisite Information

PSSP: Managing Shared Disks

Location

/usr/lpp/csd/bin/ucfghsdvsd

Related Information

Commands: cfghsdvsd, ucfghsd, ucfgvsd

Examples

To unconfigure the hashed shared disk hsd1 and the virtual shared disks that comprise it, enter:

ucfghsdvsd hsd1

ucfgvsd

Purpose

ucfgvsd - Makes a virtual shared disk unavailable.

Syntax

ucfgvsd {-a | vsd_name ...}

Flags

-a
Specifies that all virtual shared disks in the stopped state are to be unconfigured.

Operands

vsd_name
Specifies a virtual shared disk.

Description

The ucfgvsd command unconfigures the specified virtual shared disks. This command does not change any virtual shared disk definitions. It moves virtual shared disks from the stopped state to the defined state.

If a configured hashed shared disk is using this virtual shared disk, you must first unconfigure the hashed shared disk before you unconfigure the virtual shared disk.

You can use the System Management Interface Tool (SMIT) to run this command. To use SMIT, enter:

smit vsd_mgmt

and select the Unconfigure a Virtual Shared Disk option.

Security

You must be in the AIX bin group to run this command.

Restrictions

If you have the Recoverable Virtual Shared Disk software installed and operational, do not use this command. The results may be unpredictable.

See PSSP: Managing Shared Disks.

Prerequisite Information

PSSP: Managing Shared Disks

Location

/usr/lpp/csd/bin/ucfgvsd

Related Information

Commands: cfgvsd, ctlvsd, lsvsd, preparevsd, resumevsd, startvsd, stopvsd, suspendvsd

Examples

To unconfigure the virtual shared disk vsd1vg1n1 in the stopped state, enter:

ucfgvsd vsd1vg1n1

unallnimres

Purpose

unallnimres - Deallocates Network Installation Management (NIM) resources from a NIM master to one or more NIM clients.

Syntax

unallnimres -h | -l node_list

Flags

-h
Displays usage information. If the command is issued with the -h flag, the syntax description is displayed to standard output and no other action is taken (even if other valid flags are entered along with the -h flag).

-l node_list
Indicates by node_list the SP nodes to which to unallocate installation resources. The node_list is a comma-separated list of node numbers.

Operands

None.

Description

Use this command to unallocate all NIM resources from a NIM client.

|Environment Variables

|PSSP 3.4 provides the ability to run commands using secure remote |command and secure remote copy methods.

|To determine whether you are using either AIX rsh or rcp |or the secure remote command and copy method, the following environment |variables are used. |If no environment variables are set, the defaults are |/bin/rsh and /bin/rcp.

|You must be careful to keep these environment variables consistent. |If setting the variables, all three should be set. The DSH_REMOTE_CMD |and REMOTE_COPY_CMD executables should be kept consistent with the choice of |the remote command method in RCMD_PGM: |

|For example, if you want to run unallnimres using a secure remote |method, enter:

|export RCMD_PGM=secrshell
|export DSH_REMOTE_CMD=/bin/ssh
|export REMOTE_COPY_CMD=/bin/scp

Standard Error

This command writes error messages (as necessary) to standard error.

Exit Values

0
Indicates the successful completion of the command.

-1
Indicates that an error occurred.

Security

You must have root privilege to run this command.

Implementation Specifics

This command is part of the IBM Parallel System Support Programs (PSSP) Licensed Program (LP).

Location

/usr/lpp/ssp/bin/unallnimres

Related Information

Commands: allnimres, setup_server

Examples

To unallocate boot/installation resources to boot/install client nodes 1, 3, and 5 from their respective boot/install servers, enter:

unallnimres -l 1,3,5
 

undefhsd

Purpose

undefhsd - Undefines a hashed shared disk.

Syntax

undefhsd hsd_name...

Flags

None.

Operands

hsd_name
Specifies the unique name defined in the SDR names that you want to delete.

Description

This command is used to remove a hashed shared disk by removing its definition from the system, including the special device files in /dev . The hashed shared disks must be unconfigured and in the defined state on all nodes in the system partition.

You can use the System Management Interface Tool (SMIT) to run this command. To use SMIT, enter:

smit delete_vsd

and select the Undefine a Hashed Shared Disk option.

Security

You must be in the AIX bin group and have write access to the SDR to run this command.

Prerequisite Information

PSSP: Managing Shared Disks

Location

/usr/lpp/csd/bin/undefhsd

Related Information

Commands: defhsd, hsdatalst

Examples

To delete the information associated with the hashed shared disk hsd1 from the SDR, enter:

undefhsd hsd1

undefvsd

Purpose

undefvsd - Undefines a virtual shared disk.

Syntax

undefvsd vsd_name ...

Flags

None.

Operands

vsd_name
Specifies the virtual shared disk whose underlying logical volume you no longer want to be globally accessed by any virtual shared disk nodes.

Description

This command is used to remove virtual shared disk definition data from the System Data Repository (SDR) and any special device files from /dev for the given vsd_names on all the virtual shared disk nodes. The virtual shared disks must be unconfigured and in the defined state on all the virtual shared disk nodes.

You can use the System Management Interface Tool (SMIT) to run the undefvsd command. To use SMIT, enter:

smit delete_vsd

and select the Undefine a Virtual Shared Disk option.

Security

You must be in the AIX bin group to run this command.

You must have write access to the SDR to run this command.

Prerequisite Information

PSSP: Managing Shared Disks

Location

/usr/lpp/csd/bin/undefvsd

Related Information

Commands: defvsd

Examples

To delete the information associated with the virtual shared disk vsd1vg2n1 from the SDR, enter:

undefvsd vsd1vg2n1

unfencevsd

Purpose

unfencevsd - Gives applications running on a node or group of nodes access to a virtual shared disk or group of virtual shared disks that were previously fenced from applications running on those nodes.

Syntax

|unfencevsd {-a | -v |vsd_name_list} {-n node_list |[-f] | -r}

Flags

|-a
|Specifies all virtual shared disks.

|-f
|Allows a fenced node to unfence itself.

|-n node_list
|Specifies one or more node numbers separated by commas.

|-r
|Removes records associated with virtual shared disks listed in |vsd_name_list from the System Data Repository (SDR).
|Note:
The -a and -r flags are mutually |exclusive. Use unfencevsd -v -n to unfence |nodes. Only use -r to remove an IBM Virtual Shared Disk |fence record from the SDR while no IBM Virtual Shared Disk is configured on |any node. |

|-v vsd_name_list
|Specifies one or more virtual shared disk names, separated by |commas.

Operands

None.

Description

Under some circumstances, the system may believe a node has become inoperable and may begin recovery procedures when the node is actually operational, but is cut off from communication with other nodes running the same application. In this case, the problem node must not be allowed to serve requests for the virtual shared disks it normally manages until recovery is complete and the other nodes running the application recognize the problem node as operational. The fencevsd command prevents the problem node from filling requests for its virtual shared disks. The unfencevsd command allows fenced nodes to regain access to the virtual shared disks.

This command can be run from any node.

Notes:

  1. This command will be unsuccessful if you do not specify a current server (primary or backup) to a virtual shared disk with the -v flag.

  2. This command changes SDR attributes when issued with the -r flag. Specify -r only when disks have already been removed from a fenced virtual shared disk.

Security

You must be in the AIX bin group to run this command.

Prerequisite Information

PSSP: Managing Shared Disks

Location

/usr/lpp/csd/bin/unfencevsd

Related Information

Commands: fencevsd, lsfencevsd, lsvsd, updatevsdtab, vsdchgserver

Refer to PSSP: Managing Shared Disks for information on how to use this command in writing applications.

Examples

  1. To unfence node 5 from the virtual shared disks vsd1 and vsd2, enter:
    unfencevsd -v vsd1,vsd2 -n 5
    
  2. To unfence node 7 from the virtual shared disks vsd1 and vsd2 when the unfencevsd command must be entered from node 7, enter:
    unfencevsd -v vsd1,vsd2 -n 7 -f
    

updatehsd

Purpose

updatehsd - Lets you change the option in the System Data Repository (SDR) that prevents overwriting the Logical Volume Control Block (LVCB) for specified hashed shared disks.

Syntax

updatehsd
{-d hsd_names | -a} [-f]
 
-o {protect_lvcb | not_protect_lvcb}

Flags

-d
Specifies the names of the hashed shared disks that are the targets of this command.

-a
Updates the option on all hashed shared disks defined in the system or system partition.

-o protect_lvcb | not_protect_lvcb
Specifies whether to skip the first stripe (the LVCB) up to a maximum of 128KB of every virtual shared disk that constitutes the hashed shared disk. protect_lvcb specifies skipping the LVCB; not_protect_lvcb specifies not skipping it.

-f
Forces the SDR changes by reconfiguring one or more virtual shared disks on all nodes in the current partition on which those virtual shared disks are currently configured.

Operands

None.

Description

Use this command only on the control workstation.

Note:
This utility is very powerful. Misuse can destroy the contents of a database. Only the superuser should be allowed to run it. If a database has been loaded on a configured hashed shared disk, modifying the protect_lvcb or not_protect_lvcb option will destroy the database.

The hashed shared disk name must be specified. You must choose either protect_lvcb or not_protect_lvcb. The hashed shared disk must be defined in the System Data Repository (SDR).

You can use the System Management Interface Tool (SMIT) to run this command. To use SMIT, enter:

smit set_HSDdd_parms

|and select the Update Hashed Shared Disk Option or

smit hsd_mgmtd_parms

|and select the Set/Show HSD Device Driver Operational Parameters |followed by the Update Hashed Shared Disk Option.

Security

You must have access to the virtual shared disk subsystem via the sysctl service to run this command.

Prerequisite Information

PSSP: Managing Shared Disks

Location

/usr/lpp/csd/bin/updatehsd

Related Information

Commands: defhsd, lshsd, hsdatalst

Examples

To set the protect_lvcb option for hsdcont01 and hsdcont02, enter:

updatehsd -d hsdcont01,hsdcont02 -o protect_lvcb

updatevsdnode

Purpose

updatevsdnode - Changes IBM Virtual Shared Disk subsystem options in the System Data Repository (SDR).

Syntax

updatevsdnode
-n {ALL | node_number [,node_number ...]}
 
{[-a {VSD_adapter | none}]
 
[-i init_cache_buffer_count]
 
[-m max_cache_buffer_count] [ -r vsd_request_count]
 
[-p rw_request_count] [ -b min_buddy_buffer_size]
 
[-x max_buddy_buffer_size] [ -s max_buddy_buffers]
 
[-M vsd_max_ip_packet_size]}
 
[-f] [-c cluster_name | NONE]

Flags

-n
Specifies the node numbers of the nodes whose SDR information you want this command to update, or ALL nodes in the system or system partition. You can issue the command /usr/lpp/ssp/install/bin/node_number to find out the node number of the node you are running on.

-a
Specifies the adapter name to be used for IBM Virtual Shared Disk communications with this node or nodes. IBM suggests using the switch (adapter name css0) for the virtual shared disk for best performance. |

|-i
|The IBM Virtual Shared Disk device driver implements an optional |write-through cache of pinned kernel memory with a block size of 4KB. |When the first cached virtual shared disk is configured on a node, the cache |is created, and it contains the number of blocks specified in this field of |the SDR. The minimum value is 1. IBM suggests using a value of |64, which results in a 256K cache. If you use the switch as the virtual |shared disk adapter, no cache buffer is allocated.
|Note:
IBM Virtual Shared Disk caching is no longer supported. This |information will still be accepted for compatibility with previous releases, |but the IBM Virtual Shared Disk device driver will ignore the |information. |
|

|-m
|The number of buffers in the cache can be increased up to |max_cache_buffer_count. You cannot decrease the number; |you must unconfigure all the virtual shared disks and start over. IBM |suggests using the value of 256, which results in a 1MB cache. If you |use the switch as the virtual shared disk adapter, no cache buffer is |allocated.
|Note:
IBM Virtual Shared Disk caching is no longer supported. This |information will still be accepted for compatibility with previous releases, |but the IBM Virtual Shared Disk device driver will ignore the |information. |

-r
This value will be ignored, but a value must be specified for coexistence. The device driver will dynamically allocate the structures that it needs to manage. The previous recommended value was 256.

-p
This value will be ignored, but a value must be specified for coexistence. The device driver will dynamically allocate the structures that it needs to manage. The previous recommended value was 256.

-b
Specifies the smallest buddy buffer a server uses to satisfy a remote request to a virtual shared disk. This value must be a power of 2 and greater than or equal to 4096. IBM suggests using the value of 4096 (4KB).

-x
The largest buddy buffer a server will use to satisfy a remote request. This value must be a power of 2 and greater than or equal to the min_buddy_buffer_size. The recommended value is 262144 (256KB). This value must be the same on all nodes within a system partition.

-s
This is the number of max_buddy_buffer_size buffers to allocate. The buddy buffer is pinned kernel memory allocated when the IBM Virtual Disk device driver is loaded the first time and is freed when the device driver is unconfigured from the kernel. The recommended value is in the range of 32 to 96 buddy buffers where the max_buddy_buffer_size has been set to 256KB.

Buddy buffers are only used on the servers. On client nodes you may want to set max_buddy_buffers to 1.

Note:
The statvsd command will indicate if remote requests are queueing waiting for buddy buffers.

-M
Specifies the maximum IP message size for virtual shared disks, in bytes. The recommended value for the switch is 61440 (61KB).

-f
Specifies that this command will force the SDR changes by reconfiguring one or more virtual shared disks on all nodes in the current partition on which those virtual shared disks are currently configured.

-c cluster_name | NONE
Changes the cluster the node belongs to. NONE removes the node from the cluster.

Operands

None.

Description

Use updatevsdnode to change the specified values in the SDR for all nodes in node_list.

Note:
This command only changes the information in the SDR. To effectively configure the virtual shared disks, you must first unconfigure all the virtual shared disks and then reconfigure them.

You can use the System Management Interface Tool (SMIT) to run this command. To use SMIT, enter:

smit vsd_mgmt

and select the Set/Show Virtual Shared Disk Device Driver Operational Parameters option or the Update IBM Virtual Shared Disk Device Driver Node Parameters option.

Security

You must have access to the virtual shared disk subsystem via the sysctl service to run this command.

Prerequisite Information

PSSP: Managing Shared Disks

Location

/usr/lpp/csd/bin/updatevsdnode

Related Information

Commands: lsvsd, vsdatalst, vsdnode

Examples

To increase the buddy buffer size to 48 maximum sized buddy buffers on node 3, enter:

updatevsdnode -n 3 -s 48

Note:
The device driver must be unconfigured from the kernel and reloaded to have this change go into effect.

updatevsdtab

Purpose

updatevsdtab - Changes the IBM Virtual Shared Disk subsystem option to set cache or nocache in the System Data Repository (SDR).

Syntax

updatevsdtab {-v vsd_names | -a} {[ -o {cache | nocache}] [-s ]} [-f]

Flags

-v vsd_names
Specifies a list of virtual shared disk names to be updated.

-a
Specifies that the option is to be changed on all nodes of the system or system partition. |

|-o cache | nocache
|Specifies either the cache or the nocache option. |The default is cache.
|Note:
IBM Virtual Shared Disk caching is no longer supported. This |information will still be accepted for compatibility with previous releases, |but the IBM Virtual Shared Disk device driver will ignore the |information. |

-s
Updates the virtual shared disk size after the associated logical volume size is changed.

-f
Forces SDR changes by reconfiguring a virtual shared disk on all nodes in the current system partition on which the virtual shared disk is configured.

Operands

None.

Description

Use this command to update the SDR, if necessary. When a feature of the virtual shared disk in the SDR (such as cache/nocache option or the virtual shared disk size), is changed using the updatevsdtab command, the change will not take effect until the virtual shared disk is unconfigured and configured again.

If the -f flag is specified, the virtual shared disks involved will be reconfigured (using sysctl) on all nodes that are up and initially had these virtual shared disks configured.

You can use the System Management Interface Tool (SMIT) to run this command. To use SMIT, enter:

smit vsd_mgmt

and select the Set/Show IBM Virtual Shared Disk Device Driver Operational Parameters option or the Update IBM Virtual Shared Disk Options option.

Security

You must have access to the virtual shared disk subsystem via the sysctl service to run this command.

Prerequisite Information

PSSP: Managing Shared Disks

Location

/usr/lpp/csd/bin/updatevsdtab

Related Information

Commands: defvsd, updatevsdnode

Examples

  1. To change the cache default for all virtual shared disks on a system or system partition, enter:
    updatevsdtab -a -o nocache
    
  2. To reset the size of the virtual shared disk named USER1n3, enter:
    updatevsdtab -v USER1n3 -s
    

updauthfiles

Purpose

|updauthfiles - Updates or creates (if necessary) the |.k5login, .klogin, and .rhosts |files on the control workstation and on all nodes in the system for which some |combination of DCE, K4, or Standard AIX are defined as authentication methods |or when no authentication methods are defined. | |

Syntax

updauthfiles [-h] [-I]

Flags

|-h
|Displays usage information.

-I
Specifies that updauthfiles was called during install, when name resolution is not available.

Operands

None.

Description

The updauthfiles command determines the authorization methods for the local host (control workstation or node) by reading the auth_root_rcmd attribute in the System Data Repository (SDR) |system partition object. If the specified |authorization method has been correctly configured and is running, it creates or updates the appropriate authorization file for Standard AIX, |Kerberos V4, and Kerberos V5 (using DCE principals). |If restricted root access (RRA) is enabled, the files will be |generated with no entries for root access from the nodes to the control |workstation or from the nodes to other nodes. If no authorization |methods (none) were selected, the authorization files will be |generated with no PSSP entries for the system partition.

The updauthfiles command copies the .klogin file from the /spdata/sys1/spsec directory to root's home directory when run on the control workstation. |If running on a node, it retrieves a copy of the |.klogin file |from the control workstation |unless restricted root access is activated, in which case the |.klogin file is generated at the node. The control workstation's authorization files are updated according to the union of all authentication methods in the system.

|If authorization methods or restricted root access settings have |recently changed, updauthfiles will add or delete PSSP-generated |entries from the authorization files to reflect the changes. Customer |added entries will be retained.

|If no authorization method (none) is selected, it cannot be |combined with any other authorization method on the system |partition.

An error message is generated and logged for any authorization file unable to be created or updated.

|Environment Variables

|PSSP 3.4 provides the ability to run commands using secure remote |command and secure remote copy methods.

|To determine whether you are using either AIX rsh or rcp |or the secure remote command and copy method, the following environment |variables are used. |If no environment variables are set, the defaults are |/bin/rsh and /bin/rcp.

|You must be careful to keep these environment variables consistent. |If setting the variables, all three should be set. The DSH_REMOTE_CMD |and REMOTE_COPY_CMD executables should be kept consistent with the choice of |the remote command method in RCMD_PGM: |

|For example, if you want to run updauthfiles using a secure remote |method, enter:

|export RCMD_PGM=secrshell
|export DSH_REMOTE_CMD=/bin/ssh
|export REMOTE_COPY_CMD=/bin/scp

Standard Input

The command reads the .k5login, .klogin, and .rhosts files.

Standard Output

The command updates the .k5login, .klogin, and .rhosts files.

The command |may issue |a remote copy from a node to the control workstation to copy the .klogin file.

A log file is created in /var/adm/SPlogs/auth_install/log.

Exit Values

0
Indicates successful completion of the command. |

|1
|Indicates a problem running the command. Review the log |file for the specific problem. The authorization files may be |incorrect. This could cause problems when remote commands are issued, |causing some PSSP administrative tasks to be unsuccessful.

|Correction of errors is necessary to complete the process. Problems |relating to the creation of .rhost and |.k5login files should be corrected on the node, and the |command should be rerun. Problems due to copying the |.klogin file may need to be corrected on the control |workstation; then the command should be rerun on the node. |Problems relating to the creation of the .klogin file on the |control workstation or on the nodes when restricted root access is enabled, |should be fixed from wherever updauthfiles was run.

Security

You must have root privilege to run this command.

Related Information

Commands: rcp

Files: .rhost, .klogin, and .k5login

Location

/usr/lpp/ssp/bin/updauthfiles

Examples

To create the appropriate authorization files on the control workstation, enter:

/usr/lpp/ssp/bin/updauthfiles


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