|C H A P T E R 1|
Introduction to DR
The Sun Fire high-end and midrange systems listed in the Preface can be divided into domains, each functioning as a separate computer, running its own operating system (see Dynamic System Domains). The dynamic reconfiguration (DR) feature lets you enable and disable a domain's system boards, I/O boards, and certain components while that domain continues running.
Part of DR runs on Solaris software in the domain and is managed through the cfgadm(1M) command. Another part runs on the system controller (SC).
This chapter covers the following topics:
System boards on midrange systems are sometimes called CPU/Memory boards. They are the same boards as those on high-end systems. This document exclusively uses the term system board. System boards are interchangable between high-end and midrange platforms.
High-end system I/O boards and midrange systems I/O assemblies are similar in some ways, but different in others. This document uses the term I/O board for both except when necessary for clarity.
The I/O buses on a high-end system I/O board support PCI or hsPCI+ cards and MaxCPU boards. A MaxCPU board fits into slot 1 and contains two CPUs and no memory.
Midrange system I/O boards support PCI or CompactPCI cards.
This document uses the generic term PCI when referring to hsPCI+ and CompactPCI cards except when clarity demands otherwise.
Some of the tasks you can use DR for include:
For example, you can DR detach a faulty system board, then use the system's hot-plug feature to physically remove it. After plugging in the repaired board or a replacement, you can use DR to configure the board into the domain. If you use the DR feature to add or remove a system board or component, DR always leaves the board or component in a known configuration state. See States and Conditions for more information about configuration states for system boards and components.
You can also assign a system board or I/O board to a different domain for load balancing or to provide extra capabilities for specific tasks.
DR software enables you to do the following tasks:
The four main types of DR operations that support the above actions are connect, configure, unconfigure, and disconnect.
Note - If a system board is in use, you must stop its use and disconnect it from the domain before you power it off. After a new or upgraded system board is inserted and powered on, connect its attachment point (see Attachment Points) and configure it for use by the operating system. For more information about DR operations, see Common DR Board Operations.
You can initiate DR operations in any of the following ways:
When running DR on a midrange system you might need to execute one or more midrange system SC commands - such as showplatform and showboards - before or during DR operations. Their use is briefly described where appropriate in this document, and you can find more information about them in the Sun Fire Midrange Systems Controller Command Reference Manual.
Caution - The midrange system SC commands addboardand deleteboardare not DR commands like the high-end system SMS commands of the same name. You can safely use these midrange system SC commands only when the domain is powered off. For more information about these and other midrange system SC commands, see the Sun Fire Midrange Systems Controller Command Reference Manual.
A hot-pluggable device can be logically connected to or disconnected from a running system. (A hot-swappable device can be physically connected to or disconnected from a running system.) Hot-pluggable boards and modules have special connectors that supply electrical power to the board or module before the data pins make contact. Boards and devices that have hot-plug connectors can be inserted or removed while the system is running; that is, they are hot-swappable.
System boards and I/O boards are hot-plug devices. However, some devices, such as the peripheral power supply, are not hot-plug modules and cannot be disconnected while the system is running.
Automatic DR (ADR) lets your applications execute DR operations with no user interaction. ADR uses an enhanced DR framework that includes the reconfiguration coordination manager (RCM) and the system event facility, sysevent. The RCM enables application-specific loadable modules to register callbacks. The callbacks can perform preparatory tasks before, error-recovery actions during, and clean-up after a DR operation. The system event framework enables applications to register for system events and receive notifications of those events.
ADR interfaces with the RCM and sysevent to enable applications to automatically give up resources prior to unconfiguring them, and to capture new resources as they are configured into the domain.
An application can execute the cfgadm(1M) command from a domain, which is called local ADR. In addition, on high-end systems, the application can execute an SMS DR command from the SC, which is called global ADR. On high-end systems you can use global ADR to move system boards from one domain to another, configure hot-swapped boards into a domain, and remove system boards from a domain.
The Capacity on Demand (COD) option provides additional CPU resources on COD system boards that you install in your Sun Fire system. A Sun Fire COD system can have a mix of both standard and COD system boards installed. At least one active CPU is required for each domain in the system.
You can use DR to move COD boards into and out of domains in the same way you use it to move standard system boards. But you can use the CPUs on a COD board only after you purchase right-to-use (RTU) licenses for them. Each COD RTU license entitles you to receive a COD RTU license key that enables a specified number of CPUs on COD boards in a single system.
Whenever you use DR to configure a COD board into a domain, make sure enough RTU licenses are available to the target domain to enable each active CPU on the COD board. If the target domain does not have enough RTU licences available to it when you attempt to add a COD board, the system displays a status message for each CPU that cannot be enabled in the domain.
For more information about the COD option for high-end systems, see the System Management Services (SMS) Administrator Guide.
This document describes the latest version of DR as it runs on or with the latest Solaris 8, Solaris 9, and Solaris 10 software releases. Be sure to check the SunSolveSM database at http://sunsolve.sun.com for the latest patches.
The following sections describe any special considerations for using DR with specific Solaris releases.
The Solaris 10 3/05 HW1 OS is the first release of Solaris 10 software to support the UltraSPARC® IV+ system board, and the Solaris 9 9/05 OS is the first release of Solaris 9 software to do so. You can add UltraSPARC IV+ boards to a domain configured with older boards, but you cannot use DR to add an older board to a domain that was booted with all UltraSPARC IV+ boards. (You can add an older board to a domain booted with all UltraSPARC IV+ boards if you shut down the domain first.)
For additional information about domain restrictions with UltraSPARC IV+ boards on Sun Fire midrange systems, see the Sun Fire Midrange Systems Platform Administration Manual for Firmware Release 5.19.
The Solaris 8 2/02 OS was the first release of Solaris 8 software to support DR of I/O boards. In addition, System Management Services (SMS) 1.3 on Sun Fire high-end systems is the first release of SMS to fully support DR. You can enable the full functionality of DR on domains running software no earlier than the Solaris 8 2/02 OS by installing patches and a new kernel update on the domain; and by installing the latest version of SMS software on your high-end server's system controller (SC). The Solaris 8 OS does not support UltraSPARC IV+ boards.