| Sun Fire High-End Systems Software Overview Guide |    
|
| Sun Fire High-End Systems Software Overview Guide |
|
| C H A P T E R 6 |
|
Dynamic Reconfiguration Software for Sun Fire High-End Systems |
Dynamic reconfiguration (DR) software running on the Sun Fire high-end systems enables you to perform hardware configuration changes to a live domain that is running the Solaris OS.
You can perform DR operations from the SC or from an individual domain.
You can perform DR operations from the SC using the addboard(1M), moveboard(1M), deleteboard(1M), and rcfgadm(1M) SMS commands.
Dynamic reconfiguration software also enables you to hot-plug system boards without bringing the system down. It is used to deconfigure the resources on a faulty system board from a domain so that the system board can be removed from the system. The repaired or replacement board can then be inserted into the domain while the Solaris OS is running.
DR software then configures the resources on the board into the domain. If you use the DR feature to add or remove a system board, DR always leaves the board in a known configuration state.
Domain configuration for Sun Fire high-end systems is determined by the domain configuration in the platform configuration database (PCD), which resides on the SC. The PCD controls how the system board slots are logically partitioned into domains. Thus, the configuration can include empty slots and populated slots.
The physical domain is determined by the logical domain. The logical domain is the set of slots that belong to the domain. The physical domain is the set of boards that are physically interconnected. A slot can be a member of a logical domain without having to be part of a physical domain.
The number of slots available to a given domain is controlled by an available component list maintained on the system controller. A slot must be assigned or available to a domain before you can use a cfgadm(1M) command to change its state.
After a slot has been assigned to a domain, it becomes visible to that domain and unavailable and invisible to any other domain. Conversely, you must unassign and disconnect a slot from its domain before you can assign and connect it to another domain.
After the domain is booted, the system boards and the empty slot can be assigned to or unassigned from a logical domain. However, they are not allowed to become a part of the physical domain until the operating system requests it.
System board slots that are not assigned to any domain are available to all domains. These boards can be assigned to a domain by the platform administrator; however, an available component list can be set up on the SC to allow users with appropriate privileges to assign available boards to a domain.
The available component list controls what administrative tasks can be performed, based on the name and group identification of the user. For instance, the platform administrator can add, delete, or move boards to or from a domain, as well as assign and unassign boards to or from a domain. However, the domain administrator or a domain configurator cannot assign or unassign boards to or from a domain.
On the SC for a Sun Fire high-end system, a board can be in one of four states: unavailable, available, assigned, or active. You can use the showboards(1M) command to view the state of a specific board. You must have appropriate privileges for the specified domain. Unavailable boards cannot be viewed by the domain administrator. Only the platform administrator can see every board in the system.
The names and descriptions of the states for boards on the SC are described in the sections that follow. The state of a board on the SC is not the same as the state of a board on the domain.
The board is unavailable to the domain. This means that the board has not been added to the available component list for the specified domain or that the board is currently assigned to another domain. Note that boards that are not in the available component list are invisible to the domain. In the unavailable state, the board is not considered part of the specified domain.
The board is available to be added to the domain. This means that the board is in the available component list for the domain. Note that the board can be available to any number of domains. In the available state, the board is considered to be part of the logical domain.
The board has been assigned to the domain, which means that the board is in the available component list for that domain and that it is unavailable to any other domain. In the assigned state, the board is considered to be part of the physical domain.
The board has been connected or the board has been connected and configured into the Solaris OS and is available for use by the operating system. In the active state, the board is considered part of the physical domain.
You must use caution when you add or remove system boards with I/O devices. Before you can remove a board with I/O devices, all its devices must be closed and all its file systems must be unmounted.
If you need to remove a board with I/O devices from a domain temporarily and then add it back before any other boards with I/O devices are added, reconfiguration is not necessary and need not be performed. In this case, device paths to the board devices remain unchanged. But if you add another board with I/O devices before the first board has been put back, reconfiguration is required because the paths to devices on the first board have changed.
Automatic DR enables an application to execute DR operations without requiring user interaction. This ability is provided by an enhanced DR framework that includes the reconfiguration coordination manager (RCM) and the sysevent system event facility. The RCM enables application-specific loadable modules to register callbacks. The callbacks perform preparatory tasks before a DR operation, error recovery during a DR operation, and cleanup after a DR operation.
The system event framework enables applications to register for system events and receive notifications of those events. The automatic DR framework interfaces with the RCM and with the system event facility to enable applications to automatically give up resources prior to unconfiguring them, and to capture new resources as they are configured into the domain.
The automatic DR framework can be used locally from the domain by using the cfgadm(1M) command, or from the SC. The automatic DR operations that are initiated locally on the domain are referred to as local automatic DR, and the automatic DR operations initiated from the SC are referred to as global automatic DR. The global automatic DR operations include moving system boards from one domain to another, configuring hot-plugged boards into a domain, and removing system boards from a domain.
See Dynamic Reconfiguration Software Information to determine which documents to read for more information about Dynamic Reconfiguration software.
| Sun Fire High-End Systems Software Overview Guide | 819-4658-10 |
|
Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.