| System Management Services (SMS) 1.2 Administrator Guide |
|
| System Management Services (SMS) 1.2 Administrator Guide |
|
| C H A P T E R 4 |
SMS 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 operating environment. Each domain is insulated from the other domains. Continued operation of a domain is not affected by any software failures in other domains nor by most hardware failures in any other domain.
The system controller (SC) supports commands that let you logically group system boards into dynamic system domains , or simply domains , which are able to run their own operating system 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 operating system 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.
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 15K system provides.
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 15K DCU's are:
CPU/Memory board
Sun Fire HsPCI I/O assembly (HPCI)
Sun Fire MaxCPU board (MCPU)
Sun Fire Link wPCI board (WPCI)
Sun Fire 15K hardware requires the presence of at least one of the two types of boards containing CPUs and memory, plus at least one of the I/O board types in each configured domain. csb, exb boards and the SC are not DCUs.
You can create a domain out of any group of system boards, provided the following conditions are met:
The boards are present and not in use in another domain.
At least one board has a CPU and memory.
At least one is an I/O board.
At least one board has a network interface.
The boards have sufficient memory to support an autonomous domain.
The name you give the new domain is unique (as specified in the addtag (1M) command).
You have an idprom.image file for the domain that was shipped to you by the factory. If your idprom.image file has been accidentally deleted or corrupted and you do not have a backup, contact your Sun field support representative.
There must be at least one boot disk connected to one of the boards that will be grouped together into a domain. Alternatively, if a domain does not have its own disk, there must be at least one network interface so that you can boot the domain from the network.
The assignment of DCUs to a domain is the result of one of three logical operations acting upon a DCU (system board):
Adding the board (from no-domain ) to a domain
Removing the board from a domain (leaving the board in no-domain )
Moving the board from one domain to another
Although there are logically three DCU assignment operations the underlying implementation is based upon four domain configuration operations:
Adding a board to an inactive domain
Removing a board from an inactive domain
Adding a board to an active domain
Removing a board from an active domain
The first two domain configuration operations apply to inactive domains, that is, to domains that are not running software. These operations are called static domain configuration operations. The latter two domain configuration operations apply to active domains, that is, those running 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 operating environment control. The Sun Fire 15K dynamic reconfiguration (DR) project 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.2 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 provides for adding or removing boards from an active (running) domain, (dynamic domain configuration). 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 domain(s) have local automatic DR capabilities or not.
SMS provides for the addition or removal of a board from an inactive domain, such as, static domain configuration using addboard , deleteboard, and moveboard . For more information, refer to the System Management Services (SMS) 1.2 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 15K resources to produce the most effective utilization. For more information on DR, refer to the System Management Services (SMS) 1.2 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 domain(s). 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.
Update the domain configuration available component list
Update the board available component list state for each board to show the domain to which it is now available
Notify dxs of boards added to their respective domain's available component list
dxs 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.
The following location forms are accepted:
The following is an example of making boards at SB0, IO1, and IO2 available to domain A:
At this point the platform administrator can 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 15K 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 Note - Before proceeding, see Domain Configuration Requirements. If the system configuration must be changed to meet any of these requirements, call your service provider. |
|
is the current name assigned to the domain using addtag (1M). |
|
|
is the new name you want to give to the domain. It should be unique among all domains controlled by the SC. |
The following is an example of naming Domain A to dmnJ :
|
Note Note - Platform administrators are restricted to using the -c assign option and only for available not active boards. |
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.
The following location forms are accepted:
SB0, IO1, and IO2 have now gone 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 command fails the board does not return to its original state. A dxs or dca error is logged to the domain. If the error is recoverable you can retry the command. If it is unrecoverable, you will need to reboot the domain in order to use that board.
|
Note Note - Platform administrators are restricted to using the -c unassign option and only for assigned not 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.
|
specifies the transition of the board from the current configuration state to a new unassign ed state. |
|
|
is the board (DCU) location. Multiple locations are accepted. |
The following location forms are accepted:
SB0 has now gone from being assigned to the domain to being available to it.
If the command fails the board does not return to its original state. A dxs or dca error is logged to the domain. If the error is recoverable you can retry the command. If it is unrecoverable, you will need to reboot the domain in order to use that board.
|
Note Note - Platform administrators are restricted to the -c assign option and only for assigned not 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.
|
is the current name assigned to the domain using addtag (1M). |
|
|
specifies the transition of the board from the current configuration state to an assign ed 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 the command fails the board does not return to its original state. A dxs or dca error is logged to the domain. If the error is recoverable you can retry the command. If it is unrecoverable, you will need to reboot the domain in order to use that board.
Platform administrators can obtain board status for all domains.
The board status is displayed.
The following partial example shows the board information for a user with platform administrator privileges. All domains are visible.
Platform administrators can obtain domain status for all domains.
The status listing is displayed.
The following partial example shows the domain information for a user with platform administrator privileges. All domains are visible.
The Solaris environment uses the functions provided by a hardware time of day (TOD) chip to support Solaris system date/time. Typically Solaris software reads the current system date/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/time or, if configured, uses Network Time Protocol (NTP) to synchronize current system date/time to a (presumably more accurate) time source.
The SC is the only computer on the platform that has a realtime clock. The virtual TOD for domains is stored as an offset from that realtime clock value. Each domain can be configured to use NTP services instead of setdate (1M) to manage the running system date/time, however, the SC should not use NTP to set its clock. If the SC uses NTP, no offset adjustments will be made and the virtual TOD values stored on the domain will get skewed. 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 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/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/time.
Since the Sun Fire 15K 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/time management on a Sun Fire 15K 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 15K 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 in order 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.
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.
showdate (1M) displays the current SC date and time.
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 .
The NTP daemon, x ntpd(1M) for the Solaris 9 05/02 operating environment, 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.
|
Note Note - Do not use NTP to set the SC clock. It should only be used on domains. For more information see Virtual Time of Day. |
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 below. 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 05/02 operating environment 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 05/02 operating environment 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 05/02 operating environment is located in
/etc/inet
.
For the Solaris 9 05/02 operating environment, you can add lines similar to the following to the /etc/inet/ntp.conf on the domains:
14. Change to the initialization directory, 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 05/02 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 15K 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.
|
Note Note - Once you have updated the FPROM(s) you must reset the SC using the reset-all command at the OpenBoot PROM (ok) prompt. |
For more information and examples, refer to the flashupdate man page.
This section briefly goes over the configuration services available to the domain administrator.
The domain administrator has been given far more capability with regard to the addboard , deleteboard , and moveboard commands.
1. Log in to the SC as a domain administrator for that domain.
|
Note Note - In order for the domain administrator to add a board to a domain, that board must appear in the domain 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.
|
is the current name assigned to the domain using addtag (1M). |
|
|
specifies the transition of the board from the current configuration state to a new configuration state. |
|
Configuration states are: assign , connect , or configure . If the -c function option is not specified, the default expected configuration state is configure .
Multiple locations are accepted.
The following location forms are accepted:
SB0, IO1, and IO2 have now gone 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.
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.
|
specifies the transition of the board from the current configuration state to a new configuration state. |
|
Configuration states are: unconfigure , disconnect , or unassign . If the -c option is not specified, the default expected configuration state is unassign .
Multiple locations are accepted.
The following location forms are accepted:
SB0 has now gone from being assigned to the domain to being available to it.
|
Note 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.
|
is the current name assigned to the domain using addtag (1M). |
|
|
specifies the transition of the board from the current configuration state to a new configuration state. |
|
Configuration states are: assign , connect , or configure . If the -c option is not specified, the default expected configuration state is configure .
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 .
Domain administrators can obtain board status only for those domains for which they have privileges.
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.
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 .
sc0:sms-user:> showplatform ... Domain Solaris Hostname Domain Status newA sun15-b0 Powered Off engB sun15-b1 Keyswitch Standby domainC sun15-b2 Running OBP |
Domain administrators can obtain board status only for those domains for which they have privileges.
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 15K domain has a virtual keyswitch. Like the Sun
Enterprise servers physical keyswitch, the Sun Fire 15K domain virtual keyswitch controls whether the domain is powered on or off, whether increased diagnostics are run at boot, 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 all the configured processors' bootbus SRAM. 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 15K system domain and starts OpenBoot PROM on the boot processor.
The primary task of OpenBoot PROM is to boot and configure the operating system 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:
on
From the off or standby position, on powers on all boards assigned to the domain (if not already powered on). Then the domain is brought up. Depending on the size, configuration and diagnostic settings of the domain, this will take approximately 20 minutes.
From the diag position, on is nothing more than a position change, but upon the next reboot of the domain power on self-test (POST) is not invoked with verbosity and the diag level is set to its maximum.
From the secure position, on restores write permission to the domain.
standby
From the off position, standby powers on all boards assigned to the domain (if not already powered on).
From the on , diag , or secure position, standby optionally causes an Are you sure? prompt and the domain gracefully shuts down. The boards remain fully powered.
off
From the on , diag , or secure position, off optionally causes an Are you sure? prompt, and all boards are put into low-power mode.
From the standby position, off puts all boards into low-power mode.
diag
From the off or standby position, diag powers on all boards assigned to the domain (if not already powered on). Then the domain is brought up just as in the on position, except that POST is invoked with verbosity and the diag level is set to its maximum.
From the on position, diag is nothing more than a position change, but upon the next reboot of the domain, POST is invoked with verbosity and the diag level set to its maximum.
From the secure position, diag restores write permission to the domain and upon the next reboot, POST is invoked with verbosity and the diag level is set to its maximum.
secure
From the off or standby position, secure powers on all boards assigned to the domain (if not already powered on). Then the domain is brought up just as in the on position, except that the secure position removes write permission to the domain. For example, flashupdate and reset will not work.
From the on position, secure removes write permission to the domain (as described above). From the diag position, secure removes write permission to the domain (as described above), and on the next reboot of the domain POST is invoked with verbosity and the diag level set to its normal values.
Domain administrators can set the virtual keyswitch only for those domains for which they have privileges.
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.
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.
For most NVRAM variables, the only interface available to read or write them 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 bring 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 Note - Only experienced system administrators, 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.
|
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 need to 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 power-on 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 . In the event the OK prompt is unavailable, 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, the system will not boot automatically and will stop in Open Boot PROM where new NVRAM variables can be set. 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 start-up. |
|||
|
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.
Say domain A encounters repeated panics caused by a corrupted default boot disk.
1. Log in to the SC with domain administrator privileges.
4. Once the domain has come up to the OK prompt set NVRAM variables to a new non-corrupted boot-device.
|
is a user-defined alias you created. The boot device must correspond to the a bootable disk on which you have installed the operating environment. |
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.
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.
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 15K 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.
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.
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 0-17. Any member of a platform or domain group can run showbus .
Domain administrators can set the bus only for those domains for which they have privileges.
For more information on reconfiguring bus traffic, refer to the showbus (1M) man page.
| System Management Services (SMS) 1.2 Administrator Guide | 816-3267-10 |
|
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.
