Changing Configurations - Sun Microsystems IB Switch 9P Administration Manual

Changing Configurations

You can change from one configuration (blueprint) to another without re-configuring
the hosts by ensuring that the IB subnet prefix is maintained when changing from
one configuration to another. However, changing the blueprint on a switch cannot be
done without re-booting the switch. Hence, the hosts connected to the rebooting
switch will loose access to the subnet during this transition period.
In cascaded configurations, one switch can be replaced (or removed or powered
down) without impacting the other switches in the configuration or the hosts that
are connected to those switches. To construct cascaded configurations, switches can
be configured and connected in any order as long as they are configured with
consistent blueprint type, subnet prefix and switch role.
However, merging two operational configurations cannot be performed without
performing a manual re-configuration of all the hosts in one of the original
configurations. Hence, if two switches are both configured as part of a 12-node
blueprint with the same subnet IDs, but are not connected to each others before they
are booted and configured, then they can not be interconnected at a later time
without having to perform a re-configuration of (some of) the connected hosts.
In order to avoid such problems, it is recommended to always connect and configure
all switches that are supposed to be part of a subnet before connecting (or booting)
any associated host. - In the case of replacing a switch in an operational
configuration, the implication is that the new switch should be connected to the
existing switch(es) before it is allowed to become operational (with connected,
operational hosts).
If a subnet has been made operational with all associated switches present, then it is
possible to disconnect and then re-connect the switches without having to re-
configure anything. Also, it is possible to change connection of a host from one
switch port to another port on another switch without having to perform any re-
configuration.
Connecting switches with conflicting configurations will not impact existing
operational connectivity for the switch, but no communication will be possible
between the switches where the blueprint configurations does not match.
If for some reason it is decided to reduce the number of nodes in a configuration
(e.g. split a 12-node configuration into two disjoint parts), then this can be done
without changing the blueprint setting on any of the switches. However, if changing
the blueprint is required in order to allow more hosts to be connected to a single
switch, then this may imply that the hosts that are currently attached to the switch
have to be re-configured.
Appendix D Blueprints 91