Go to main content

Managing Devices in Oracle® Solaris 11.4

Exit Print View

Updated: November 2020
 
 

Dynamic Reconfiguration and Hot-Plugging

Hot-plugging is an operation in which you add, remove, or replace system components while the system is running. Dynamic reconfiguration refers to the ability to adjust configuration of hot-plugged components. This term also refers to the general ability to move both hardware and software system resources around in the system or disable them in some way without physically removing them from the system.

In Oracle Solaris, you can add, remove, or replace devices while the system is still running provided that the system components support hot-plugging. Without that support, new devices are configured at boot time after the new components are installed on the system.

You can hot-plug bus types such as USB, Fibre Channel, SCSI, and so on. Additionally, you can hot-plug devices such as PCI and PCIe, USB, InfiniBand, and so on.

To perform hot-plugging and DR, you typically use the cfgadm command, which also guides you through the steps to complete these tasks. You can perform the following actions:

  • Display system component status

  • Test system components

  • Change component configurations

  • Display configuration help messages

Performing DR and hot-plugging require administrative privileges that are not generally granted to user accounts. Therefore, you must obtain the appropriate rights for these tasks. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.4.

You can use DR in conjunction with additional layered products from Oracle such as alternate pathing or failover software. These products work together to provide fault tolerance in the event of a device failure and thus ensure higher availability of the systems.

Without high availability software, you can replace a failed device only by manually stopping the appropriate applications, unmounting noncritical file systems, and then proceeding with the device replacement.


Note -  Some systems have a mix of hot-pluggable slots and slots that are not hot-pluggable. Refer to your hardware documentation for information about hot-plugging devices on your specific system.

Attachment Points

Attachment points are locations on the system where DR can occur.

An attachment point consists of an occupant part and a receptacle.

  • An occupant is a hardware component that can be configured into the system. An occupant's state can be either configured or unconfigured.

  • A receptacle is the location that accepts the occupant. A receptacle's state can be either connected or disconnected. An empty state also exists but applies only to non-SCSI host bus adapters (HBAs).

The following table shows the combined states of occupants and receptacles on attachment points and the corresponding states of a device.

Occupant and Receptacle Combined States
Description of Device State
Unconfigured/Empty
Device is not physically connected (applies to non-SCSI HBAs only)
Unconfigured/Disconnected
Device is logically disconnected and unavailable, even though the device might be physically connected
Unconfigured/Connected
Device is logically connected but unavailable. Device is included in the prtconf command output
Configured/Connected
Device is connected and available

About Attachment Point Identification

Attachment points are represented by physical and logical attachment point IDs (Ap_Ids). The physical Ap_Id is the physical path name of the attachment point. The logical Ap_Id is a user-friendly alternative for the physical Ap_Id. For more information about Ap_Ids, refer to cfgadm(8) man page.

The logical Ap_Id for a device consists of the combination of the HBA Ap_Id and the device identifier, and follows the format HBA-Ap_Id::device-identifier. For example, the Ap_Id of a SCSI HBA is normally the controller number, such as c0. If the device identifier on the HBA is dsk, then that device's logical Ap_Id would be c0::dsk.

The device identifier is derived from the logical device name in the /dev directory. For example, a tape device with the logical device name /dev/rmt/1 would have the device identifier rmt/1. Thus, the tape device's logical Ap_Id would be c0::rmt/1.

If an HBA Ap_Id has no controller number, an internally generated unique identifier is provided, such as fas1:scsi. If a device identifier cannot be derived from the logical name in the /dev directory, then an internally generated unique identifier is also provided. For example, for the /dev/rmt/1 tape device, the logical name might be st4 and the logical Ap_Id would be c0::st4.

For more information about SCSI Ap_Ids, refer to the cfgadm_scsi(8) man page.