| System Management Services (SMS) 1.6 Administrator Guide |    
|
| System Management Services (SMS) 1.6 Administrator Guide |
|
| C H A P T E R 5 |
|
SMS Domain Configuration |
A dynamic system domain (DSD) is an independent environment, a subset of a server, that is capable of running a unique version of firmware and a unique version of the Solaris OS. Each domain is insulated from the other domains. Continued operation of a domain is not affected by any software failures in other domains or by most hardware failures in any other domain.
The system controller (SC) supports commands that enable you to logically group system boards into dynamic system domains, or simply domains, which are able to run their own OS and handle their own workload. Domains can be created and deleted without interrupting the operation of other domains. You can use domains for many purposes. For example, you can test a new OS version or set up a development and testing environment in a domain. In this way, if problems occur, the rest of your system is not affected.
You can also configure several domains to support different departments, with one domain per department. You can temporarily reconfigure the system into one domain to run a large job over the weekend.
The Sun Fire 15K system allows up to 18 domains to be configured. The Sun Fire 12K system allows up to 9 domains to be configured.
Domain configuration establishes mappings between the domains and the server's hardware components. Also included in domain configuration is the establishment of various system management parameters and policies for each domain. This chapter discusses all aspects of domain configuration functionality that the Sun Fire high-end system provides.
This chapter contains the following sections:
A domain configuration unit (DCU) is a unit of hardware that can be assigned to a single domain. DCUs are the hardware components from which domains are constructed. DCUs that are not assigned to any domain are said to be in no-domain.
All DCUs are system boards and all system boards are DCUs. The Sun Fire high-end system DCUs are:
Sun Fire high-end system hardware requires the presence of at least one regular system board, plus at least one of the I/O board types in each configured domain. csb, exb boards, and the SC are not DCUs.
|
Note - MaxCPU boards do not contain memory. To set up a domain, at least one regular CPU board is required. |
You can create a domain out of any group of system boards, provided the following conditions are met:
The assignment of DCUs to a domain is the result of one of three logical operations acting on a DCU (system board):
Although there are logically three DCU assignment operations, the underlying implementation is based upon four domain configuration operations:
The first two domain configuration operations apply to inactive domains; that is, to domains that are not running OS software. These operations are called static domain configuration operations. The latter two domain configuration operations apply to active domains, that is, those running OS software, and are called dynamic domain configuration operations.
Dynamic domain configuration requires interaction with the domain's Solaris software to introduce or remove the DCU-resident resources such as CPUs, memory, or I/O devices from Solaris OS control. Sun Fire high-end system dynamic reconfiguration (DR) provides a capability called remote DR for an external agent, such as the SC, to request dynamic configuration services from a domain's Solaris environment.
The SC command user interfaces utilize remote DR as necessary to accomplish the requested tasks. Local automatic DR allows applications running on the domain to be aware of impending DR operations and to take action, as appropriate, to adjust to resource changes. This improves the likelihood of success of DR operations, particularly those which require active resources to be removed from domain use. For more information on DR, refer to the System Management Services (SMS) 1.6 Dynamic Reconfiguration User Guide.
When a domain is configured for local automatic DR, remote DR operations initiated from the SC benefit from the automation of DR operations for that domain. With local automatic DR capabilities available in Sun Fire domains, simple scripts can be constructed and placed in a crontab(1) file, allowing simple platform reconfigurations to take place on a time schedule.
SMS allows you to add boards to or remove boards from an active (running) domain. Initiation of a remote DR operation on a domain requires administrative privilege for that domain. SMS grants the ability to initiate remote DR on a domain to individual administrators on a per-domain basis.
The remote DR interface is secure. Since invocation of DR operations on the domain itself requires superuser privilege, remote DR services are provided only to known, authenticated remote agents.
The user command interfaces that initiate DCU assignment operations are the same whether the affected domains have local automatic DR capabilities or not.
SMS provides for the addition or removal of a board from an active domain, such as static domain configuration using addboard, deleteboard, and moveboard. For more information, refer to the System Management Services (SMS) 1.6 Dynamic Reconfiguration User Guide.
Remote DR and local automatic DR functions are building blocks for a feature called global automatic DR. Global automatic DR introduces a framework that can be used to automatically redistribute the system board resources on a Sun Fire system. This redistribution can be based upon factors such as production schedule, domain resource utilizations, domain functional priorities, and so on. Global automatic DR accepts input from customers describing their Sun Fire resource utilization policies and then uses those policies to automatically marshal the Sun Fire high-end system resources to produce the most effective utilization. For more information on DR, refer to the System Management Services (SMS) 1.6 Dynamic Reconfiguration User Guide.
This section briefly describes the configuration services available to the platform administrator.
Each domain (A-R) defaults to having a 0-board list of boards that are available to an administrator or configurator to assign to their respective domains. Boards can be added to the available component list of a domain by a platform administrator using the setupplatform(1M) command. Updating an available component list requires pcd to perform the following tasks:
After pcd notifies dxs about any added boards, dxs in turn notifies the running domain of the arrival of an available board.
setupplatform sets up the available component list for domains. If a domain-id or domain-tag is specified, a list of boards must be specified. If no value is specified for a parameter, it will retain its current value.
1. In an SC window, log in as a platform administrator.
2. Type the following command:
|
Adds the slot to the available component list for the specified domain. |
|
|
domain-id - ID for a domain. Valid domain-ids are A-R and are not case sensitive. |
|
The following location forms are accepted:
The following is an example of making boards at SB0, IO1, and IO2 available to domain A:
The platform administrator can now assign the board to domain A using the addboard(1M) command or leave that up to the domain administrator.
A platform administrator has privileges for only the -c assign option of the addboard command. All other board configuration requires domain privileges. For more information, refer to the addboard man page.
You do not need to create domains on the Sun Fire high-end system. Eighteen domains have already been established (domains A-R, case insensitive). These domain designations are customizable. This section describes how to uniquely name domains.
|
Note - Before proceeding, see Domain Configuration Requirements. If the system configuration must be changed to meet any of these requirements, call your service provider. |
2. Type the following command:
|
domain-id - ID for a domain. Valid domain-ids are A-R and are not case sensitive. |
|
|
The new name you want to give to the domain. It must be unique among all domains controlled by the SC. |
The following is an example of naming Domain A to dmnA:
|
Note - Platform administrators are restricted to using the -c assign option. The option can be used only for boards classified as available, not for boards classified as active. |
The system board must be in the available state to the domain to which it is being added. Use the showboards (1M) command to determine a board's state.
2. Type the following command:
|
domain-id - ID for a domain. Valid domain-ids are A-R and are not case sensitive. |
|
|
Specifies the transition of the board from the current configuration state to the assigned state. |
|
The following location forms are accepted:
SB0, IO1, SB1, and IO2 have now changed from a state of being available to domain C to being assigned to that domain.
addboard performs tasks synchronously and does not return control to the user until the command is complete. If the command fails, the board does not return to its original state. A dxs or dca error is logged to the domain and pcd reports an error to the platform log file. If the error is recoverable, you can retry the command. If it is unrecoverable, you must reboot the domain in order to use that board.
|
Note - Platform administrators are restricted to using the -c unassign option. The option can be used only for boards with a status of assigned, not boards with a status of active. |
The system board must be in the assigned state to the domain from which it is being deleted. Use the showboards (1M) command to determine a board's state.
2. Type the following command:
|
Specifies the transition of the board from the current configuration state to a new unassigned state. |
|
The following location forms are accepted:
SB0 has now changed from being assigned to the domain to being available to it.
If deleteboard fails, the board does not return to its original state. A dxs or dca error is logged to the domain and pcd reports an error to the platform log file. If the error is recoverable, you can retry the command. If it is unrecoverable, you must reboot the domain in order to use that board.
|
Note - Platform administrators are restricted to the -c assign option. The option can only be used for boards with a status of assigned. It cannot be used for active boards. |
The system board must be in the assigned state to the domain from which it is being deleted. Use the showboards (1M) command to determine a board's state.
2. Type the following command:
|
domain-id - ID for a domain. Valid domain-ids are A-R and are not case sensitive. |
|
|
Specifies the transition of the board from the current configuration state to an assigned state. |
|
The following location forms are accepted:
moveboard performs tasks synchronously and does not return control to the user until the command is complete. You can only specify one location when using moveboard.
SB0 has been moved from its previous domain and assigned to domain C.
If moveboard fails, the board does not return to its original state. A dxs or dca error is logged to the domain and pcd reports an error to the platform log file. If the error is recoverable, you can retry the command. If it is unrecoverable, you must reboot the domain the board was in when the error occurred, in order to use that board.
The SMS setdefaults(1M) command removes all instances of a previously active domain.
Platform administrators can set domain defaults for all domains, but only one domain at a time. The domain must not be active and setkeyswitch must be set to off.
setdefaults removes all pcd entries except network information and log files. This includes removing the NVRAM and boot parameter data.
By default, you are asked whether you want to remove the NVRAM and boot parameter data. If you respond no, the data is preserved. If you use the -p option you are not prompted and the data is automatically preserved.
2. Type the following command:
|
domain-id - ID for a domain. Valid domain-ids are A-R and are not case sensitive. |
|
|
Preserves the NVRAM and boot parameter data without a prompt. |
For more information on setdefaults, refer to the setdefaults man page or the System Management Services (SMS) 1.6 Reference Manual.
Platform administrators can obtain board status for all domains.
The board status is displayed.
The following partial example for the Sun Fire 15K system shows the board information for a user with platform administrator privileges. All domains are visible. On a Sun Fire 12K system, nine domains would be shown.
Platform administrators can obtain domain status for all domains.
2. Type the following command:
|
domain-id - ID for a domain. Valid domain-ids are A-R and are not case sensitive. |
The status listing is displayed.
The following partial example for the Sun Fire 15K system shows the domain information for a user with platform administrator privileges. All domains are visible. On a Sun Fire 12K system, nine domains would be shown.
The Solaris environment uses the functions provided by a hardware time of day (TOD) chip to support Solaris system date and time. Typically, Solaris software reads the current system date and time at boot using a get TOD service. From that point forward, Solaris software either uses a high-resolution hardware timer to represent current date and time or, if configured, uses Network Time Protocol (NTP) to synchronize current system date and time to a (presumably more accurate) time source.
The SC is the only computer on the platform that has a real-time clock. The virtual TOD for domains is stored as an offset from that real-time clock value. Each domain can be configured to use NTP services instead of setdate (1M) to manage the running system date and time. For more information on NTP, see Configuring NTP or refer to the xntpd(1M) man page in the man Pages(1M): System Administration Commands section of the Solaris 9 Reference Manual Collection.
|
Note - NTP is a separate package that must be installed and configured on the domain in order to function as described. Use setdate on the domain prior to installing NTP. |
However system date and time is managed while Solaris software is running, an attempt is made to keep the boot-time TOD value accurate by setting the TOD when variance is detected between the current TOD value and the current system date and time.
Since the Sun Fire high-end system hardware provides no physical TOD chip for Sun Fire domains, SMS provides the time-of-day services required by the Solaris environment for each domain. Each domain is supplied with a TOD service that is logically separate from that provided to any other domain. This difference allows system date and time management on a Sun Fire high-end system domain to be as flexible as that provided by standalone servers. In the unlikely event that a domain needs to be set up to run at a time other than real-world time, the Sun Fire high-end system TOD service allows that domain to be configured without affecting the TOD values supplied to other domains running real world time.
Time settings are implemented using setdate(1M). You must have platform administrator privileges to run setdate. See All Privileges for more information.
setdate (1M) allows the SC platform administrator to set the system controller date and time values. After setting the date and time, setdate(1M) displays the current date and time for the user.
2. Type the following command:
Optionally, setdate(1M) can set a domain TOD. The domain's keyswitch must be in the off or standby position. You must have platform administrator privileges to run this command on the domain.
2. Type the following command:
showdate(1M) displays the current SC date and time.
2. Type the following command:
Optionally, showdate(1M) can display the date and time for a specified domain. Superuser or any member of a platform or domain group can run showdate.
2. Type the following command:
The NTP daemon, called xntpd(1M) for the Solaris OS, provides a mechanism for keeping the time settings synchronized between the SC and the domains. The OpenBoot PROM obtains the time from the SC when the domain is booted, and NTP keeps the time synchronized on the domain from that point on.
NTP configuration is based on information provided by the system administrator.
The NTP packages are compiled with support for a local reference clock. This means that your system can poll itself for the time instead of polling another system or network clock. The poll is done through the network loopback interface. The numbers in the IP address are 127.127.1.0. This section describes how to set the time on the SC using setdate, and then to set up the SC to use its own internal time-of-day clock as the reference clock in the ntp.conf file.
NTP can also keep track of the drift (difference) between the SC clock and the domain clock. NTP corrects the domain clock if it loses contact with the SC clock, provided that you have a drift file declaration in the ntp.conf file. The drift file declaration specifies to the NTP daemon the name of the file that stores the error in the clock frequency computed by the daemon. See the following procedure for an example of the drift file declaration in an ntp.conf file.
If the ntp.conf file does not exist, create it as described in the following procedure. You must have an ntp.conf file on both the SC and the domains.
1. Log in to the main SC as superuser.
2. Change to the /etc/inet directory and copy the NTP server file to the NTP configuration file:
3. Using a text editor, edit the /etc/inet/ntp.conf file created in the previous step.
The ntp.conf file for the Solaris 9 OS is located in /etc/inet.
The following is an example of server lines in the ntp.conf file on the main SC, to synchronize clocks.
5. Stop and restart the NTP daemon:
6. Log in to the spare SC as superuser.
7. Change to the /etc/inet directory and copy the NTP server file to the NTP configuration file:
8. Using a text editor, edit the /etc/inet/ntp.conf file created in the previous step.
The ntp.conf file for the Solaris 9 OS is located in /etc/inet.
The following is an example of server lines in the ntp.conf file on the spare SC, to synchronize clocks.
9. Stop and restart the NTP daemon:
10. Log in to each domain as superuser.
11. Change to the /etc/inet directory and copy the NTP client file to the NTP configuration file:
12. Using a text editor, edit the /etc/inet/ntp.conf file created in the previous step.
The ntp.conf file for the Solaris 9 OS is located in /etc/inet.
For the Solaris 9 OS, you can add lines similar to the following to the /etc/inet/ntp.conf file on the domains:
14. Change to the initialization directory, and stop and restart the NTP daemon on the domain:
NTP is now installed and running on your domain. Repeat Step 10 through Step 14 for each domain.
For more information on the NTP daemon, refer to the xntpd(1M) man page in the man Pages(1M): System Administration Commands section of the Solaris 9 Reference Manual Collection.
Each configurable domain has a virtual ID PROM that contains identifying information about the domain, such as hostID and domain Ethernet address. The hostID is unique among all domains on the same platform. The Ethernet address is world unique.
Sun Fire high-end system management software provides a virtual ID PROM for each configurable domain containing identifying information that can be read, but not written, from the domain. The information provided meets the requirements of the Solaris environment.
SMS provides the flashupdate(1M) command to update the Flash PROM in the system controller (SC), and the Flash PROMs in a domain's CPU and MaxCPU boards after SMS software upgrades or applicable patch installation. flashupdate displays both the current Flash PROM and the flash image file information prior to any updates.
For more information and examples, refer to the flashupdate man page.
This section briefly describes the configuration services available to the domain administrator.
The addboard, deleteboard, and moveboard commands offer more functionality to the domain administrator than to the platform administrator.
1. Log in to the SC as a domain administrator for that domain.
|
Note - For the domain administrator to add a board to a domain, that board must appear in the domain's available component list. |
The system board must be in the available or assigned state to the domain to which it is being added. Use the showboards (1M) command to determine a board's state.
2. Type the following command:
|
domain-id - ID for a domain. Valid domain-ids are A-R and are not case sensitive. |
|
|
Specifies the transition of the board from the current configuration state to a new configuration state. |
|
Configuration states are as follows:
If the -c function option is not specified, the default expected configuration state is configure. For more detailed information on the configuration states, refer to the addboard(1M) man page.
Multiple locations are accepted.
The following location forms are accepted:
In this example, SB0, IO1, SB1, and IO2 have changed from being available to domain C to being assigned to it.
addboard performs tasks synchronously and does not return control to the user until the command is complete. If the board is not powered on or tested, specify the -c connect|configure option, then the command will power on the board and test it.
If addboard fails, the board does not return to its original state. A dxs or dca error is logged to the domain and pcd reports an error to the platform log file. If the error is recoverable, you can retry the command. If it is unrecoverable, you must reboot the domain in order to use that board.
1. Log in to the SC as a domain administrator for that domain.
The system board must be in the assigned or active state to the domain from which it is being deleted. Use the showboards (1M) command to determine a board's state.
2. Type the following command:
|
Specifies the transition of the board from the current configuration state to a new configuration state. |
|
If the -c function option is not specified, the default expected configuration state is unassign. For more detailed information on the configuration states, refer to the deleteboard(1M) man page.
Multiple locations are accepted.
The following location forms are accepted:
In this example, SB0 has changed from being assigned to the domain to being available to it.
If deleteboard fails, the board does not return to its original state. A dxs or dca error is logged to the domain and pcd reports an error to the platform log file. If the error is recoverable, you can retry the command. If it is unrecoverable, you must reboot the domain in order to use that board.
|
Note - You must have domain administrator privileges for both domains involved. |
1. Log in to the SC as a domain administrator for that domain.
The system board must be in the assigned or active state to the domain from which it is being deleted. Use the showboards (1M) command to determine a board's state.
2. Type the following command:
If the -c option is not specified, the default expected configuration state is configure. For more detailed information on the configuration states, refer to the moveboard(1M) man page.
The following location forms are accepted:
moveboard performs tasks synchronously and does not return control to the user until the command is complete. If the board is not powered on or tested, specify -c connect|configure; then, the command will power on the board and test it. You can only specify one location when using moveboard.
If moveboard fails, the board does not return to its original state. A dxs or dca error is logged to the domain and pcd reports an error to the platform log file. If the error is recoverable, you can retry the command. If it is unrecoverable, you must reboot the domain the board was in when the error occurred, in order to use that board.
The SMS setdefaults(1M) command removes all instances of a previously active domain.
Domain administrators can set domain defaults for all domains, but only one domain at a time. The domain must not be active and setkeyswitch must be set to off. setdefaults removes all pcd entries except network information, log files and, optionally, NVRAM and boot parameter data.
2. Type the following command:
|
domain-id - ID for a domain. Valid domain-ids are A-R and are not case sensitive. |
For more information on setdefaults, refer to the setdefaults man page or the System Management Services (SMS) 1.6 Reference Manual.
Domain administrators can obtain board status only for those domains for which they have privileges.
2. Type the following command:
The board status is displayed.
The following partial example shows the board information for a user with domain administrator privileges for domain A.
Domain administrators can obtain domain status only for those domains for which they have privileges.
2. Type the following command:
|
domain-id - ID for a domain. Valid domain-ids are A-R and are not case sensitive. |
The status listing is displayed.
The following partial example shows the domain information for a user with domain administrator privileges for domains newA, engB, and domainC.
Domain administrators can obtain board status only for those domains for which they have privileges.
2. Type the following command:
The device status is displayed.
The following partial example shows the device information for a user with domain administrator privileges for domain A.
Each Sun Fire high-end system domain has a virtual keyswitch. Like the Sun Enterprise server's physical keyswitch, the Sun Fire high-end system domain virtual keyswitch controls whether the domain is powered on or off, whether increased diagnostics are run at boot, and whether certain operations (for example, flash PROM updates and domain reset commands) are permitted.
Only domains configured with their virtual keyswitch powered on are booted, monitored, and subject to automatic recovery actions, should they fail.
Virtual keyswitch settings are implemented using setkeyswitch(1M). You must have domain administrator privileges for the specified domain in order to run setkeyswitch. See All Privileges for more information.
setkeyswitch (1M) changes the position of the virtual key switch to the specified value. pcd (1M) maintains the state of each virtual key switch between power cycles of the SC or physical power cycling of the power supplies.
setkeyswitch(1M) is responsible for loading the bootbus SRAM of all the configured processors. All the processors are started, with one processor designated as the boot processor. setkeyswitch(1M) loads OpenBoot PROM into the memory of the Sun Fire high-end system domain and starts OpenBoot PROM on the boot processor.
The primary task of OpenBoot PROM is to boot and configure the OS from either a mass storage device or from a network. OpenBoot PROM also provides extensive features for testing hardware and software interactively.
The setkeyswitch(1M) command syntax follows:
The following operands are supported:
For more information on ASR, see Automatic System Recovery (ASR).
Domain administrators can set the virtual keyswitch only for those domains for which they have privileges.
2. Type the following command:
showkeyswitch (1M) displays the position of the virtual keyswitch of the specified domain. The state of each virtual keyswitch is maintained between power cycles of the SC or physical power cycling of the power supplies by the pcd (1M). Superuser or any member of a platform or domain group can run showkeyswitch.
Domain administrators can obtain keyswitch status only for those domains for which they have privileges.
2. Type the following command:
Each domain has a virtual NVRAM containing OpenBoot PROM data, such as the OpenBoot PROM variables. OpenBoot PROM is a binary image stored on the SC in /opt/SUNWSMS/hostobjs which setkeyswitch downloads into domain memory at boot time. There is only one version of OpenBoot PROM for all domains.
SMS software provides a virtual NVRAM for each domain and allows OpenBoot PROM full read/write access to this data.
The only interface available to read from or write to most NVRAM variables is OpenBoot PROM. The exceptions are those OpenBoot PROM variables which must be altered in order to bring OpenBoot PROM up in a known working state, or to diagnose problems that hinder OpenBoot PROM from coming up. These variables are not a replacement for the OpenBoot PROM interface.
These limited number of OpenBoot PROM variable values in the domain NVRAM are readable and writable from SMS using setobpparams(1M). You must have domain administrator privileges to run set/showobpparams. If you change variables for a running domain, you must reboot the domain in order for the changes to take effect.
|
Note - Only experienced system administrators who are familiar with OpenBoot PROM commands and their dependencies should attempt to use setobpparams in any manner other than that described. |
setobpparams(1M) sets and gets a subset of a domain's virtual NVRAM variables and REBOOTINFO data using the following syntax.
|
domain-id - ID for a domain. Valid domain-ids are A-R and are not case sensitive. |
param=value is one of the following variables and its corresponding value:
|
When set to false, the default boot device is specified by boot-device and the default boot file by boot-file. If set to true, OpenBoot PROM runs in diagnostic mode, and you must set either diag-device or diag-file to specify the correct default boot device or file. These default boot device and file settings cannot be set using setobpparams. Use setenv(1) in OpenBoot PROM. |
|||
|
When set to true, the domain boots automatically after poweron or reset-all. The boot device and boot file used are based on the settings for diag-switch (see above). Neither boot-device nor boot file can be set using setobpparams. If the ok prompt is unavailable during such as a repeated panic, use setobpparams to set auto-boot? to false. When the auto-boot? variable is set to false using setobpparams, the reboot variables are invalidated. In addition, the system will not boot automatically and will stop at OpenBoot PROM. At that point, you can set new NVRAM variables. See To Recover From a Repeated Domain Panic. |
|||
|
Firmware security level. Valid variable values for security-mode are: |
|||
|
When set to true, this variable executes commands in NVRAMRC during system startup. |
|||
|
When set to true, this variable includes name fields for plug-in device FCodes. |
The following is an example of how setobpparams can be useful.
In the following example, domain A encounters repeated panics caused by a corrupted default boot disk.
1. Log in to the SC with domain administrator privileges.
|
Note - Most, but not all, shells require using single quotes around the variable values to prevent the question mark from being treated as a special character. |
4. Once the domain has come up to the OK prompt, set NVRAM variables to a new uncorrupted boot-device.
|
A user-defined alias you created. The boot device must correspond to the bootable disk on which you have installed the OS. |
5. Now that you have set up a new alias for your boot device, boot the disk by typing:
For more information on OpenBoot variables, refer to the OpenBoot 4.x Command Reference Manual.
Domain administrators can set the OpenBoot PROM variables only for those domains for which they have privileges.
2. Type the following command:
security-mode has been set to full. All commands except go require a password on domain A. You must reboot a running domain in order for the change to take effect.
Domain administrators can set the OpenBoot PROM variables only for those domains for which they have privileges.
2. Type the following command:
|
domain-id - ID for a domain. Valid domain-ids are A-R and are not case sensitive. |
SMS NVRAM updates are supplied to OpenBoot PROM at OpenBoot PROM initiation (or domain reboot time). For more information refer to the OpenBoot PROM 4.x Command Reference Manual.
In most situations, hardware failures that cause a domain crash are detected and eliminated from the domain configuration either by POST or OpenBoot PROM during the subsequent automatic recovery boot of the domain. However, there can be situations where failures are intermittent or the boot-time tests are inadequate to detect failures that cause repeated domain failures and reboots. In those situations, Sun Fire high-end system management software uses configurations or configuration policies supplied by the domain administrator to eliminate hardware from the domain configuration in an attempt to get a stable domain environment running.
The following commands can be run by either platform or domain administrators. Domain administrators are restricted to the domains for which they have privileges.
setbus(1M) dynamically reconfigures bus traffic on active expanders in a domain to use either one centerplane support board (CSB) or both. Using both CSBs is considered normal mode. Using one CSB is considered degraded mode.
setbus resets any boards that are powered on but not active. Any attach-ready state is lost. For more information on attach-ready states, refer to the System Management Services (SMS) 1.6 Dynamic Reconfiguration User Guide.
You must have platform administrator privileges or domain privileges for the specified domain in order to run setbus.
This feature allows you to swap out a CSB without having to power off the system. Valid buses are:
Domain administrators can set the bus only for those domains for which they have privileges.
2. Type the following command:
For more information on reconfiguring bus traffic, refer to the setbus(1M) man page.
showbus(1M) displays the bus configuration of expanders in active domains. This information defaults to displaying configuration by slot order. Any member of a platform or domain group can run showbus.
2. Type the following command:
For more information on reconfiguring bus traffic, refer to the showbus(1M) man page.
| System Management Services (SMS) 1.6 Administrator Guide | 819-4660-10 |
|
Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.
To Set Up the Available Component List