sm_config(1M)         Maintenance Commands          sm_config(1M)

NAME
     sm_config - SCI adapter configuration utility for clusters

SYNOPSIS
     sm_config [-t] -f filename

AVAILABILITY
     SUNWsma

INTERFACE CLASSIFICATION
     Sun Private

DESCRIPTION
     sm_config is the SCI adapter configuration utility.  It acts
     as  a  client  of sm_configd(1M) daemon.  sm_config contacts
     the sm_configd(1M) daemon on all the hosts and  works  in  a
     distributed  fashion  to  retrieve the adapter inventory and
     configure the adapter cards on these hosts.  The  configura-
     tion process involves programming -
      (a) the adapter Node-Ids into the  adapter's  flash  memory
     and
      (b) IP addresses into the cards.

     Upon  successful  completion,  a  configuration  file  named
     /etc/sma.config  is  installed on all the hosts in the clus-
     ter.  This file contains a  snapshot  view  of  the  cluster
     members,  switches,  adpaters  etc.  It also installs a file
     called /etc/sma.ip which contains the IP  addresses  of  all
     the SCI interfaces in the cluster.

OPTIONS
     -t              starts sm_config in debug mode.

     -f filename     takes the filename as  an  input  file.  The
                    input   file   template   is   available   in
                    /opt/SUNWsma/bin     directory     as     (a)
                    template.pdb   (for  PDB  clusters)  and  (b)
                    template.hpc (for HPC clusters).  These  tem-
                    plate   files  provide  detailed  information
                    about the type  of  information  required  by
                    sm_config.

     This input file template contains 8 sections -

     1. Cluster configuration section -  specifies  the  type  of
     cluster  being  configured  (PDB or HPC).  A sample template
     for this section -
       Cluster is configured as =    PDB

     2. Host names section  - requires the names of all the hosts
     in  the  cluster.   If  the hosts in the cluster do not have
     full public-net connectivity  then  the  name  of  the  host
     without  connectivity  must be preceded by "_%".  This indi-
     cates to sm_config not to contact this host via the  public-
     net.

     For example, consider a case where host2  in  a  cluster  of
     host1, host2, host3 and host4 lacks public-net connectivity.
     When sm_config is started with the following template_1,  it
     will contact host1, host3 and host4 over the net and config-
     ure their SCI interfaces.  However, it  is  now  the  user's
     responsibility  to run sm_config on host2 in the stand-alone
     mode using template_2 below.

     template_1 - used on host1, host3 and host4 :-
       HOST 0  =    host1
       HOST 1  =    _%host2
       HOST 2  =    host3
       HOST 3  =    host4

     template_2 - used on host2 :-
       HOST 0  =    _%host1
       HOST 1  =    host2
       HOST 2  =    _%host3
       HOST 3  =    _%host4

     A caveat to keep in mind when running  sm_config  in  stand-
     alone mode is that, sm_config cannot guarantee the coherency
     of the /etc/sma.config generated during the different  invo-
     cations  (for  eg.  in  the  above case - /etc/sma.config on
     host2 versus the ones on host1, host3 and host4) if the user
     were to supply inconsistent input data for the two cases.

     3.  Number of Switches section - Accepts input for the total
     no. of switches in the cluster.

     However, if the cluster being configured has some unused SCI
     adapters  meant  for  use  in  the  future, then the cluster
     should be configured as it would look in  the  future,  when
     all  the  adapters  are fully connected.  For instance, a 1-
     switch cluster containing 4 hosts with 2  adapters  on  each
     (second  set of adapters idle), which will later evolve into
     a 2-switch cluster should be configured as a 2-switch  clus-
     ter.

     This ensures that when the cluster evolves to its final form
     in future, new communication channels (SMA sessions) will be
     created on the new links (say, through a new switch) on  the
     fly.   This  eliminates  having  to  run sm_config later and
     rebooting the machine.  A detailed example of this is  given
     in the input template file.

     A sample template for this section -
       Number of Switches in cluster =         2
     4. Number of Direct Links section -  Accepts input  for  the
     total  no. of direct SCI links in the cluster. A sample tem-
     plate for this section -
       Number of Direct Links in cluster =     2

     5. Allow Rings section - Whether the cluster supports confi-
     gurations  with multiple hosts connected to the same port of
     the same switch.  A sample template for this section -
       Allow Rings in cluster (Y/N)?   =       N

     6. Adapter information section -  Accepts detailed  informa-
     tion  for  each adapter on each host.  A sample template for
this section is -
       host 0 :: adp 0 is connected to =       switch 0 :: port 0
       host 0 :: adp 1 is connected to =       link 1 :: endpt 0

     7. Network IP address section - Accepts the first  3  octets
     (network) of the IP address for a particular switch or link.
     A sample template for this section -
       Network IP address for Switch 0 =     204.152.65


     8. Netmask section - Accepts the netmask for the private SCI
     sub-nets.   For  example,  a cluster with less than 15 hosts
     per switch should select a netmask of 0xf0 while  a  cluster
     with  15  hosts  or more but less than 31 hosts would choose
     0xe0.  A sample template for this section -
       Netmask = f0

USAGE
     The root user can start  sm_config  from  the  command  line
     using the -f option to provide an input file to it.

     A cluster can have 3 topologies -
      (i) Switched - All hosts are connected to  each  other  via
     SCI switches.  Can have 2 or more hosts.
      (ii) Non-switched - Two hosts connected  directly  via  SCI
     cables (direct links).  Has exactly 2 hosts.
      (iii) Hybrid - Contains switches and direct links. Can have
     2 or more hosts.

     NOTE - At this point, PDB does not  support  more  than  two
     switches  in  a cluster (see (i) above), nor does it support
     case (iii) from above.

     NOTE - sm_config can be run on any host in the cluster,  but
     it  should  not  be run on multiple hosts simultaneosly (eg.
     via cconsole).  If this occurs, the results  are  unpredict-
     able - in the worst case, the adapter flash memory might get
     programmed with corrupt data.

     NOTE  -  After  running  sm_config,  the  system  should  be
     rebooted.

FILES
     /opt/SUNWcluster/bin/sm_config
     /etc/sma.config
     /etc/sma.ip

SEE ALSO
     sm_configd(1M)

DIAGNOSTICS
     sm_config prints error and warning messages to stderr.  If a
     fatal error occurs on any host or locally where sm_config is
     running, then the process is aborted and no  /etc/sma.config
     is  generated  till  the error is rectified.   Do not reboot
     the machine till a successful run of sm_config has been com-
     pleted.

RELEASE NOTES -
     If nis+ is being used as the name service then  the  default
     behaviour  is  to  look  up  the global nis+ map but if that
     doesn't exist, the local /etc/services file is not searched.
     This  behaviour is different from the default nis behaviour.
     In  this  scenario  inetd  will  be  unable  to  start   the
     sm_configd daemon.

SunOS 5.5.1        Last change: 30 March 1997

get_ci_status(1M)     Maintenance Commands      get_ci_status(1M)

NAME
     get_ci_status - Displays the Cluster configuration, the  SCI
     adapter status and the SMA session status.

SYNOPSIS
     get_ci_status [ -l ]

AVAILABILITY
     SUNWsma

INTERFACE CLASSIFICATION
     Sun Private

DESCRIPTION
     get_ci_status displays the cluster  configuration,  the  SCI
     adapter  status  and the SMA session status.  It queries the
     SCI driver for information about the local SCI adapters  and
     tests  the  connectivity  to  SCI  adapters  on other hosts,
     either via a switch or a direct link.

     For each adapter in the cluster, get_ci_status displays  the
     host  it is on, the port on a switch it is connected to, its
     adapter-id and whether the local  adapters  can  communicate
     with the adapters on other hosts.

     In addition, for each local adapter  get_ci_status  displays
     the  SBus  slot#  it is attached to, the host part of its IP
     address and whether the adapter is functional.

OPTIONS
     -l    Displays the local SCI adapter status only.

     no option
          Displays the local SCI adapter status and global  clus-
          ter   status.    When  displaying  the  global  status,
          get_ci_status reports whether the remote adapter can be
          reached  at  the hardware level (via SCI_PROBES) and/or
          at the software session level (via SMA sessions).

     The SCI Probe reachability is indicated by active  or  inac-
     tive keywords following the status for the remote adapter in
     question. The software SMA session reachability is indicated
     by  operational  or inoperational keywords.  For example, an
     output of the following form -

      sma: sci #0: sbus_slot# 1; adapter_id 8 (0x08);  ip_address
     1;  switch_id#  0;  port_id#  0;  Adapter  Status - UP; Link
     Status - UP
      sma: sci #1: sbus_slot# 2; adapter_id 12 (0x0c); ip_address
     17;  switch_id#  1;  port_id#  0;  Adapter Status - UP; Link
     Status - UP
      sma: Switch_id# 0
      sma: port_id# 1: host_name = interconn2; adapter_id  =  72;
     active | operational
      sma: port_id# 2: host_name = interconn3; adapter_id =  136;
     active | operational
      sma: port_id# 3: host_name = interconn4; adapter_id =  200;
     active | operational
      sma: Switch_id# 1
      sma: port_id# 1: host_name = interconn2; adapter_id  =  76;
     active | inoperational
      sma: port_id# 2: host_name = interconn3; adapter_id =  140;
     inactive | operational
      sma: port_id# 3: host_name = interconn4; adapter_id =  204;
     inactive | inoperational

     indicates that there are 2 local adapters (adapter_id 8  and
     12),  both  of  which  are  functioning OK (keyword UP) with
     respect to SCI Probes  to  themselves.   In  case,  a  local
     adapter  is  unable  to  complete  a successful SCI Probe to
     itself, the status of that local adapter is shown as DOWN.

     The global status is shown in the set  of  lines  associated
     with a switch.  The status of the communication channel from
     the local adapter  (adapter_id  8)  to  remote  adapters  on
     interconn2,  interconn3  and interconn4 via the first switch
     (Switch_id# 0) is - SCI Probe status OK (keyword active) and
     SMA sessions functional (keyword operational).

     However, the status of the communication channels  from  the
     local  adapter  (adapter_id  12)  to remote adapters via the
     second switch (Switch_id #1) have the following problems -
       1. Adapter_id  76  =>  SCI  Probes  -  reachable  (keyword
     active)  and SMA session - not established (keyword inopera-
     tional)
       2. Adapter_id 140 => SCI  Probes  -  unreachable  (keyword
     inactive)  and  SMA  session - established (keyword inopera-
     tional).  This is a brief transitionary stage.
       3. Adapter_id 204 => SCI  Probes  -  unreachable  (keyword
     inactive)  and  SMA  session - not established (keyword ino-
     perational)

USAGE
     get_ci_status can be run from the command line by any  user.
     However,  it  can  only  be run after the adapter cards have
     been initialized using sm_config(1M).  This ensures that all
     the  adapter  node-ids have been properly programmed and the
     configuration file /etc/sma.config exists.

FILES
     /opt/SUNWsma/bin/get_ci_status
     /etc/sma.config

SEE ALSO
     sm_config(1M),

DIAGNOSTICS
     get_ci_status prints error and warning messages to stderr.

SunOS 5.5.1        Last change: 30 March 1997