Sun SPARC® Enterprise MX000 Server Administration ES-411 M9000

Sun SPARC Enterprise MX000
Server Administration
ES-411
M9000
Student Guide
Sun Microsystems, Inc.

UBRM03-195
500 Eldorado Blvd.
Broomfield, CO 80021
U.S.A.
Revision C.1
Copyright 2010 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved.
This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and
decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of
Sun and its licensors, if any.
Third-party software, including font technology, is copyrighted and licensed from Sun suppliers.
Sun, Sun Microsystems, the Sun logo, Solaris, Sun Fire, Sun StorageTek, Java, Sunsolve, Sun4U, OpenBoot, Sun Enterprise, and Sun
StorEdge are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and
other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd.
ORACLE is a registered trademark of Oracle Corporation.
Adobe is a registered trademark of Adobe Systems, Incorporated.
Federal Acquisitions: Commercial Software Government Users Subject to Standard License Terms and Conditions
Export Laws. Products, Services, and technical data delivered by Sun may be subject to U.S. export controls or the trade laws of other
countries. You will comply with all such laws and obtain all licenses to export, re-export, or import as may be required after delivery to
You. You will not export or re-export to entities on the most current U.S. export exclusions lists or to any country subject to U.S. embargo
or terrorist controls as specified in the U.S. export laws. You will not use or provide Products, Services, or technical data for nuclear, missile,
or chemical biological weaponry end uses.
DOCUMENTATION IS PROVIDED AS IS AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS, AND

WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE
LEGALLY INVALID.
THIS MANUAL IS DESIGNED TO SUPPORT AN INSTRUCTOR-LED TRAINING (ILT) COURSE AND IS INTENDED TO BE
USED FOR REFERENCE PURPOSES IN CONJUNCTION WITH THE ILT COURSE. THE MANUAL IS NOT A STANDALONE
TRAINING TOOL. USE OF THE MANUAL FOR SELF-STUDY WITHOUT CLASS ATTENDANCE IS NOT RECOMMENDED.
Export Control Classification Number (ECCN) assigned: 14 August 2006
Please
Recycle
Copyright 2010 Sun Microsystems Inc., 4150 Network Circle, Santa Clara, California 95054, Etats-Unis. Tous droits rservs.
Ce produit ou document est protg par un copyright et distribu avec des licences qui en restreignent lutilisation, la copie, la distribution,
et la dcompilation. Aucune partie de ce produit ou document ne peut tre reproduite sous aucune forme, par quelque moyen que ce soit,
sans lautorisation pralable et crite de Sun et de ses bailleurs de licence, sil y en a.
Le logiciel dtenu par des tiers, et qui comprend la technologie relative aux polices de caractres, est protg par un copyright et licenci
par des fournisseurs de Sun.
Sun, Sun Microsystems, le logo Sun, Solaris, Sun Fire, Sun StorageTek, Java, Sunsolve, Sun4U, OpenBoot, Sun Enterprise, et Sun StorEdge
sont des marques de fabrique ou des marques dposes de Sun Microsystems, Inc. aux Etats-Unis et dans dautres pays.
Toutes les marques SPARC sont utilises sous licence sont des marques de fabrique ou des marques dposes de SPARC International, Inc.
aux Etats-Unis et dans dautres pays. Les produits portant les marques SPARC sont bass sur une architecture dveloppe par Sun
Microsystems, Inc.
UNIX est une marques dpose aux Etats-Unis et dans dautres pays et licencie exclusivement par X/Open Company, Ltd.
ORACLE est une marque dpose registre de Oracle Corporation.
Adobe est une marque enregistree de Adobe Systems, Incorporated.
Lgislation en matire dexportations. Les Produits, Services et donnes techniques livrs par Sun peuvent tre soumis aux contrles
amricains sur les exportations, ou la lgislation commerciale dautres pays. Nous nous conformerons lensemble de ces textes et nous
obtiendrons toutes licences dexportation, de r-exportation ou dimportation susceptibles dtre requises aprs livraison Vous. Vous
nexporterez, ni ne r-exporterez en aucun cas des entits figurant sur les listes amricaines dinterdiction dexportation les plus courantes,
ni vers un quelconque pays soumis embargo par les Etats-Unis, ou des contrles anti-terroristes, comme prvu par la lgislation
amricaine en matire dexportations. Vous nutiliserez, ni ne fournirez les Produits, Services ou donnes techniques pour aucune utilisation
finale lie aux armes nuclaires, chimiques ou biologiques ou aux missiles.
LA DOCUMENTATION EST FOURNIE EN LETAT ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET GARANTIES

EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES, DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y
COMPRIS NOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE A LA QUALITE MARCHANDE, A LAPTITUDE A UNE
UTILISATION PARTICULIERE OU A LABSENCE DE CONTREFAON.
CE MANUEL DE RFRENCE DOIT TRE UTILIS DANS LE CADRE DUN COURS DE FORMATION DIRIG PAR UN
INSTRUCTEUR (ILT). IL NE SAGIT PAS DUN OUTIL DE FORMATION INDPENDANT. NOUS VOUS DCONSEILLONS DE
LUTILISER DANS LE CADRE DUNE AUTO-FORMATION.
Please
Recycle
Table of Contents
Introduction to the Sun SPARC Enterprise MX000 Servers .......1-1

Objectives ........................................................................................... 1-1
Additional Resources ........................................................................ 1-3
Introducing the Sun SPARC Enterprise MX000 Servers .............. 1-5
Sun SPARC Enterprise MX000 Server Models ..................... 1-5
Server Technologies.................................................................. 1-5
Joint Product Development ..................................................... 1-6
High-End Servers Overview .......................................................... 1-15
M8000 and M9000 Server Capabilities................................. 1-15
Server Features ........................................................................ 1-16
Overview of Common Features and Components ..................... 1-20
System Architecture Terminology........................................ 1-20
Physical System Board Sets .................................................. 1-22
CPU and Memory ................................................................... 1-24
Memory Board Features........................................................ 1-26
I/O Features............................................................................ 1-27
Disk and Tape Options.......................................................... 1-28
XSCF Features......................................................................... 1-30
RAS Features........................................................................... 1-32
Fault Management Agent (FMA) ........................................ 1-35
Dynamic Reconfiguration (DR) ............................................ 1-35
M9000 Server Hardware Features ................................................. 1-43
M9000 Server With Expansion Cabinet Hardware ..................... 1-46
Exercise: Introducing the Sun SPARC Enterprise
MX000 Servers ............................................................................... 1-49
Task 1 Guided Tour ............................................................. 1-49
Exercise Summary................................................................... 1-49
Exercise Solutions ............................................................................ 1-50
Task 1 Guided Tour ............................................................. 1-50
Exercise Summary................................................................... 1-50
Sun SPARC Enterprise Architecture Overview .............................2-1
v
Copyright July 2009 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision C.1
Objectives ........................................................................................... 2-1
Operational Overview....................................................................... 2-4
The Jupiter Interconnect.................................................................... 2-5
Functionality .............................................................................. 2-7
CPU and Memory Board Operational Overview.......................... 2-8
SPARC64 VI and VII CPUs...................................................... 2-8
SPARC64 VI and VII Microprocessor Memory .................... 2-9
I/O Overview ................................................................................... 2-14
Mid-Range Server IOU........................................................... 2-14
High-End Server IOU ............................................................. 2-15
Board Nomenclature ....................................................................... 2-16
Extended System Controller Facility Unit (XSCFU) ................... 2-24
Global I2C Bus (Maintenance Bus) ....................................... 2-24
Service Processor Hardware Architecture ................................... 2-26
Service Processor Block Diagram ......................................... 2-26
Service Processor Component Breakdown ......................... 2-27
Exercise: Identifying the Architectural Components
of the MX000 Servers .................................................................... 2-29
Task ........................................................................................... 2-29
Exercise Summary............................................................................ 2-31
Task ........................................................................................... 2-32
Service Processor Architecture and
Configuration ................................................................................... 3-1
Objectives ........................................................................................... 3-1
Extended System Control Facility Functions................................. 3-5
Service Processor Functionality .............................................. 3-5
M8000 and M9000 Servers .................................................... 3-10
M9000 Server With Expansion Cabinet ............................... 3-11
Service Processor Comparison Summary .......................... 3-12
Serial Management Port Connections................................. 3-13
Configuring the Service Processor ................................................ 3-14
Gathering Required Information .......................................... 3-14
Initial Login to the Service Processor .................................. 3-15
Adding or removing a User Account.................................. 3-17
The adduser Command......................................................... 3-17
The deleteuser Command .................................................. 3-18
The password Command ...................................................... 3-19
Managing Server Administrative Privileges................................ 3-21
Access Control Privileges ...................................................... 3-21
The setprivileges Command ........................................... 3-23
The showuser Command ..................................................... 3-25
Setting the Service Processor Time...................................... 3-28
vi Sun SPARC Enterprise MX000 Server Administration

Configuring NTP.................................................................... 3-30
Setting the Locale .................................................................... 3-30
Resetting/Rebooting the XSCF ............................................ 3-31
Service Processor Networks ........................................................... 3-38
XSCF External Administration Network............................ 3-39
Network Parameters.............................................................. 3-40
Configuring the XSCF External Administration Network 3-40
The sethostname Command............................................... 3-43
The showhostname Command............................................. 3-44
The shownetwork Command............................................... 3-45
The setroute Command ..................................................... 3-48
The showroute Command .................................................... 3-49
Domain to Service Processor Communications Protocol
(DSCP) Network.................................................................. 3-51
Configuring the DSCP Network.......................................... 3-52
Configuring the XSCF ISN Network................................... 3-55
Enabling Basic Services ......................................................... 3-56
The setupplatform Command ......................................... 3-58
Firmware Features and Functions ................................................. 3-61
XSCF Control Package............................................................ 3-61
Firmware Update Overview ................................................ 3-62
Firmware Update Features ................................................... 3-63
Upgrading the Firmware ................................................................ 3-64
The version Command......................................................... 3-64
Firmware Import Procedure........................................................... 3-68
Importing Firmware Using the BUI ..................................... 3-68
The getflashimage Command .......................................... 3-70
The flashupdate Command............................................... 3-73
Exercise: Configuring the Service Processor................................ 3-76
Preparation.............................................................................. 3-77
Task 1 Creating a User ....................................................... 3-78
Task 2 Setting the Service Processor Time ...................... 3-79
Task 3 Configuring the XSCF External Network ........... 3-80
Task 4 Enabling Basic Network Services ......................... 3-81
Task 5 Configuring the DSCP Network .......................... 3-82
Task 6 Updating Firmware................................................ 3-83
Task 1 Creating a User ....................................................... 3-87
Task 2 Setting the Service Processor Time ...................... 3-88
Task 3 Configuring the XSCF External Network ........... 3-89
Task 4 Enabling Basic Network Services ......................... 3-90
Task 5 Configuring the DSCP Network .......................... 3-91
Task 6 Updating Firmware................................................ 3-92
Platform Administration and Configuration...................................4-1
vii
Objectives ........................................................................................... 4-1
Managing Sun SPARC Enterprise Servers ..................................... 4-5
Gathering Additional Service Processor Configuration
Information ............................................................................. 4-5
Managing XSCF User Accounts....................................................... 4-6
The setpasswordpolicy Command.................................... 4-7
The showpasswordpolicy Command .................................. 4-8
The disableuser Command............................................... 4-10
The enableuser Command ................................................. 4-11
The setautologout Command .......................................... 4-12
The showautologout Command ........................................ 4-13
The who Command ................................................................ 4-14
Managing XSCF User Accounts With LDAP............................... 4-15
Commands Used to Configure LDAP ................................. 4-15
General LDAP Setup Procedure ........................................... 4-16
The setlookup Command .................................................... 4-16
The showlookup Command .................................................. 4-17
The setldap Command......................................................... 4-18
The showldap Command ...................................................... 4-19
Managing Additional Network Settings ...................................... 4-22
The setsmtp and showsmtp Commands ........................... 4-23
Sample Command Output.................................................... 4-25
The setemailreport Command ........................................ 4-26
The showemailreport Command ...................................... 4-27
Configuring the Domain Name System ....................................... 4-28
Commands Used to Configure DNS.................................... 4-28
The setnameserver Command .......................................... 4-29
The shownameserver Command ......................................... 4-30
Configuring SNMP .......................................................................... 4-31
SNMP Traps............................................................................. 4-32
Setup Information ................................................................... 4-33
Commands Used to Configure SNMP................................. 4-34
The setsnmp Command......................................................... 4-34
The showsnmp Command ..................................................... 4-36
The setsnmpusm Command ................................................. 4-37
The setsnmpvacm Command................................................ 4-38
The setsunmc Command ...................................................... 4-40
The showsunmc Command .................................................... 4-42
Managing the Server Environment ............................................... 4-43
The setaltitude Command............................................... 4-44
The showaltitude Command............................................. 4-47
The showenvironment Command ...................................... 4-48
The setlocator Command ................................................. 4-50
The showlocator Command............................................... 4-51
The setpowerupdelay Commands .................................... 4-52
viii Sun SPARC Enterprise MX000 Server Administration

The showpowerupdelay Command.................................... 4-54
The setshutdowndelay Command.................................... 4-55
The showshutdowndelay Command.................................. 4-56
Viewing Hardware Status and Configurations ........................... 4-57
The showhardconf Command............................................. 4-58
The showstatus Command ................................................. 4-75
The replacefru Command ................................................. 4-76
The testsb Command.......................................................... 4-86
The prtfru Command.......................................................... 4-88
The cfgdevice Command ................................................... 4-92
The switchscf Command ................................................... 4-94
The clockboard Command ................................................. 4-96
Configuring Capacity on Demand ................................................ 4-97
COD Overview........................................................................ 4-97
COD Commands Summary .................................................. 4-98
Installing a COD License ...................................................... 4-99
Deleting a COD License ......................................................... 4-99
Reserving Licenses for Allocation ...................................... 4-100
Managing Headroom ........................................................... 4-100
Displaying COD Reservation Information........................ 4-101
Displaying COD License Status .......................................... 4-102
Displaying COD Usage Statistics........................................ 4-102
Using the XSCF Web ..................................................................... 4-103
Exercise: Administering and Configuring the MX000
Server ............................................................................................ 4-105
Task 1 Verifying Basic Network Settings ...................... 4-107
Task 2 Managing User Accounts .................................... 4-109
Task 3 Monitoring Environmental Factors.................... 4-112
Task 4 Viewing Hardware Status ................................... 4-114
Task 5 Managing Capacity on Demand (Optional) ...... 4-116
Exercise Summary.......................................................................... 4-118
Exercise Solutions .......................................................................... 4-119
Task 1 Verifying Basic Network Settings ....................... 4-119
Task 2 Managing User Accounts .................................... 4-121
Task 3 Monitoring Environmental Factors.................... 4-124
Task 4 Viewing Hardware Status ................................... 4-126
Task 5 Managing Capacity on Demand (Optional) ..... 4-129
Domain Administration and Configuration ....................................5-1
Objectives ........................................................................................... 5-1
Exploring Domains ............................................................................ 5-5
Domain Implementation.......................................................... 5-5
Domain Configuration ...................................................................... 5-6
Domain Configuration on the Entry-level Server ............... 5-7
Domain Configuration on the Mid-Range Servers .............. 5-7
ix
Domain Configuration on the High-End Servers ................ 5-7
Domain Configuration Unit (DCU)....................................... 5-8
Domain Configuration .......................................................... 5-14
Configuring Static Domains ........................................................... 5-15
The showboards Command................................................ 5-16
The setupfru Command ..................................................... 5-17
The setdcl Command.......................................................... 5-19
The addboard Command ..................................................... 5-22
The deleteboard Command............................................... 5-24
The moveboard Command ................................................... 5-26
The setdomainmode Command .......................................... 5-27
The setdomparam Command............................................... 5-29
Controlling Power to the Domain ................................................. 5-30
The poweron Command......................................................... 5-30
The poweroff Command ...................................................... 5-31
Accessing the Domain Console...................................................... 5-32
The console Command......................................................... 5-32
The showconsolepath Command ....................................... 5-34
Displaying the Domain Devices and Status................................. 5-35
The showdevices Command................................................ 5-35
The showdomainstatus Command..................................... 5-37
Resetting the Domain ...................................................................... 5-39
The sendbreak Command .................................................... 5-39
The reset Command ............................................................. 5-39
The OBP Device Tree....................................................................... 5-41
M8000 Uni-mode XSB 00-0 OBP Device Tre ...................... 5-67
Processor Device Mapping ............................................................. 5-73
Decoding Processor Locations on the MX000 Servers....... 5-73
Decoding I/O Card Locations on the High-End Servers. 5-82
External I/O Expansion Unit ................................................ 5-86
The Solaris OS................................................................................... 5-88
Configuring the Solaris OS in a New Domain............................. 5-89
Configuring Services for the Solaris 10 OS.......................... 5-89
Finishing the Installation ....................................................... 5-90
Exercise: Administering and Configuring the Domain.............. 5-91
Task 1 Building a Domain with a uni-mode XSB........... 5-92
Task 2 Building a Domain with a quad-mode XSB........ 5-94
Task 3 Building a Domain with two quad-mode XSBs . 5-96
Task 4 Sending a break signal to the OS.......................... 5-98
Exercise Solutions .......................................................................... 5-100
Task 1 Building a Domain with a uni-mode XSB......... 5-101
Task 2 Building a Domain with a quad-mode XSB...... 5-104
Task 3 Building a Domain with two quad-mode XSBs 5-106
Task 4 Sending a break signal to the OS........................ 5-108
x Sun SPARC Enterprise MX000 Server Administration

Dynamic Domain Reconfiguration..................................................6-1
Objectives ........................................................................................... 6-1
Introducing Dynamic Reconfiguration........................................... 6-5
Benefits of DR ............................................................................ 6-5
DR Operational Locations ................................................................ 6-6
Sun SPARC Enterprise Service Processor ............................. 6-6
Domain ....................................................................................... 6-6
DR Concepts ....................................................................................... 6-7
Preparing the Domain for DR Operations ............................ 6-7
DR attach Operation........................................................................ 6-8
DR attach States ...................................................................... 6-8
DR detach Operation........................................................................ 6-9
DR detach States ................................................................... 6-10
I/O Unit Considerations................................................................. 6-11
Multipathed I/O Configuration ........................................... 6-11
Detach-Safe and Suspend-Safe Devices.............................. 6-12
System Memory Considerations.................................................... 6-13
Detaching Permanent Memory............................................. 6-13
Swap Space .............................................................................. 6-14
CPU Considerations ........................................................................ 6-15
Bound Threads ........................................................................ 6-15
Processor Sets .......................................................................... 6-15
Dynamic Reconfiguration Operations and Resource Pools......
6-16
XSB Settings and Considerations................................................... 6-17
Configuration Policy Option ................................................. 6-17
Floating Board Option........................................................... 6-18
Omit-Memory Option ........................................................... 6-19
Omit-I/O Option..................................................................... 6-19
Performing DR From the XSCFU .................................................. 6-20
XSCF Commands .................................................................... 6-20
The addboard Command ..................................................... 6-21
The deleteboard Command............................................... 6-23
The moveboard Command ................................................... 6-25
Exercise: Performing DR Operations ............................................ 6-27
Task 1 - Performing Dynamic Reconfiguration.................. 6-27
Task 1 - Performing Dynamic Reconfiguration.................. 6-30
Data Collection and Fault Analysis.................................................7-1
Objectives ........................................................................................... 7-1
Log Archiving Functionality ............................................................ 7-5
Basic Features ............................................................................ 7-5
xi
Archived Data Types................................................................ 7-5
Log Archiving Functional Overview .................................... 7-6
Configuring Log Archiving .............................................................. 7-7
The setarchiving Command................................................ 7-7
The showarchiving Command ............................................ 7-9
Log Archiving Task Summary ............................................. 7-10
Configure the Log Archive Host .......................................... 7-10
Auditing ............................................................................................ 7-12
Audit Records.......................................................................... 7-12
Audit Trails .............................................................................. 7-12
Audit Events ........................................................................... 7-13
Audit Classes .......................................................................... 7-14
Audit Policy ............................................................................. 7-14
Performing Audit Tasks.................................................................. 7-15
The setaudit Command ...................................................... 7-15
The showaudit Command ................................................... 7-18
The viewaudit Command .................................................... 7-20
Audit Task Summary ............................................................ 7-23
The snapshot Command ............................................................... 7-25
Options and Parameters........................................................ 7-26
Operational Overview........................................................... 7-28
Modes of Operation ............................................................... 7-29
Sample Command Output.................................................... 7-30
Viewing Raw Snapshot Data................................................ 7-31
Viewing and Monitoring Logs ....................................................... 7-32
The showlogs Command ...................................................... 7-32
The showmonitorlog Command ........................................ 7-36
Fault Management Architecture.................................................... 7-37
Service Processor Implementation ....................................... 7-37
The fmd Daemon .................................................................... 7-38
The fmadm Command ............................................................ 7-39
The fmdump Command.......................................................... 7-40
The fmstat Command.......................................................... 7-46
Collecting Fault Data .............................................................. 7-48
FRU Replacement Guidelines ........................................................ 7-49
Backing up service processor information ......................... 7-50
Restoring service processor configuration information ... 7-52
Removing service processor information........................... 7-54
Collecting Data With Sun Explorer Software .............................. 7-56
Installing and Running the Sun Explorer Utility .............. 7-57
Viewing a Sun Explorer Capture......................................... 7-58
Gathering Escalation Information ................................................. 7-60
Providing General Information ............................................ 7-60
Providing Detailed Information ........................................... 7-60
Exercise: Collecting Data and Viewing Logs ............................... 7-61
Task 1 Configuring Log Archiving................................... 7-62
xii Sun SPARC Enterprise MX000 Server Administration

Task 2 Configuring Auditing ............................................ 7-64
Task 3 Creating a snapshot Archive ............................... 7-65
Task 4 Viewing Logs........................................................... 7-66
Task 5 Executing Sun Explorer ......................................... 7-67
Task 1 Configuring Log Archiving.................................... 7-69
Task 2 Configuring Auditing ............................................ 7-71
Task 3 Creating a snapshot Archive ............................... 7-72
Task 4 Viewing Logs........................................................... 7-73
Task 5 Executing Sun Explorer ......................................... 7-74
xiii
Module 1
Introduction to the Sun SPARC Enterprise

MX000 Servers
Objectives
Upon completion of this module, you should be able to:
Compare and contrast the five Sun SPARC Enterprise MX000 server
models
Differentiate hardware features of the Sun SPARC Enterprise M3000
entry-level server
Differentiate hardware features across the Sun SPARC Enterprise
MX000 mid-range server product line
Differentiate hardware features across the Sun SPARC Enterprise
MX000 high-end server product line
List the common features of all five Sun SPARC Enterprise MX000
server models
1-1
Objectives
Relevance
Discussion The information in this module is relevant to your job

because it provides an introduction to the Sun SPARC Enterprise MX000
! server models. The following questions are relevant to understanding the
?
concepts of this module:
How is each MX000 server model used?
What are some of the key features that differentiate the entry-level
M3000, the mid-range MX000 server models, and the high-end
MX000 server models?
1-2 Sun SPARC Enterprise MX000 Server Administration

Additional Resources
Additional resources The following references provide additional

information on the topics described in this module:
Sun Microsystems, Inc., Sun SPARC Enterprise
M3000/M4000/M5000/M8000/M9000 Servers XSCF Reference Manual:
XSCF Control Package (XCP) 1080, October 2008. Part number 820-
5872-xx.
M3000/M4000/M5000/M8000/M9000 Servers XSCF Users Guide,
October 2008. Part number 819-6202-xx.
Sun Microsystems, Inc., Sun SPARC Enterprise M3000/M4000/
M5000/M8000/M9000 Servers Administration Guide, January 2009. Part
number 819-3601-xx.
Sun Microsystems, Inc., Sun SPARC Enterprise M3000 Server
Overview Guide, January 2009. Part number 820-5579-xx.
Sun Microsystems, Inc., Sun SPARC Enterprise M3000 Server Site
Planning Guide, October 2008. Part number 820-5580-xx.
Sun Microsystems, Inc., Sun SPARC Enterprise M3000 Server Getting
Started Guide, October 2008. Part number 820-5581-xx.
Sun Microsystems, Inc., Sun SPARC Enterprise M3000 Server Safety
and Compliance Guide, October 2008. Part number 820-5582-xx.
Sun Microsystems, Inc., Sun SPARC Enterprise M3000 Server Service
Manual, January 2009. Part number 820-5683-xx.
Installation Guide, January 2009. Part number 820-5684-xx.
Sun Microsystems, Inc., Sun SPARC Enterprise M4000/M5000 Servers
Safety and Compliance Guide, April 2007. Part number 819-2203-xx.
Overview Guide, November 2008. Part number 819-2204-xx.
Site Planning Guide, November 2008. Part number 819-2205-xx.
Getting Started Guide, April 2007. Part number 819-2206-xx.
Service Manual, November 2008. Part number 819-2210-xx.
Introduction to the Sun SPARC Enterprise MX000 Servers 1-3


Installation Guide, November 2008. Part number 819-2211-xx.
Sun Microsystems, Inc., Sun SPARC Enterprise Equipment Rack
Mounting Guide, November 2008. Part number 819-5367-xx.
Sun Microsystems, Inc., Sun SPARC Enterprise M8000/9000 Servers
http://docs.sun.com

Introducing the Sun SPARC Enterprise MX000 Servers

The Sun SPARC Enterprise MX000 servers are a family of symmetric
multiprocessing (SMP) systems. They are binary-compatible servers for
mission-critical and high-performance computing applications.
The MX000 servers incorporate mainframe features such as dynamic

domains and, if properly configured, robust hardware redundancies to
provide advanced availability capabilities. The MX000 servers offer
unparalleled performance, scalability, and reliability, availability, and
serviceability (RAS) compared to other two- and four-processor socket
UNIX servers currently on the market.
Sun SPARC Enterprise MX000 Server Models

There are five distinct models of MX000 server. The servers are
categorized as entry-level, mid-range, or high-end servers. The M3000 is
an entry level server, the M4000 and M5000 are mid-range servers, and
the M8000, M9000, M9000 with Expansion Cabinet, are high-end servers.
All five server models run the latest version of the Solaris operating
system (OS).
Server Technologies
Each of the MX000 servers merges mainframe-like technologies for high
reliability and the associated know-how accumulated over time with the
high-speed technologies of supercomputers and the flexibility of UNIX
server development.
Resource Flexibility
Each M3000, M4000, M5000, M8000, M9000, and M9000 with Expansion
Cabinet server contains SPARC 64 VI or SPARC 64 VII
microprocessors, which contain a multicore architecture.
Error Isolation
The MX000 servers feature a robust fault isolation mechanism. If an error

does occur, the corresponding error can be corrected or isolated, possibly
without halting the server. This feature minimizes problems in many
cases, thereby improving job continuity.

Joint Product Development

The MX000 servers are the result of an alliance between Sun Microsystems
and Fujitsu. These servers:
Are Sun and Fujitsus next generation, entry-level, mid-range and
high-end server models
Have been jointly designed by Sun and Fujitsu
Are being jointly manufactured by Sun and Fujitsu
Run the Solaris 10 OS and are SPARC v9-compliant for binary
compatibility with SPARC-based Sun Fire and Fujitsu
PRIMEPOWER servers
Are fully compliant with Suns standards for software, storage, and
services
This alliance entails shared investment of MX000 servers product

development costs and has allowed Sun to invest more heavily in chip
multithreading (CMT) technology for future enterprise computing
products.

High-End Servers Overview

The Sun SPARC Enterprise M8000, M9000, and M9000 with Expansion
Cabinet high-end servers are designed with:
Price
Performance
Highest availability
Competitive reliability
Sophisticated RAS features
Scalability
M8000 and M9000 Server Capabilities

The M8000, M9000, and M9000 with Expansion Cabinet servers provide
the capabilities listed in Table 1-1.
Table 1-1 Sun SPARC Enterprise MX000 High-End Server Capabilities
Capability Description
Application acceleration Dual-core SPARC64 VI microprocessors

Quad-core SPARC64 VII microprocessors
High-speed Jupiter bus interconnect
Industry-standard Peripheral Component
Interconnect Express (PCI-E) I/O
RAS capabilities Redundancy for:

Power
Cooling
Service processors
Highly flexible
Modular building block architecture
configuration
(CMUs, IOUs)
World-class OS support Solaris 10 OS

Server Features
The M8000, M9000 and M9000 with Expansion Cabinet servers hardware
configuration includes the following components:
Centerplane
CPU/memory board(s) (CMU)
Two or Four processors per board
Sixteen or Thirty Two dimms per board
I/O board(s)
Eight PCI-E card slots
Eight PCI cassettes
Four HDD drives
Tape drive unit (optional), and DVD drive
Jupiter System bus
Symmetric multiprocessing (SMP), where any processor in the same
domain can connect to a single shared main memory
Two eXtended System Control Facility Unit (XSCFU_B) boards
known as the service processors, One Active, One Standby
Operator panel (OPNL)
Redundant power and cooling
Hot FRU removal/replacement capability for fan trays, power
supplies, service processors, CMUs, IOUs, DC-DC convertors
(DDCs)
I/O expansion with the Sun External I/O Expansion Unit
Note In many cases, field-replaceable units for the M8000, M9000, and
M9000 with Expansion Cabinet servers are designed with different size
dimensions when compared with the field-replaceable units in the M3000,
M4000 and M5000 servers.

The M8000 and M9000 Server Components
Table 1-2 summarizes the features of the high-end servers.
Table 1-2 Features of the Sun SPARC Enterprise M8000, M9000, and M9000 With
Expansion Cabinet Servers
M9000 With
Components M8000 M9000 Expansion
Cabinet
Centerplane Active Passive Passive

CMUs Four Eight Sixteen
Two or Four Two or Four Two or Four
processors processors processors
per CMU per CMU per CMU
16 or 32 16 or 32 16 or 32
dimms per dimms per dimms per
CMU CMU CMU
Supports 1- Supports 1- Supports 1-
GB, 2-GB, GB, 2-GB, GB, 2-GB,
and 4-GB and 4-GB and 4-GB
DIMMs DIMMs DIMMs
128-DDR2 256-DDR2 512-DDR2
DIMMs total DIMMs total DIMMs total
System Bus System Bus System Bus
Bandwidth Bandwidth Bandwidth
(memory) (memory) (memory)
184 GB/sec 368 GB/sec 737GB/sec
peak peak peak
IO units (IOUs) Four Eight Sixteen

32 PCI-E 64 PCI-E 128 PCI-E
card slots card slots card slots
16 HDD 32 HDD 64 HDD
drives drives drives
System Bus System Bus System Bus
Bandwidth Bandwidth Bandwidth
(I/O) 61 (I/O) 122 (I/O) 244
GB/sec peak GB/sec peak GB/sec peak

Expansion Cabinet Servers (Continued)
M9000 With
Cabinet
Service Two XSCFU_B Two XSCFU_B Two XSCFU_B
Processors Two XSCFU_C
Power supplies 9 units (no 15 units (no 30 units (no
expansion expansion expansion
cabinet) N+1 cabinet) N+1 cabinet) N+1
Three power Five Power Ten power
cords cords cords
Redundant 12 Fan Units:

cooling
(Air flow is Four 172mm 16 Fan Units: 32 Fan Units:
bottom to top) fans 16 172mm 32 172mm
Eight 60mm fans fans
fans N+1 N+1
N+1 Redundant Redundant
Redundant
Internal drives One DVD One DVD Two DVD

drive drive drives
One tape One tape Two tape
drive unit drive unit drive units
Power 10,500 Watts 21,300 Watts 42,600 Watts

Consumption
Volt Amphere 11,000 VA 22,400 VA 44,800 VA
Heat output 35834 BTUs/hr 72693 BTUs/hr 145385 BTUs/hr
Domains One to Sixteen One to Twenty One to Twenty
Four Four
Packaging Rack Rack Rack (x2)

Expansion Cabinet Servers (Continued)
M9000 With
Cabinet
Server 70.9 x 29.5 x 70.9 x 33.5 x 70.9 x 65.9 x
dimensions: 49.6 inches 49.6 inches 49.6 inches
height x width
x depth 180 x 75 x 180 x 85 x 180 x 167.4 x
126 mm 126 mm 126 mm
Weight 1540 lb 2072 lb 4145 lb

700 kg 940 kg 1880 kg
Clearance and
service area 31.5 inches 31.5 inches 31.5 inches
front 800 mm 800 mm 800 mm
Clearance and 31.5 inches 31.5 inches 31.5 inches

service area
rear 800 mm 800 mm 800 mm
Power Supports
Expansion Single Phase
Cabinet Dual power 70.9 x 12.5 x 70.9 x 12.5 x 70.9 x 12.5 x
Dimensions: feed and 49 inches 49 inches 49 inches
height x width Three phase
x depth power (Y(Star) 180 x 31.7 x 180 x 31.7 x 180 x 31.7 x
(Air flow is and Delta) 124.4 mm 124.4 mm 124.4 mm
from front to
rear)
Power
Expansion 770 lb 770 lb 770 lb
Cabinet 350 kg 350 kg 350 kg
weight

Overview of Common Features and Components

This section describes the common features of all five MX000 server
models. The common features and components include:
System architecture terminology
SPARC64 VI/VII microprocessors
Memory DIMMs
PCI-E cards
HDD, DVD, and DAT drives
Extended System Control Facility (XSCF) Concept
Physical size and layout differs
RAS features
Additional RAS features in High-End Servers
Fault Management Architecture (FMA)
Dynamic Reconfiguration (DR) features
System Architecture Terminology

Table 1-3 shows the architecture terms that are used to describe the
resources of the MX000 servers.
Table 1-3 Architecture Terms
Term Description
CPUM board Mid-range server board containing 2 processors.

Each CPUM contains 2 CPUs
Each CPU consists of two(SPARC64 VI) or
four(SPARC64 VII) cores.
Each core is dual threaded.
MEMB board Mid-range server board containing 8 DIMMs.

Table 1-3 Architecture Terms (Continued)
Term Description
CMU board High-end server board containing either 2 or 4
processors and 32 DIMM slots.
Each CPU consists of two(SPARC64VI) or
four(SPARC64 VII) cores.
Each core is dual threaded.
I/O Unit (IOU) board The IOU contains PCI card slots.
The mid-range server IOU provides 5 card slots and 2
network interfaces.
The high-end server IOU provides 8 card slots and 4
HDD drives.
Physical System Board (PSB) The mid-range server PSB consists of at least one
set CPUM, one MEMB, and one IOU. A PSB set can be
partially populated or fully populated.
The high-end server PSB consists of at least one CMU
and one IOU. The CMU board can be partially
populated or fully populated.
Extended System Board A Uni-mode XSB consists of up to two CPUMs, four

(XSB) MEMBs and an IOU in the M4000/M50000 servers.
A Quad-mode XSB consists of about one quarter of
the resources.
A Uni-mode XSB consists of the entire CMU and IOU
in the M8000/M9000 servers.
A Quad-mode XSB consists of about one quarter of
the resources.
Domain Component List Each domain has its own Domain Component List
(DCL) and Logical System (DCL).
Board (LSB)
Each of these DCLs contain 16 Logical System Board
(LSB) numbers ranging from 0 to 15.
Before any XSB can be added to any one domain, it
must first have an associated LSB number in the
corresponding DCL.

Physical System Board Sets

Each of the MX000 servers is capable of at least one PSB set. Specific
resources are associated with each PSB set. The lowest number PSB set is
given a number of 0 or 00 and the highest number PSB set possible is 15.
The M8000 has four PSB (PSB# 00, 01, 02, 03) sets that contain the
following:
PSB#00
CMU#0 and IUO#0
PSB#1
CMU#1 and IOU#1
PSB#2
CMU#2 and IOU#2
PSB#3
CMU#3 and IOU#3
The M9000-32 has eight PSB sets number 0 through 7, the M9000-64 has
sixteen PSB sets numbered 0 through 15.
CPU and Memory

In the entry-level M3000, the CPU and memory is located on the
motherboard.
In the MX000 mid-range servers, the CPUs are located on CPUM boards
and the memory is found on MEMB boards.
In the MX000 high-end servers, the CPUs and memory are located on the
same physical board, the CMU.

Note Mixing of CPUs running at different clock frequencies is

supported across the MX000 servers within a single domain or system.
All CPUs in the MX000 servers use the SPARC64 VI or SPARC64 VII
high-performance multiprocessor. The microprocessor implements an
instruction retry function allowing an operation to continue when an
error has been detected.
Multithreading Technology
The CPUs implement a combination of:

Chip Multi Processing (CMP), which provides multiple cores per
CPU
Chip Multi Threading (CMT), which provides multiple threads per
core
Vertical Multi Threading (VMT) technology, which allows multiple
threads to run in parallel using a time-sharing technique
The CPUs have two or four physical cores and each core has two strands
with VMT structures. This allows threads to run in parallel. The two
strands that belong to the same physical core share most of the physical
resources, while the physical cores do not share physical resources except
the Level 2 (L2) cache and system interface.

Features Summary
The SPARC64 VI microprocessor includes the following features:

Two SPARC V9 cores running at either 2.15 gigahertz (GHz),
2.28GHz or 2.4GHz. Current implementations are:
M4000 and M5000: 2.15GHz (5MB L2 cache)
M8000 and M9000: 2.28GHz (5MB L2 cache) or 2.4GHz (6MB L2
cache)
Dual-core CMT with two threads per core
The Sun4U architecture
128 kilobytes (Kbytes) of I-cache and 128 Kbytes of D-cache per core
The SPARC64 VII microprocessor includes the following features:

Two SPARC V9 cores running at either 2.4 gigahertz (GHz) or
2.52GHz. Current implementations are:
M3000: 2.52GHz (5MB L2 cache)
Quad-core CMT with two threads per core
The Sun4U architecture
64 kilobytes (Kbytes) of I-cache and 64 Kbytes of D-cache per core

Memory Board Features

The memory subsystem controls memory access and cache memory. The
memory subsystem uses double-data-rate 2 (DDR2) memory and can
implement up to eight-way interleaving, providing higher-speed memory
access.
The DDR2 memory dimms are 1-Gbyte, 2-Gbyte, or 4-Gbyte with the
following features:
Error Correcting Code (ECC) protection
Recovery from memory chip failures
Memory mirroring (optional)
Extended ECC memory support
Memory Mirroring
The memory mirror mode is supported for every pair of memory buses in
a CMU. If an error occurs in one bus, the memory mirror mode enables
continued operation using the other, non-defective bus. This feature is
optional and must be enabled by the system administrator.
Extended ECC Memory Support
Extended ECC, or Advanced ECC, is a technology that was used for the
NASA pathfinder mission to Mars. Extended ECC memory has the ability
to correct multibit memory errors and, in doing so, increases system
availability considerably.
Extended ECC operations are essentially the same as RAID for disk
subsystems. When writing data to the DIMM, a duplicate set of data in
the form of a checksum is written to another part of the memory
subsystem. If a memory failure occurs, then the data is immediately
recovered by re-calculating the data from the checksum information. This
procedure allows the system to mask single bit errors that standard ECC
memory can correct but also 2-, 3-, and 4-bit errors. In some cases, even a
whole DRAM chip failure simply results in a correctable error (CE).

I/O Features
The entry-level M3000 provides I/O through the motherboard and four
PCI-E I/O slots.
The mid-range and high-end servers provide I/O functionality using a

component called an Input/Output Unit (IOU).
The M4000 and M5000 servers upper four slots of the IOU support PCI-E
cards while the lower slot supports a single PCI-X card. Each IOU also
supports two Gigabit ethernet ports.
The M8000 and M9000 servers IOU has eight PCI-E card slots. Each IOU
also supports four HDD drives.
The MX000 mid-range and high-end servers support a mix of PCI-E and
PCI-X cards. The industry-standard PCI cards used are not hot-pluggable,
so the PCI cards are installed into a hot-pluggable PCI Cassette unit.
Table 1-4 summarizes the various I/O configurations.
Table 1-4 IOU and PCI Configurations
Max Number of
Server PCI Slots PCI-E PCI-X
IOUs
M3000 0 4 4 0
M4000 1 5 4 1
M5000 2 10 8 2
M8000 4 32 32 0
M9000 8 64 64 0
M9000 with 16 128 128 0
Expansion
Cabinet
Note The mid-range and high-end servers (but not entry-level) support
a Sun External I/O Expansion Unit that provides additional PCI slots.
Additional PCI-E or PCI-X slots can be accessed by installing a PCIB-EX
card into a PCI-E slot and connecting an external I/O Expansion Unit.
This I/O expansion unit can be ordered with PCI-E and/or PCI-X slots.

Disk and Tape Options

All MX000 mid-range and high-end servers support the insertion and
removal of PCI cards. PCI cards must be un-configured and disconnected
using the Solaris OS cfgadm command before the cards can be physically
removed.
Note For additional information, refer to the Sun SPARC Enterprise

ServersT M4000/M5000 System Service Manual and the Sun SPARC
Enterprise M8000/M9000 System Service Manual.
Supported Disk and Tape Devices
The MX000 servers currently support the disk and tape storage devices
listed in Table 1-5.
Table 1-5 Supported Disk and Tape Devices
Device Type Devices Supported
Disk arrays Sun StorageTek 9990

Sun StorageTek 6130
Sun StorageTek 9985
Sun StorageTek 3511
Sun StorageTek 6920
Sun StorageTek 3510
Sun StorageTek 6540
Sun StorageTek 3320
Sun StorageTek
Sun StorageTek 3120
FLX380
Sun StorageTek D240
Sun StorageTek 6140
Tape Sun StorageTek L8500
Libraries Sun StorageTek C2
Sun StorageTek
Sun StorageTek LTO-3
L1400M
Sun StorageTek LTO-2
Sun StorageTek L500
Sun StorageTek SDLT600
Sun StorageTek L700
Sun StorageTek C4

Note The list of supported devices is constantly changing and being

updated.
Sun External I/O Expansion Unit Support
The Sun External I/O Expansion Unit provides a host system with
additional slots for PCI cards. The single I/O boat configuration provides
six additional PCI-X or PCI-E slots. The dual I/O boat configuration
provides twelve additional PCI-X or PCI-E slots.
The I/O Expansion Unit chassis includes the centerplane and two
permanently attached internal AC cables.
No serviceable components are inside the chassis. If the centerplane or the

internal AC cables are damaged, the entire chassis (less the power supply
units [PSUs] and I/O boats) must be replaced.
Self-paced course This course only presents information about the Sun
External I/O Expansion Unit that is specific to the MX000 server models.
For additional training about the I/O Expansion Unit, the following Web-
based course is available:
WET-5393: Sun External I/O Expansion Unit Installation and Administration.

XSCF Features
The MX000 servers all use the XSCF to provide system monitoring and
control. This hardware component is called the Extended System Control
Facility unit (XSCFU).
Note For simplicity, the XSCFU is also referred to as the service

processor, and is referenced this way for the remainder of this module.
While input power is being supplied to the server, the XSCF firmware
constantly monitors and manages the server even if the power to domains
is turned off.
Service Processor Functionality
The service processor (XSCFU) provides the following functionality:

Access control to the platform
Monitoring of the platform and domain hardware
Creation of system domains
Power on and posting of system domains
System console capability
External network connectivity
Dynamic Reconfiguration of XSBs
Management of capacity on demand
Monitors the platform and domains for errors and faults
Monitors environmental sensors for the platform and domains
A TTY console for each domain
A browser-based user interface (BUI)
Remote messaging of various events

XSCF User Interfaces
Two types of interfaces for XSCF firmware are available:

A command-line interface (CLI) called the XSCF shell. The XSCF
shell provides the commands required to configure, monitor, and
maintain resources and services for the MX000 servers. This is the
main method for accessing the XSCF and configuring the MX000
servers.
A Browser User Interface (BUI) called the XSCF web. The BUI is
intended to provide commands to configure, monitor, and maintain
XSCF resources and services similar to the XSCF shell.

RAS Features
The RAS features designed into the MX000 servers are listed in Table 1-6.
Table 1-6 RAS Features Summary
Feature Description
Reliability System monitoring - Constantly monitors the server

to ensure that it is operating normally.
Environmental monitoring - Provides a historical
log of all pertinent environmental conditions and
error conditions when encountered.
Dynamic CPU resource de-allocation - Dynamically
re-allocates CPU resources into an OS using DR
without interrupting the applications that are
running. If a process has been bound to a specific
CPU, dynamic CPU de-allocation is not possible.
ECC address and data path protection - Provides
ECC protection for the address and data paths.
Referential Integrity check/recovery mechanism in
the processor - Helps to mitigate failures.
Alive check - Cooperates with the XSCF firmware to
periodically check if software, including the domain
OS, is running.
Status checking of components - Keeps checking the
status of each component to detect signs of an
imminent fault, such as system down occurrences.
Helps to prevent system failure.
Memory patrol - Periodically performs memory
patrol to detect memory errors. Prevents faulty areas
from being used. Helps to prevent system failures.

Table 1-6 RAS Features Summary (Continued)
Feature Description
Availability Redundant components - A strategy used to
improve availability. When one component fails, the
redundant component(s) ensure that services that
were delivered by the failed component continue to
be available. Power supplies and fans are examples
of redundant components in both systems.
Predictive failure analysis - Ability to maintain a log
and threshold of errors and take proactive recovery
actions that minimize the likelihood of a system
outage.
Limited single point of reboot failure (hardware) -
Limited single hardware point of failure prevents
any domain from rebooting the OS.
Fault isolation of the crossbar interconnect
Extended ECC memory support - Recovers from
memory chip failures. Dynamic Random Access
Memory (DRAM) failures result in a correctable
error.
Dual power grid capable - The alternating current
(AC) power subsystem is completely duplicated,
which allows a redundant connection to a different
power grid (not available on the M4000 or M5000
servers - although they do offer power supply
redundancy).
Automated email notification system - Ability of the
server to detect a problem and to send event
notification through email, the SNMP trap, the BUI
interface, or to remote system monitors.
Enhanced retry - Support of an enhanced retry and
degradation function for the detected faults.
Automatic system reboot - Shortening the system
downtime by using automatic system reboot.
XSCF collection of fault information -
The XSCF collects information about
faults, log files, configurations, and environmental
conditions.

Table 1-6 RAS Features Summary (Continued)
Feature Description
Serviceability First fault isolation - Based on in-line error detection
with the capability to detect errors within FRU
boundaries.
Error logging - Ability to immediately log errors.
Multistage alerts and reporting - Errors are logged
and reported to higher software levels and made
available to system management and remote
monitoring.
Directive maintenance - Ability to automatically
direct the maintenance activities of the service
personnel.
Concurrent maintenance (limited) - Ability to
perform maintenance activities while the system is
in operation.
Machine readable FRU identification (FRU-ID) -
Ability to electronically read FRU-ID information,
such as part numbers and serial numbers.
Application Specific Integrated Circuits (ASIC) and
processor built-in self-test (BIST) - Provide
chip (ASIC) and processor tests.
Dynamic system domains, including domain
isolation - Provide multiple domains. Each domain
is capable of running different OS instances and each
domain operates independently from other
domains.
System and FRU-level fault indicators, or light-
emitting diodes (LEDs) - Visually identify the
system status including FRU operational status and
service required.
XSCF firmware - Service processor firmware used
for platform administration, platform logging, and
service-related actions.

Fault Management Agent (FMA)

The Fault Management Agent (FMA) is incorporated by default into the
Solaris OS software that resides in a domain. In the MX000 servers the
service processor also has a communication path with the domain and
some fault management information is forwarded and diagnosed by the
service processor.
The service processor has a full-featured FMA implementation which

provides fault diagnosis and reconfiguration capabilities.
Dynamic Reconfiguration (DR)

Domains can have both Uni-mode XSBs and Quad-mode XSBs
dynamically reconfigured into and out of them. Extended System Boards
(XSBs) are used to create domains and also called Domain Configuration
Units (DCUs).
DR has three basic functions: add, delete, and move. These functions
allow you to:
Add Domain Configurable Units (DCUs) without stopping the OS to
manage domain resources (addboard).
Delete Domain Configurable Units (DCUs) without stopping the OS
to manage domain resources (deleteboard).
Move Domain Configurable Units (DCUs) without stopping the OS
to manage domain resources (moveboard).

M9000 Server Hardware Features

The M9000 server provides CMP/CMT scalability using up to
64 processor cores and flexible dynamic system domain configuration.
Figure 1-1 shows an image of the M9000 server.
Figure 1-1 Sun SPARC Enterprise M9000 Server With Power Cabinet

Table 1-7 on page 1-28 identifies the various hardware components found
in the M9000 server.
Table 1-7 Sun SPARC Enterprise M9000 Server Hardware
Component M9000
Centerplane Uses embedded application-specific integrated

circuits (ASIC) to support the system bus
crossbar switch (XBU).
The XBU is a high-throughput data transfer
bus between the CMU and IOU. The XBU has
duplicated bus routes. If one crossbar switch
has an error, the system can be restarted to
isolate the faulty switch, enabling the M9000
server to continue operation.
CMU boards As many as eight:

Each CMU contains four CPU module sockets.
Each CMU contains 32 DIMM slots.
IOU As many as eight:
Each IOU contains eight PCI-E (x8) slots.
Four HDD drive bays.
XSCFU_B Two (redundant):
Provides management and configuration
functions for the platform and domains.
Enables remote control and monitoring of the
server through an Internet connection.
Reports fault information to the system
administrator.
Power options Three power input options:
Single-phase (default)
Single-phase, dual-feed
Three-phase
Power supplies 15 (N+1)
System fans 16 fans per system (4 in the front and 12 in the
rear)

Table 1-7 Sun SPARC Enterprise M9000 Server Hardware (Continued)
Component M9000
Internal storage One DVD-ROM

One optional tape drive unit
Operator panel Yes

Exercise: Introducing the Sun SPARC Enterprise MX000 Servers
Exercise: Introducing the Sun SPARC Enterprise

MX000 Servers
This lab provides a guided tour of each server model. At the end of this
lab, you should be able to identify the major components of each server as
well as the major components of the lab environment.
Task 1 Guided Tour

Your instructor will provide a guided tour of the M3000, M4000, M5000,
M8000, and M9000 servers using Sunsolve access.
Exercise Summary
Discussion Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
Experiences
Interpretations
Conclusions

Exercise Solutions
Exercise Solutions
This section contains solutions for the exercise.
Task 1 Guided Tour

Your instructor will provide a guided tour of the M3000, M4000, M5000,
M8000, and M9000 servers using Sunsolve access.
Exercise Summary

!
?
Experiences
Interpretations
Conclusions
Applications

Exercise Solutions

Objectives
Module 2
Sun SPARC Enterprise Architecture

Overview
Objectives
Compare and contrast the Jupiter bus interconnect with bus
interconnects for Sun's predecessor mid-range and high-level server
product lines
Document the architectural similarities and differences across the
MX000 server product line
Classify and label architectural components across the entire MX000
server product line
Differentiate between uni-mode XSBs and quad-mode XSBs
Identify the terms used in nomenclature in the MX000 server line
Sun SPARC Enterprise Architecture Overview 2-1

Objectives
Relevance
Discussion The following questions are relevant to understanding the

Sun SPARC Enterprise server architecture:
!
? How do the MX000 servers differ from other Sun SPARC-based
servers?
What functions do the various application-specific integrated circuits
(ASICs) provide?
What resources are associated with a PSB set in uni-mode?
What resources are associated with a PSB set in quad-mode?
What components make up the Extended System Controller Facility
Unit (XSCFU) or service processor?


5872-xx.
number 819-3601-xx.
http://docs.sun.com

Operational Overview
The MX000 server architecture builds and improves upon the success of
the Sun SPARC Enterprise family of servers by using a new CPU and bus
architecture. This enhanced architecture includes:
New system bus architecture based on the Jupiter bus interconnect
also called the Jupiter link
An enhanced CPU architecture running at speeds of 2 GHz and
greater
Multicore, multithreaded CPUs
SPARC64 VI Dual Core, Dual Threaded Processors
SPARC64 VII Quad Core, Dual Threaded Processors
A new service processor (XSCFU) with a fault management daemon

The Jupiter Interconnect
The Jupiter Interconnect

The Jupiter interconnect is a high-speed system interconnect among the
CPU, memory, and I/O subsystems in entry-level M3000, the mid-range
servers, and the high-end servers. It provides superior memory and I/O
bandwidth, which helps the SPARC64 VI (Olympus-C processor) or the
SPARC64 VII (Jupiter processor) deliver superior performance.
The Jupiter interconnect provides as much as 7 times more system

bandwidth than in the previous generation of servers. Its maximum
theoretical bandwidth is 304.2 Gbytes per second with a latency of 258
nanoseconds (ns) for local transactions and 498 ns for remote transactions.
The Jupiter interconnect is central to the architecture found in the entry-

level M3000, the mid-range servers, and the high-end servers. shows an
example of the M3000 and how the Jupiter System Controller (JSC) ASIC
connects CPU to I/O. PCI-X cards are not supported on the
M3000.Functionality
The Jupiter interconnect provides a connection between the interconnect

devices (SPARC64 VI/VII processors, memory, and PCI bridges) and the
data path. The interconnect devices are interfaced to the data path using
the (Jupiter) System Controller (SC) ASIC.

CPU and Memory Board Operational Overview

CPU and memory are organized differently on the entry-level M3000,
mid-range and high-end servers.
In the entry-level M3000, the CPU and memory reside on a motherboard.
In the mid-range servers, CPUs reside on CPU modules (CPUMs) and

memory resides on memory boards (MEMBs) which plug onto a
motherboard.
In the high-end servers, both the CPUs and memory reside on a CPU
Memory unit (CMU). The CMU board is inserted into the chassis and
plugs into a centerplane.
SPARC64 VI and VII CPUs

The SPARC64 VI and SPARC64 VII CPU are high-performance, highly
integrated microprocessors. These processors implement a combination of
CMP (chip multiprocessing) and VMT (vertical multithreading). The
SPARC64 VI CPUs each have two physical cores and each core has two
strands (threads) with VMT structure, meaning that four strands are able
to run in parallel. The SPARC64 VII CPUs each have four physical cores
and each core has two strands (threads) with VMT structure. The Solaris
OS sees each strand as a complete processor. These CPUs interconnect
through the Jupiter bus which is scalable to 64 sockets.
Figure 2-1 on page 2-7 shows the SPARC64 VI and VII processor chip
block diagram. Each core has its own floating point unit (FPU) and data
cache (D$). They do share the same L2 cache, which can be 5 or 6 Mbytes.
Note The M3000 offers the SPARC64 VII CPU with two or four cores.
The M4000, M5000, M8000, and M9000 servers offer the SPARC64 VII
CPU with four cores. Each core runs two threads.
Note The SPARC64 VII CPU cores all share the L2 cache and each core
has 64KB of I-cache and 64 KB of D-cache.

Figure 2-1 SPARC64 VII and VI Processor Chip Block Diagram
SPARC64 VI and VII Microprocessor Memory

The DIMM modules supported in these servers are high-capacity, dual
side-mounted units. They are Double Data Rate II (DDR II) DIMMs. The
supported DIMM sizes are:
1-Gbyte DIMMs
2-Gbyte DIMMs
4-Gbyte DIMMs
DIMMs are installed in two groups of four on the M3000. The minimum
configuration of memory for the M3000 is 4 GB.
DIMMs are installed in sets of eight on a MEMB.
DIMMS are installed in two sets of 16 on a CMU.

You cannot mix larger DIMM sizes with smaller DIMM sizes in the same
group or set. The CMU board provides 16 A banks of memory and 16
B banks of memory. The largest size memory dimms are installed in the
A banks.
Memory Mirroring
The entry level M3000, the mid-range servers, and high-end servers
support memory mirroring. Memory mirroring operates by pairing
DIMMs together for both reads and writes. Mirroring divides the
available memory in half. Memory mirroring is turned off by default on
all systems.
On writes, the data and ECC are written to both halves of the pair. On
reads, data is read from both halves and the ECC is compared. Errors
during memory mirroring are handled as follows:
If both copies of the pair have correctable ECC and have matching
data, the data is returned.
If one copy has uncorrectable ECC and the other has correctable
ECC, the data is returned.
If both copies have uncorrectable ECC errors, an error data packet is
returned.
If both copies have correctable ECC, but the data does not match, an
error data packet is returned.
Memory mirroring is supported in uni-mode on the M3000.
Note The M3000 is not capable of quad-mode.
Memory mirroring is supported both in uni-mode and quad-mode XSBs

in the mid-range servers.
Memory mirroring is only supported in uni-mode on the high-end

servers. This is because in the high-end server models, there is striping
between the memory access controllers (MACs) on a CMU. In the mid-
range server models, there is no striping.
In the high-end models configured in quad-mode XSB mode, you get half
of MAC0 and MAC2 for XSB-0. This does not allow the memory mirror
mode because you can only mirror within a MAC.

In the mid-range servers configured in quad-mode XSB mode, you get

one full MAC per quad-mode XSB. This makes it possible for mirroring in
the mid-range servers.
Uni-mode and quad-mode XSBs are described later in this module.

Memory Access Controller

The mother board of the M3000 contains a MAC, each of the memory
boards (MEMBs) in a mid-range server contains a MAC, and the CMUs in
the high-end server contains four MACs. The MACs provide an interface
from memory to the JSC or SC ASICs.
High-End Server IOU

The IOU in the high-end servers supports only PCI-E cards. In Figure 2-2
you can see the layout of the IOUs in a high-end server. All of the
high-end servers use the same IOU board.
Figure 2-2 High-End Server IOU Block Diagram
Each I/O unit contains the following:

PCI cards Eight short PCI Express (PCI-E) (8-lane) slots.
Two OBERON chips.
PCI-E switches or bridges connected to the slots.

IOU PCI-E slots #0 and #4 support the IOU Device Mounting card A
(IOU A card). When installed, this PCI-E card provides two external
Gigabit ethernet ports for use by a domain. The IOU A card installed
in PCI-E slot #0 provides access to the HDD drives in HDD slots #0
and #1. The IOU A card installed in PCI-E slot #4 provides access to
the HDD drives in HDD slots #2 and #3.
IOU PCI-E slots #2 and #6 also support IOU A cards. When installed,
these cards act as an attachment point for the DVD and DAT.
Any one domain supports a maximum of six IOU A cards.

Board Nomenclature
Board Nomenclature
The boards in the MX000 servers are referenced with new terminology.
Before configuring the system, you should be familiar with the following
terms:
Physical System Board (PSB) set Consists of CPU, memory, and I/O
Specific boards are associated with specific with each PSB set
eXtended System Board (XSB)
Is the result of using your PSB in uni-mode (XX-0) with all of
the associated CPUs, memory boards, and IO being assigned to
the XSB
Is the result of using your PSB in quad-mode (XX-0, XX-1, XX-2,
XX-3) with the associated CPUs, memory boards, and IO being
divided among as many as four extents
The numbering scheme is based on the PSB number coming
first, followed by a dash and then the extent number.
Logical System Board (LSB) number To create domains, you must
first assign an LSB number to an XSB
There are 16 LSB numbers for every domain.
The LSB numbers range from 0 to 15.

Board Nomenclature
The High-End Servers

The M8000 server contains four PSB sets. The M9000 server contains eight
PSB sets. The M9000 server with Expansion Cabinet contains 16 PSB sets.
Each PSB set consists of:
One IOU containing:
Eight PCI-E slots
Four Disk Drive slots
One CPU Memory Unit (CMU) containing:
Two or Four CPUs
16 or 32 DIMMs
Configuring PSB#00 in uni-mode results in XSB#00-0 with the following

resources:
CMU#0
CPU#0
CPU#1
CPU#2
CPU#3
32 DIMMs
IOU#0
PCI-E slots 0, 1, 2, 3, 4, 5, 6, 7
HDD drive slots 0, 1, 2, 3

Board Nomenclature
Configuring a PSB#00 in quad-mode results in the following XSBs:

XSB 00-0 containing:
CMU#0/CPU#0
CMU#0 memory consisting of up to eight DIMMs
IOU#0 PCI-E slots 0 and 1
Access to HDD 0 and HDD 1 if an IOU A card is installed in
IOU#0 PCI-E slot # 0
Two Gigabit Ethernet interfaces if an IOU A card is installed in
CMU#0/CPU#1
CMU#0/CPU#2
CMU#0/CPU#3
High-End Server PSB numbers range from PSB#00 to PSB#15.

The M8000 has PSB#00 to PSB#03.
The M9000-32 has PSB#00 to PSB#07.
Note A uni-mode PSB#15 offers the same amount of resources as a uni-

mode PSB#00. Using PSB#15 in quad-mode results in the same resource
breakout as PSB#00 in quad-mode; only the PSB#s are different.

Board Nomenclature
Figure 2-3 shows a combination of uni-mode XSB and quad-mode XSBs

divided among four domains in a high-end server.
Figure 2-3 High-End Server uni-mode XSB and quad-mode XSB Block
Diagram

Extended System Controller Facility Unit (XSCFU)

The mid-range server architecture is designed to support one extended
system controller facility unit or service processor. The high-end server
architecture is designed to support two service processors.
The service processor acts as the:

I2C master
JTAG (Joint Test Action Group) controller
Monitor of power supplies
Interrupt handler
Resource for reset control
Global I 2C Bus (Maintenance Bus)

The MX000 servers use a global maintenance bus structure to monitor the
environmental integrity of the platform.
This monitoring structure is controlled by the service processor and uses

the I2C bus architecture.
The I2C bus monitors the server voltages, temperatures, and fan speeds.
In Figure 2-4 on page 2-17 you can see how the maintenance buses
interface within the system.

Figure 2-4 Maintenance Bus Block Diagram

Service Processor Hardware Architecture

The service processor is comprised of a variety of electrical components
and, in effect, is a small computer unto itself. This section describes the
service processor components and their functions.
Service Processor Block Diagram

Figure 2-5 provides a functional block diagram of the service processor
used in the MX000 servers. Following the figure (which represents an
MX000 mid-range server) is Table 2-1 on page 2-19 which provides details
on the components.
Figure 2-5 Service Processor Block Diagram for MX000 Servers

Service Processor Component Breakdown

Table 2-1 provides a list of the major components that make up the service
processor and lists the key features and functionality for each of the
components.
Table 2-1 Service Processor Component Breakdown
Component Details
Processor Freescale Motorola MPC8541E PowerQUICC III CPU

64 kilobyte (KB) L1 cache (32-KB I-cache and
D-cache)
256-KB L2 cache
Core speed: 533MHz
Supports 32-bit PCI bus, I2C bus, local bus, and
serial direct RAM (SDRAM) bus
FPGA Lattice Field Programmable Gate Array (FPGA)
Known as the MBCF-SCF (maintenance bus
control)
Interfaces to the MPC8541E local bus,
maintenance bus, and TTY bus
Monitors the PSU and UPS
Operating frequency: 340 MHz
Operating voltage: 1.14v to 1.26v
Main memory Micron MT46V32M16P-6T:F
DDR-SDRAM: 256 Mbytes (MB)
Entry-level Server
Mid-range Servers
DDR-SDRAM: 512 Mbytes (MB)
High-End Servers
Provides 64 bits of data
Provides 8 bits of ECC
Operating frequency: 133 MHz

Table 2-1 Service Processor Component Breakdown (Continued)
Component Details
FMEM Spansion S29JL064H70TFI000
flash memory 8 Mbytes
64 Megabits (Mbits) (x2)
Uses two banks of memory, one for backup
Operating voltage: 3v
Maintenance Acts as the communication mechanism for various
bus components and provides:
I2C master control
JTAG controller functionality
Power supply monitoring
Interrupt handling
Reset control
Ports The following ports are provided:
USB 1.1 (x1)
10/100Base-T (x2)
Serial port (x1)
Uninterruptable Power Control (UPC) (x2)
RCI (x1) not used by Sun
Clock Epson Q414574B1000102
Entry-level and Mid-range servers only
High-accuracy crystal real-time clock
Automatic leap year adjustment
Clock is provided by the Active Centerplane on
the M8000
Clock is provided by the Clock Board on the
M9000s

Exercise: Identifying the Architectural Components of the MX000 Servers
Exercise: Identifying the Architectural Components

of the MX000 Servers
In this lab, you answer questions concerning the architecture of the
MX000 servers.
Preparation
No special preparation is needed for this lab.
Task
Answer the following questions:
1. What are the functions of the system controller ASIC?
_____________________________________________________________
_____________________________________________________________
2. Which type of interconnect bus is used in the MX000 servers?

_____________________________________________________________
_____________________________________________________________
3. What is the difference between a CPUM and a CMU?

_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

Exercise: Identifying the Architectural Components of the MX000 Servers
4. Which servers support both PCI-X and PCI-Express cards without

the use of an IO-Box?
_____________________________________________________________
_____________________________________________________________
5. What is the difference between a uni-mode XSBs and quad-mode

XSBs?
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

Exercise Summary
Exercise Summary

!
?
Experiences
Interpretations
Conclusions
Applications

Exercise Solutions
Exercise Solutions
This section provides solutions for the exercise.
Task
1. What are the functions of the system controller ASIC?
The system controller is an ASIC that provides an interface among the memory
access controllers (MACs), the CPUs, and the I/O controllers.
2. Which type of interconnect bus is used in the MX000 servers?
The Jupiter interconnect bus.

3. What is the difference between a CPUM and a CMU?
The CPUM is a fru that consists of two CPUs and resides in the
mid-range servers. A CMU is a CPU/Memory unit that consists of 2 or 4 CPUs
and 16 or 32 DIMM slots and resides in the high-end servers.
4. Which servers support both PCI-X and PCI-Express cards without
the use of an IO-Box?
The M4000 and M5000 servers.

5. What is the difference between a uni-mode XSBs and quad-mode
XSBs?
A uni-mode XSB (00-0) is a PSB set with all of the components assigned to it. A
quad-mode XSB is a PSB set with its components divided into four sections (00-
0, 00-1, 00-2, 00-3). The M3000 does not support quad-mode. The component
division is different on the mid-range and the high-end servers.

Module 3
Service Processor Architecture and

Configuration
Objectives
Document the functions of the service processor
Compare and contrast the differences between the service processors
of the entry-level, mid-range, and high-end servers
List the features of the External Administration Network, Domain to
Service Processor Communication Protocol Network, and the
Internal Service Network
Compare the available physical network configurations
Perform an initial configuration of the service processor
Update the service processor firmware
3-1
Objectives
Relevance
Discussion The following questions are relevant to understanding

service processor architecture and configuration:
!
?
What is the role of the service processor?
Are there any differences among the service processors used in the
MX000 servers?
What steps are required to configure the service processor?
What is the procedure for upgrading the service processor firmware?


5872-xx.
number 819-3601-xx.
Service Processor Architecture and Configuration 3-3


http://docs.sun.com
http://www.sun.com/downloads

Extended System Control Facility Functions

The MX000 servers all use the Extended System Control Facility (XSCF) to
provide system monitoring and control. The XSCF consists of a hardware
component called the Extended System Control Facility unit (XSCFU) and
a software component called the XSCF control package (XCP).
Note For simplicity, the XSCFU is also referred to as the service

processor, and will be called this for the remainder of the course.
Service Processor Functionality

The main functions provided by the service processor are:
Platform monitoring
Configuration management
Security management
Server status reporting
Error detection
Remote server access
Resource management
Dynamic Reconfiguration (DR)
Capacity on Demand (COD)
A more detailed review of these functions is provided in Table 3-1 on

page 3-6.

Table 3-1 Service Processor Functions
Function Description
Platform The platform management tasks provided by the service

Management processor are:
Monitoring of cooling components (fan units)
Monitoring of power components (power supplies)
Power-on and power-off functions
Error monitoring
Configuration The configuration management tasks provided by the service
Management processor are:
Configuring the Physical System Board (PSB) sets into uni-
mode or quad-mode
Modifying the Domain Component Lists (DCLs)
Allocating XSBs to domains
Security The service processor manages security by:
Management Requiring a valid user login with a valid password
Requiring each valid user has assigned privileges
Providing an IP address filtering function for permitting
access to the service processor
Providing an encryption function using SSH and SSL
Server Status The service processor provides status functions such as:
Displaying the system configuration status
Displaying the system environmental status
Displaying the system domains status
Error Detection The service processor continually monitors the Sun SPARC
Enterprise system status. When an error does occur:
The service processor immediately collects error
information about the hardware (hardware log) and
analyzes it to identify the error location.
To continue operation, the service processor degrades the
relevant component or domain as necessary according to
error conditions, or it resets the system, thereby preventing
the problem from recurring.

Table 3-1 Service Processor Functions (Continued)
Function Description
Remote Server A function for monitoring the server through an Ethernet

Access connection is provided, which:
Allows a user to manage the server from a remote location
Provides a function for reporting error information to the
system administrator
Resource The service processor manages hardware resources on configured
Management domains and system boards. This includes:
Dynamic Reconfiguration
Logical attachment and detachment of XSBs to and
from a domain without causing domain downtime
Capacity on Demand
COD is an option that enables you to purchase spare
processing capacity

M8000 and M9000 Servers

The high-end servers service processors have the following
characteristics:.
Dual service processors (XSCFU_B).
The service processors act as redundant components.
Hot plug capability. The XSCFU_B boards can be removed and
replaced without the need to power down the server.
Figure 3-1 shows the front view of the service processors (XSCFU_B and
XSCFU_C boards) used in the high-end servers. The XSCFU_B ports are
the External LAN management ports, the USB port, the Serial
Management ports, and the RCI port.
Figure 3-1 XSCFU_B and XSCFU_C Service Processors
Redundant Service Processors
The high-end servers use a redundant configuration of service processors

(XSCFUs), thereby realizing a high reliability with the system. The XSCFU
that controls the server is called the Active XSCFU. The other XSCFU acts
as a backup and is called the Standby XSCFU. The Active XSCFU and the
Standby XSCFU monitor each other, and if an error is detected, they
determine when a failover or switch to Active or Standby should be
performed.

M9000 Server With Expansion Cabinet

The M9000 server with Expansion Cabinet, which is essentially two
M9000 servers with additional cable components, uses two XSCFU_B
units as before but also adds two XSCFU_C units, with the following
characteristics:
The XSCFU_C is the repeater unit of the XSCFU, and is installed in
the extended chassis of the M9000 server.
The XSCFU_C connects to the XSCFU_B, installed in the base
chassis, and enables XSCF to operate and administer the extended
chassis.
There are two XSCFU_C boards, to offer redundant configuration.
While the system is in operation, the XSCFU_C board can be
replaced without affecting the system.
Figure 3-2 illustrates the cabling between the XSCFU_B and XSCFU_C
boards within the M9000 server with Expansion Cabinet.
M9000 Base Cabinet M9000 Ex. Cabinet
XSCFU_B#0 XSCFU_B#1 XSCFU_C#0 XSCFU_C#1
Data Cable
Figure 3-2 XSCFU_C Expansion Cabling for the M9000 Server With
Expansion Cabinet

Service Processor Comparison Summary

Table 3-2 summarizes the differences among the service processors, based
on which server is used.
Table 3-2 Service Processor Summary Comparison
M9000 With
M3000, M4000 and M8000 and M9000
Feature Expansion
M5000 Servers Servers
Cabinet Servers
Number of One Two Four, including

XSCFUs the XSCFU_C
boards
Redundant? No Yes Yes
Hot-plug No Yes Yes
capable?
Physical location Rear Front Front
Component label XSCFU (x1) XSCFU_B (x2) XSCFU_B (x2)
XSCFU_C (x2)

Serial Management Port Connections

Each MX000 server is supplied with a brown serial cable for connecting
the serial management port of the service processor to your chosen
console device.
To ensure proper communication to the serial management port, this

section provides the information required to configure your serial
connection, including:
Serial Management Port pinouts
Network Terminal Server (NTS) port settings
Serial Management Port pinouts
The proper pinouts for both the MX000 serial management port and
terminal concentrator are provided below:
Sun System RJ45 annex TC RJ45
Serial Port port
=========================================================
Pin Desc. Color Color Desc. Pin
=========================================================
1 RTS White/Orange <----> White/Orange CTS 8
2 DTR Orange <----> Orange DSR 7
3 TXD White/Green <----> White/Green RXD 5
4 GND Blue <----> Blue GND 4
5 GND White/Blue <----> White/Blue GND 6
6 RXD Green <----> Green TXD 3
7 DSR White/Brown <----> White/Brown DTR 2
8 CTS Brown <----> Brown RTS 1
Network Terminal Server Port Settings
An NTS or other terminal server requires the following port settings to

connect to the serial management port of the MX000 server:
Baud rate: 9600 bps
Data length: 8 bit
Parity: None
Stop: 1 bit
Flow control: None

Configuring the Service Processor

This section describes the steps required for performing the initial
configuration of the service processor. You must complete the following
basic steps when you first configure the service processor:
Gather required information
Log in to the service processor
Add a user account
Set the service processor time zone, date, and time
Configure network time protocol (NTP) (optional)
Set the locale
Reboot the XSCF
Configure the XSCF External Admin Network (EAN)
Assign a host name to the service processor(s)
Create default routes
Configure the Domain to Service Processor Communications
Protocol (DSCP) network
Configure the XSCF Internal Service Processor (ISN) network (high-
end servers only)
Gathering Required Information

Before you configure the service processor, you should have the following
information:
The IP address and port(s) for a Network Terminal Server.
IP addresses to be used for the EAN network.
Netmasks
Default route addresses.
IP addresses to be used for the DSCP network.
IP addresses to be used for the ISN network.
IP address of a server that will act as a Management Service Provider
(MSP). This server may be configured to provide access for:
Login from a Browser User Interface (BUI)
Service Processor firmware

Initial Login to the Service Processor

The initial login to the service processor can be performed using a serial
connection from a terminal device and the default account name. This
default account is unique in the following ways:
You must have the key to external keyswitch
It cannot be logged into using the standard UNIX user name and
password authentication.
It can only be logged into using a procedure that requires physical
access and close proximity to the server.
Its privileges are fixed as useradm and platadm, which allows you to
configure the service processor, add users, or reset passwords.
The account cannot be deleted.
It has no password, and no password can be set for it.
Note The following procedure can also be used if the login password is
lost.
Initial login steps using the default account
To perform an initial login using the default account, complete the

following steps with the server powered off:
1. Connect the supplied serial cable from the XSCFU to a terminal
device.
2. Establish a physical connection to the XSCFU serial management
port.
3. Set the operator panel keyswitch to the service position.
4. Power on the server.
Observe the boot messages that are displayed through the serial
connection. When the XSCFU completes the boot process, a login
prompt is displayed.
5. Log in to the service processor using the default login name from a
terminal device connected to the service processor (there is no
password for this account):
login: default

6. When prompted, toggle the Operator Panel MODE switch on the

front of the server. The MODE switch has two positions: Service and
Locked.
a. If the switch is in the Service position, turn it to the Locked
position, leave it there for five seconds, turn it back to Service
and then press the enter key in your terminal session.
b. If the switch is in the Locked position, turn it to the Service
position, leave it there for five seconds, turn it back to Locked
and press enter in your terminal session.
When the toggle procedure is complete, the service processor shell
will be displayed in the terminal session:
XSCF>
Initial login steps using the admin account
A second method of login is provided using the admin account. This

account has the useradm privilege only.
1. Connect the supplied serial cable from the XSCFU to a terminal
device.
2. Establish a physical connection to the XSCFU serial management
port.
3. Power on the server.
Observe the boot messages that are displayed through the serial
connection. When the XSCFU completes the boot process, a login
prompt is displayed.
4. Log in to the service processor using the admin login name from a
terminal device connected to the service processor (there is no
password for this account):
login: admin
XSCF>
Upon login, create a new user account with a password and platadm and
useradm privileges. Log out and then log back in as the new user to start
the service processor configuration process.
Note Once any new user account has been created, the admin account is
disabled.

Adding or removing a User Account

The next step in configuring the service processor is to add at least one
user account. The adduser command creates a new user account in about
sixty seconds. The deleteuser command is used to remove a user
account. The removal process takes about 60 seconds.
The adduser Command

The adduser command creates a new local XSCF user account. When a
new user account is created, the account has no password, and cannot be
used for logging in until the password is set.
The syntax for the adduser command is:

adduser [-u UID] user
Options and Parameters
The options and parameters for this command are:
-u uid Specifies the user identifier (UID). This is an

optional argument. If specified, the value must be
greater than or equal to 100. If not specified, a value
is automatically assigned.
user Specifies the name of the user to create. The
maximum name length is 31 characters.
-h Displays usage information.
Note The UIDs 65534 and 65535 are reserved and cannot be used.
Note The following accounts are reserved for the service processor and
cannot be used: root, bin, daemon, adm, operator, nobody,
sshd, rpc, rpcuser, ldap, apache, ntp, admin, and
default.

Sample Command Output
The following example creates a user named bill with a UID of 250.
XSCF> adduser -u 250 bill
The following example creates a user named javier, without specifying a

UID:
XSCF> adduser javier
Note If a new user is created and a UID is not specified, the first new
users id will be 100. The maximum length of a user name is limited to 31
characters.
The deleteuser Command

The deleteuser command deletes a XSCF user account. All local account
data associated with the user account is deleted, including password and
SSH keys.
If the user is currently connected into the service processor, the users
connection is terminated at once. The users account is removed from the
system and the user cannot log back in.
Note Users cannot delete their own accounts.
The syntax for the deleteuser command is:

deleteuser user
user Specifies the user to delete

-h Displays usage information

The following example deletes the user account gary:

XSCF> deleteuser gary
The password Command

The password command allows a user to change password and password
expiration settings, with the following guidelines:
When invoked with one or more options, the password command
makes changes to the expiration settings of the account.
When invoked without options, the password command prompts
the user to change the account password. The password of a disabled
account can only be changed by someone with useradm privileges.
When invoked without a user operand, the password command
operates on the current user account.
The syntax for the password command is:

password [-e days | date| Never] [-i inactive]
[-M maxdays] [-n mindays] [-w warn] [user]
-e days Number of days until the account expires.

-e date Date when account expires. Format is yyyy-mm-dd.
-e Never Specifies that the account will never expire.
-i inactive Days after expiration until the account is locked. The
initial value is -1, meaning that the account will not
be locked. Valid values are -1 or greater.
-M maxdays Maximum number of days that a password is valid.
To set a value to never expire, set the value to
999999. Values must be non-zero.

-n mindays Minimum number of days between password

changes. Valid values are zero or greater. A value of
zero indicates that the password can be changed at
any time.
-w warn Number of days before password expiration to start
warning the user. The initial value is 7. Valid values
are zero or greater.
user Specifies the user account to operate on.
Note Any XSCF user can set his or her own password. Only a user with
useradm privileges can set another users password.
Note The password can be up to 32 characters in length.
The following example enables the password for the user darcy until
February 25, 2011:
XSCF> password -e 2011-02-25 darcy
The following example sets the password to lock 10 days after the
password expires for the user rob:
XSCF> password -i 10 rob
The following example changes the password for the user frank:
XSCF> password frank
New XSCF password:
Retype new XSCF password:
Note The service processor will give you a warning message if you do
not adhere to the password policy.

Managing Server Administrative Privileges

The XSCF software maintains user and software agent access to the service
processor and its components through authorized user interfaces that are
managed by access control.
Access control is a way of granting access to functions or components to

only those users who have been authenticated by the system and who
have appropriate privileges. Access control depends on the proper
configuration of the security services provided by the servers.
Access Control Privileges

Privileges allow users to administer user logins, platform resources,
domain resources, and audit resources, and allow a user to perform a
specific set of actions on a specific set of components. These components
include:
Physical hardware
Domains
Physical components within a domain
User privileges are configured and administered from the service

processor. By default, privileges are authenticated locally. However, you
can set up the service processor to use an LDAP server for authentication
instead.
A user can have multiple privileges as well as privileges on multiple

domains. This allows the platform administrator flexibility in managing
access to the domains.
Note Privileges are preset in the XSCF software. The existing privileges
cannot be changed, nor can additional privileges be added.

The servers provide the pre-defined privileges shown in Table 3-3.
Table 3-3 User Privileges
Privilege Capabilities
none None. When the local privilege for a user is set to none,
that user has no privileges, even if privileges for that
user are defined in LDAP.
useradm Create, delete, disable, and enable user accounts.
Change a users password and password properties.
Change a users privileges.
View all platform states except audit state and trail.
platadm Perform all service processor configuration tasks

other than the useradm and auditadm tasks.
Assign and unassign hardware to or from domains.
Perform domain and service processor power
operations.
Perform service processor failover operations on
systems with more than one service processor.
Perform all operations on domain hardware.
View all platform states.
platop View all platform states.
domainadm Perform all operations on hardware assigned to the

domain(s) on which this privilege is held.
Perform all operations on the domain(s) on which
this privilege is held.
View all states of the hardware assigned to the
View all states of the domain(s) on which this
privilege is held.

Table 3-3 User Privileges (Continued)
Privilege Capabilities
domainmgr Perform domain power operations.
View all states of the hardware assigned to the
privilege is held.
domainop View all states of the hardware assigned to the

privilege is held.
auditadm Configure auditing.

Delete audit trail.
auditop View all audit states and the audit trail.
fieldeng Perform all operations reserved for field engineers.
The setprivileges Command

The setprivileges command assigns privileges to an XSCF user. The
setprivileges command only modifies local privileges data. Multiple
privileges are separated by one or more spaces. Privileges can be assigned
to a maximum of 100 users.
The syntax for the setprivileges command is:

setprivileges user [privileges] domain-list
Note If the setprivileges command assigns privileges as none, all

privileges are removed.

user Specifies the user to assign the privileges to

privilege Specifies the privilege(s) to assign
domain-list Specifies the domains to apply the privileges for
Domain-specific Privileges
Some privileges must be assigned to a specific domain. These are

domainop, domainmgr, and domainadm. Keep the following guidelines in
mind when specifying domain-specific privileges:
Domains are specified using the @ symbol and domain number.
Inclusive domain ranges are specified using a - between the start
and end domain numbers.
Multiple single domains and multiple domain ranges are specified
using commas.
In this example, useradm privilege is assigned for the user barry.

XSCF> setprivileges barry useradm
In this example, domainadm privileges are being assigned for the user
gary to domains 1, 2, 3, 4, 6, and 9:
XSCF> setprivileges gary domainadm@1-4,6,9
In this example, all privileges are removed for the user bill.
XSCF> setprivileges bill none
Caution The setprivileges command overwrites a users current

privileges and does not append privileges to the existing list. To add
privileges to a user, you must re-list all existing privileges as well as any
new privileges.

The showuser Command

The showuser command displays XSCF user account information. If the
user argument (-u) is specified, showuser displays account information
for the specified user. If the user argument is not specified, then showuser
displays account information for the current user.
Note If logged into the XSCF as root, you do not need to use the -l
option to view users. Otherwise, a permission denied message will be
returned.
The syntax for the showuser command is:

showuser [-a] [-l] [-p] [-u] [-h] [user]
-a Displays password validity and account state

information. Valid only for local users.
-l Displays information for all local XSCF user
accounts sorted by user login name. Cannot be used
with the user operand.
-M Displays text by page. This option provides a
function that is the same as the more command.
-p Displays all privileges assigned to the user. This is
valid for local and remote users.
-u Displays user ID (UID). This is valid for local and
remote users.
user Displays information for the specified user.

The following example displays password and account validity

information.
XSCF> showuser -a
User Name: installer
Status: Enabled
Minimum: 0
Maximum: 99999
Warning: 7
Inactive: -1
Last Change: Feb 24, 2009
Password Expires: Never
Password Inactive: Never
Account Expires: Never
The following example displays privileges information.

XSCF> showuser -p
User Name: gary
Privileges: domainadm@1-4,6,9
platadm
The following example displays information for all users.

XSCF> showuser -l
User Name: installer
UID: 100
Status: Enabled
Minimum: 0
Maximum: 99999
Warning: 7
Inactive: -1
Last Change: Feb 25, 2009
Password Expires: Never
Password Inactive: Never
Account Expires: Never
Privileges: useradm
platadm
fieldeng
auditadm

The adduser Configuration Steps
To add a user account, complete the following steps:

1. Create a new user, using the adduser command:
XSCF> adduser user-name
2. Verify that the user was created:
XSCF> showuser -l
3. Set the password for the newly created user:
XSCF> password user-name
Please enter your password:
4. Assign privileges to the newly created user:
XSCF> setprivileges user-name useradm
Note Pressing the tab key twice in rapid succession will allow you to
display all of the available commands. Typing the word show and then
the tab key will display all of the commands that begin with show.
The tab key can also be used for command completion.
Note Using the up arrow key, you can scroll back through the
commands that have been entered. Using the down arrow key takes
you back through the commands most recently entered. Using the right
arrow and left arrow keys allows for editing of the displayed
command.
Note Man pages are available for each command.

Setting the Service Processor Time

The XSCF board is designed to stop keeping time when it is removed
from the platform chassis. This saves the battery when a board is in
storage. This does, however, cause some behavior that you should be
aware of:
When an XSCFU is physically reinserted/replaced, the XSCFU date
will be reset to December 31, 2000.
When a domain runs a date command to set the date, the date offset
on the XSCF will be adjusted appropriately. In other words, when a
domain reboots, it will preserve its time and not be affected by the
XSCF boards date of December 31, 2000.
When the setdate command is run on the XSCF under normal
circumstances, the date offsets of the domains will be changed (the
domains will preserve their dates). When the setdate command is
run on the XSCF when the date is December 31 2000, then the date
offsets of the domains will not be changed. Thus, as long as the initial
setdate for the XSCF is completed, everything should be fine on the
domains.
The setdate command on the XSCF will not work if any of the
domains are powered up. Changing the date requires the service
processor to be reset.
When an XSCFU is inserted/replaced, the normal documented
procedures are to run the setdate CLI before domains are powered
up. This will preserve date sanity for the domains.
The resetdateoffset command resets all domain offsets back to
zero. This command can only be run if all domains are powered
down. After this command is run, all domains will boot with the
current XSCF time.

Setting the Initial Timezone, Date, and Time
To set the time zone for the service processor, complete the following
steps:
1. Log in to the service processor using an account with platadm or
fieldeng privileges.
2. Display the current time zone:
XSCF> showtimezone -c tz
US/Eastern
3. View the available list of time zones:
XSCF> settimezone -c settz -a
Africa/Abidjan
Africa/Accra
Africa/Addis_Ababa
Africa/Algiers
Africa/Asmera
Africa/Bamako
...
4. Set the desired time zone to any of the allowed POSIX time zone
names, as shown in step 3. For example:
XSCF> settimezone -c settz -s US/Eastern
To set the date and time, complete the following steps:

1. Log in to the service processor using an account with platadm or
fieldeng privileges.
2. Display the current date:
XSCF> showdate
Tue Feb 24 22:35:11 EST 2009
3. Set the date to the desired time and year; the syntax is
MMDDHHmmYYYY.ss:
XSCF> setdate -s 022422402009.00
Tue Feb 19 22:37:00 EST 2009
The XSCF will be reset. Continue? [y|n] :y
Wed Feb 20 03:37:00 UTC 2009
XSCF> execute S10ioxoff -- complete
Feb 19 22:37:07 godzilla-SP0 XSCF[104]: XSCF shutdown
sequence start
execute K000end -- complete

Configuring NTP
The network time protocol (NTP) is an Internet protocol used to
synchronize computer clocks to a known source.
To configure the service processor to use an NTP server, complete the

following steps:
1. Log in to the service processor using an account with platadm
privileges.
2. Specify the location of the NTP server:
XSCF> setntp -c add 10.6.15.50
Please reset the XSCF by rebootxscf to apply the ntp
settings.
3. Verify the NTP configuration:
XSCF> showntp -a
server 10.6.15.50 prefer
4. Reboot the service processor:
XSCF> rebootxscf
Setting the Locale

To set the locale, which controls language settings for the service
processor, complete the following steps:
privileges.
2. Display the current locale:
XSCF> showlocale
C
3. Set the desired locale to English C:
XSCF> setlocale -s C
C

Resetting/Rebooting the XSCF

Sometimes the XSCF needs to be reset or rebooted manually. To
accomplish this task, use the rebootxscf command.
Note This command will not interfere with running domains.
The rebootxscf Command
The rebootxscf command allows the user to manually reboot the XSCF.
This command requires either platadm or fieldeng privileges to execute.
The syntax for this command is:

rebootxscf [-y |-n] [-q] [-h]

-q Suppresses all messages to stdout (quiet mode)
-y | -n Automatically answers yes or no to all prompts
The following example resets the XSCF.

XSCF> rebootxscf
The XSCF will be reset. Continue? [y|n]:y
The following example resets the XSCF and automatically replies with
yes without displaying the prompt.
XSCF> rebootxscf -q -y
The following example cancels an XSCF reboot that is in progress.

XSCF> rebootxscf
The XSCF will be reset. Continue? [y|n]:n

Service Processor Networks

The service processor makes use of as many as three networks to handle
communications between components of the MX000 servers, as well as
provide external access. The three networks are the:
XSCF External Administration Network (EAN)
Domain to Service Processor Communications Protocol (DSCP)
Network
XSCF Internal Service Network (ISN) for Service Processor (active) to
Service Processor (standby) communication for the high-end servers
Note The MX000 servers are shipped without any of the networks
configured.

XSCF External Administration Network

The XSCF External Administration Network connects the service
processors to the customer network for administrative access to the
service processor(s), such as access to the CLI or BUI.
Network Interfaces
The XSCF External Administration Network makes use of several

interfaces to handle the communication for the service processors. Each
service processor has two network ports for external communication to
the customer network. The high-end service processors provide floating
IP addresses in case of service processor failover. All the External
Administration Network interfaces are seen in Table 3-4.
Table 3-4 XSCF External Administration Network Interfaces
XSCF Interface Description
XSCF0 xscf#0-lan#0 External network port0

xscf#0-lan#1 External network port1
XSCF1 xscf#1-lan#0 External network port0
xscf#1-lan#1 External network port1
XSCF-LAN#0 lan#0 Takeover (floating) IP
XSCF-LAN#1 lan#1 addresses
Note The XSCF0 interfaces apply to the entry-level M3000, the mid-
range servers, and the high-end servers. The XSCF1 and XSCF-LAN
interfaces apply only to the high-end servers.

Network Parameters
The XSCF External Administration Network parameters are for:
The Active service processor interfaces (xscf#0-lan#0 & xscf#0-
lan#1) (All MX000 servers)
The Standby service processor interfaces (xscf#1-lan#0 &
xscf#1-lan#1) (M8000 and M9000 servers only)
Netmasks
Network routes
Gateway addresses
Note Each service processor must be configured so that IP addresses for

the network interfaces are on two different subnets. The IP address
associated with xscf#0-lan#0 should be on a different subnet than xscf#0-
lan#1.
Configuring the XSCF External Administration

Network
To configure the XSCF external admin network, complete the following
steps:
1. Log in to the XSCF using an account with platadm privileges.
2. Configure the xscf#0-lan#0 interface:
XSCF> setnetwork xscf#0-lan#0 -m 255.0.0.0 10.6.15.21
XSCF> setnetwork xscf#0-lan#1 -m 255.255.255.0
192.1.1.21
XSCF> setnetwork xscf#1-lan#1 -m 255.255.255.0
192.1.1.22
6. Apply the network settings, which will ask to reset the XSCF:
XSCF> applynetwork
The following network settings will be applied:

xscf#0 hostname :
xscf#1 hostname :
DNS domain name :
nameserver :
nameserver :
interface :xscf#0-lan#0
status :down
IP address :10.6.15.21
netmask :255.0.0.0
route :-n 10.0.0.0 -m 255.0.0.0
route :-n 0.0.0.0 -m 0.0.0.0 -g 10.0.0.5
status :down
netmask :255.255.255.0
route :
interface :xscf#0-if
status :down
IP address :
netmask :
interface :lan#0
status :down
netmask :255.0.0.0
route :
status :down
netmask :255.0.0.0
route :-n 10.0.0.0 -m 255.0.0.0
route :-n 0.0.0.0 -m 0.0.0.0 -g 10.0.0.5
status :down
netmask :255.255.255.0
route :
interface :xscf#1-if
status :down
IP address :

netmask :
interface :lan#1
status :down
netmask :
route :
Continue? [y|n] :y
Please reset the XSCF by rebootxscf to apply the
network settings. Please confirm that the settings have
been applied by executing showhostname, shownetwork,
showroute and shownameserver after rebooting the XSCF.
XSCF> rebootxscf -y
Note If you are administering a high-end server and still need to

configure the ISN network, you can wait to execute the applynetwork
command until after you have finished configuring all of the networks.

The sethostname Command

The sethostname command sets a host name and domain name for the
service processor. Do not specify a host name and domain name in Fully
Qualified Domain Name (FQDN) format, but specify the names
separately.
The syntax of the sethostname command is:

sethostname [xscfu] [hostname][-d domainname] [-h]
hostname Specifies a host name to be set for the XSCF unit.

The host name can be up to 64 characters.
-d domainname Specifies a DNS domain name to be set for the XSCF
unit. The domain name can be up to 64 characters.
The following example sets the host name for xscf#0 to godzilla-sp0.
XSCF> sethostname xscf#0 godzilla-sp0
The following example sets the host name for xscf#1 to godzilla-sp1.
XSCF> sethostname xscf#1 godzilla-sp1
The following example sets the domain name to sun.com for xscf#0 and
xscf#1.
XSCF> sethostname -d sun.com

The showhostname Command

The showhostname command shows the host names for all service
processors and domain name.
XSCF> showhostname -a
xscf#0:godzilla-sp0.sun.com
xscf#1:godzilla-sp1.sun.com

The shownetwork Command

The shownetwork command displays current network information for the
XSCF, including:
xscf#x-y The XSCF network interface name
HWaddr The MAC address of the interface (hexadecimal notation)
inet addr The IP address assigned to the interface
Bcast The broadcast address assigned to the interface
Mask The netmask assigned to the interface
UP/DOWN Whether the network interface is enabled
The syntax of the shownetwork command is:

shownetwork [-M] [-a] interface [-h]
interface Specifies the network interface whose information is

to be displayed. Valid values for XSCF unit 0 are:
xscf#0-lan#0
xscf#0-lan#1
xscf#0-if
Valid values for XSCF unit 1 are:

xscf#1-lan#0
xscf#1-lan#1
xscf#1-if
Valid values for the takeover IP addresses are:

lan#0
lan#1
-a Displays information for all XSCF network
interfaces.


function that is the same as that of the more
command.
This example displays the information for xscf#0-lan#0 and xscf#0-lan#1

on an M5000 server:
XSCF> shownetwork xscf#0-lan#0
xscf#0-lan#0
Link encap:Ethernet HWaddr 00:14:4F:3A:9A:E5
inet addr:10.6.15.41 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12003 errors:0 dropped:0 overruns:0 frame:0
TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:877255 (856.6 KiB) TX bytes:1134 (1.1 KiB)
Base address:0xe000
xscf#0-lan#1
Link encap:Ethernet HWaddr 00:14:4F:3A:9A:E6
RX bytes:1126329 (1.0 MiB) TX bytes:277052 (270.5 KiB)
Base address:0xc000
This example displays the information for xscf#0-lan#0, xscf#0-lan#1,

xscf#1-lan#0 and xscf#1-lan#1 on an M8000 server:
xscf#0-lan#0
HWaddr 00:0B:5D:D7:33:16
inet addr:10.6.15.21 Mask:255.0.0.0

xscf#0-lan#1
HWaddr 00:0B:5D:D7:33:17
inet addr:192.1.1.21 Mask:255.255.255.0


xscf#1-lan#0
Link encap:Ethernet HWaddr 00:0B:5D:D7:33:19
Base address:0xe000

xscf#1-lan#1
Link encap:Ethernet HWaddr 00:0B:5D:D7:33:1A
Base address:0xc000
Note Use the shownetwork with the -a option to see all of your
network interfaces.

The setroute Command

The setroute command configures routing information for an XSCF
network interface. As many as eight routing information items can be
registered for each network interface. Any attempt to register more than
eight items causes an error.
Note The setroute command requires platadm privileges to execute.
The syntax of the setroute command is:

setroute -c {add | del} -n address [-m address]
[-g address] interface
setroute -h
-c add Adds routing information.

-c delete Deletes routing information.
-n address Specifies an IP address to which routing
information is forwarded.
-m address Specifies the netmask to which routing information
is forwarded.
-g address Specifies a gateway address.
interface Specifies the network interface to be set with
routing information.
The following example adds the route 10.7.1.0 and netmask 255.255.0.0 for
xscf#0-lan#0.
XSCF> setroute -c add -n 10.7.1.0 -m 255.255.0.0
xscf#0-lan#0

The following example shows how to delete the routing destination

192.168.1.0 and default netmask (255.255.255.0) from xscf-lan#1 on xscf 0.
XSCF> setroute -c del -n 192.168.1.0 -m 255.255.255.0
xscf#0-lan#1
The showroute Command

The showroute command displays the current route settings.
Note The showroute command can be executed using any privilege.
The syntax of the showroute command is:

showroute [-a] [-M] [-n] [-h] interface
-a Displays routing information that is set for all XSCF

network interfaces.
command.
-n Displays IP address without the name resolution of
host name.
interface Specifies which interface to display information for.

The following example displays routing information for xscf-lan#0 on

XSCF unit 0:
XSCF> showroute xscf#0-lan#0
Destination Gateway Netmask Flags Interface
10.0.0.0 * 255.0.0.0 U xscf#0-lan#0
10.0.0.0 * 255.0.0.0 U xscf#0-lan#0
default int.brlg.sunedu 0.0.0.0 UG xscf#0-lan#0
Commands Used
The XSCF External Network is configured and managed using the

following commands:
setnetwork
setroute
applynetwork
shownetwork

Domain to Service Processor Communications Protocol

(DSCP) Network
The DSCP provides an internal and secure point-to-point protocol (PPP)-
based communication link between the Solaris OS domains and the
service processor, as seen in Figure 3-3. This is not a general use network;
it is intended to be used by DR, the Fault Management Agent, and NTP.
The DSCP network is comprised of:

One IP address dedicated to the active service processor
One IP address per domain dedicated to the DSCP network
192.168.224.1 192.168.224.2
XSCFU Domain 0
192.168.224.4
Domain 2
DSCP Link
192.168.224.13
Domain 11
192.168.224.20
Domain 18
Figure 3-3 DSCP Network
Network Configuration Settings
The DSCP network is not enabled by default; instead it is enabled when

the initial service processor configuration is completed, which includes
setting up the DSCP network parameters.
When the DSCP network is configured, the administrator simply decides

what the base IP address and netmask will be. The system then
automatically assigns appropriate IP addresses, incrementing the base IP
address by a count of +1.

Configuring the DSCP Network

Remember, the DSCP network should only be configured when no
domains are running. If the DSCP network settings are changed while a
domain is active, the domain needs to be rebooted to re-establish
communication with the service processor.
To configure the DSCP network, complete the following steps:

privileges.
2. Configure the DSCP network:
XSCF> setdscp
DSCP network (e.g. 192.168.224.0) > 192.168.224.0
DSCP netmask (e.g. 255.255.255.0) > 255.255.255.0
XSCF address [192.168.224.1] > [enter]
Domain #00 address [192.168.224.2] > [enter]
...
3. Verify that the DSCP network has been configured as desired:
XSCF> showdscp
DSCP Configuration:
Network: 192.168.224.0
Netmask: 255.255.255.0
Location Address
---------- ---------
XSCF 192.168.224.1
Domain #00 192.168.224.2
Domain #01 192.168.224.3
Domain #02 192.168.224.4
Domain #03 192.168.224.5
Domain #04 192.168.224.6
Domain #05 192.168.224.7
Domain #06 192.168.224.8
Domain #07 192.168.224.9
Domain #08 192.168.224.10
Domain #09 192.168.224.11
Domain #10 192.168.224.12
Domain #11 192.168.224.13
Domain #12 192.168.224.14
Domain #13 192.168.224.15
Domain #14 192.168.224.16
Domain #15 192.168.224.17

Commands Used
The DSCP network is configured and managed using the following

commands:
setdscp
showdscp
Caution The DSCP network should only be configured when there are
no domains running. If a change is made to the DSCP network while a
domain is active, the domain must be rebooted before the service
processor can communicate with it. Specific Solaris services must be
enabled for DSCP to function.

Internal Service Network (ISN)

The XSCF ISN provides an internal and secure PPP-based communication
link between the service processors in a high-end MX000 server. In a high-
end server, one service processor is designated as Active, while the other
service processor is designated as Standby.
The XSCF ISN allows the active service processor to exchange pertinent
system management information with the standby service processor so
that if a failure occurs, the standby service processor can take over as the
new active service processor without any interruption of domain service.
Network Interfaces
The XSCF Internal Service Network consists of one ISN interface for each
service processor, and provides for a private internal communication. The
interfaces are seen in Table 3-5.
Table 3-5 XSCF Internal Service Network Interfaces
XSCF Interface Description
XSCF0 XSCF#0-if Inter SCF Lan (ISN)

XSCF1 XSCF#1-if Inter SCF Lan (ISN)

Configuring the XSCF ISN Network

To configure the XSCF ISN network, if you have an MX000 high-end
server (more than one service processor), complete the following steps:
1. Log in to the XSCF using an account with platadm privileges.
2. Configure the xscf#0-if interface:
XSCF> setnetwork xscf#0-if -m 255.255.255.0
192.168.10.10
3. Configure the xscf#1-if interface:
XSCF> setnetwork xscf#1-if -m 255.255.255.0
192.168.10.11
XSCF> applynetwork
xscf#0 hostname :godzilla-sp0
xscf#1 hostname :godzilla-sp1
DNS domain name :
nameserver :
nameserver :
.
Continue? [y|n] :y
Please reset the XSCF by rebootxscf to apply the
network settings. Please confirm that the settings have
been applied by executing showhostname, shownetwork,
showroute and shownameserver after rebooting the XSCF.
XSCF> rebootxscf -y
Commands Used
The XSCF network is configured and managed using the following

commands:
setnetwork
applynetwork
shownetwork

Enabling Basic Services

The next steps are to enable three basic network services that provide
remote access to the service processor, telnet, ssh, and https. The
following commands are issued with both telnet, ssh and https
functionality initially disabled. To enable these network services, complete
the following steps:
privileges.
2. Enable telnet:
XSCF> settelnet -c enable
Note Enabling telnet does not require that the XSCF be reset with the
rebootxscf command, but disabling telnet does. Refer to the man
pages.
3. Enable ssh:
XSCF> setssh -c enable
Continue? [y|n] :y
Please reset the XSCF by rebootxscf to apply the ssh
settings.
Note Enabling ssh requires that the XSCF be reset with the rebootxscf
command, but disabling ssh does not.
4. Enable https:
XSCF> sethttps -c selfsign US MA Burlington SLS OPL
ssp0 root@ssp0
Enter passphrase: cangetin
Verifying - Enter passphrase: cangetin
XSCF> sethttps -c enable
Continue? [y/n] : y
Please reset the XSCF by rebootxscf to apply the https
settings.
XSCF> rebootxscf -y
Note Enabling https requires that the XSCF be reset with the
rebootxscf command, but disabling https does not. Refer to the man
pages.

5. Verify the settings:

XSCF> showtelnet
Telnet status: enabled
XSCF> showssh
SSH status: disabled
RSA key:
XSCF> showhttps
HTTPS status: enabled
Server key: installed in Feb 21 18:30:29 EST 2009
CA key: installed in Feb 21 18:30:29 EST 2009
CA cert: installed in Feb 21 18:30:29 EST 2009
CSR:
-----BEGIN CERTIFICATE REQUEST-----
MIIBvjCCAScCAQAwfjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk1BMQ8
wDQYDVQQHEwZCb3N0b24xDDAKBgNVBAoTA1NMUzEMMAoGA1UECxMDQV
BMMRcwFQYDVQQDEw5nb2R6aWxsYS14c2NmMDEcMBoGCSqGSIb3DQEJA
RYNcm9vdEBnb2R6aWxsYTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAqI6n2j0Y12wZilcAquRmMdrnOyrP5lqx5jPsjRLD3x1VZ3aNljH
iOiPepa3R8NG5Rv4uW/cCwEJqY2ymW7SoZXQLDj0VBRxVZS00pCYe+q
mdPG9EZ5Y38t5tnkKEI/0zqtw42W0Haah170x9ndly6FKAhFxdidSa
CIyegSjIjjcCAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GBAF81jrPx6na
P8tJNhvYnWJJnVpuYB4mwa+vJbIx7Tpn23f6Z6q7iM33HaPMBHyn3kX
FU4m70ITreZ2UFJb6jPPsN32RhOiL70167RmaR7//hvmJvnQBdTry6l
KqFxvnGn0l6fXp3ZTcgcsiTiEhHqOxvTfY3nF42uK7gEl/AVzpx
-----END CERTIFICATE REQUEST-----

The setupplatform Command
The setupplatform command sets up platform specific settings. The

command leads an administrator through Service Processor installation
tasks.
By default, the setupplatform command walks through each of
the available settings.
Individual settings may be selected using the -p option.
You must have one of the following privileges to run this command:
useradm: to use the -p user option
platadm: to use the -p network, -p altitude, -p timezone options
XSCF> setupplatform
Do you want to set up an account? [y|n]: n
Do you want to set up networking? [y|n]: y
Do you want to set up the XSCF network interfaces? [y|n]: y
xscf#0-lan#0 is already configured:
xscf#0-lan#0 ip address: 10.6.15.41
xscf#0-lan#0 netmask: 255.0.0.0
xscf#0-lan#0 default gateway: 10.0.0.6
Do you want to configure xscf#0-lan#0? [y|n]: y
xscf#0-lan#0 ip address? [10.6.15.41]: 10.6.15.41
xscf#0-lan#0 netmask? [255.0.0.0]: 255.0.0.0
xscf#0-lan#0 default gateway? [10.0.0.6]: 0.0.0.0
Are these settings correct? [y|n]: y
XSCF> setroute -c del -n 0.0.0.0 -m 0.0.0.0 -g 10.0.0.6 xscf#0-lan#0
XSCF> setroute -c add -n 0.0.0.0 -m 0.0.0.0 -g 0.0.0.0 xscf#0-lan#0
Do you want to configure xscf#0-lan#1? [y|n]: y
xscf#0-lan#1 ip address? []: 192.1.1.41
xscf#0-lan#1 netmask? [255.255.255.0]: 255.255.255.0
xscf#0-lan#1 default gateway? []: 0.0.0.0
XSCF> setroute -c add -n 0.0.0.0 -m 0.0.0.0 -g 0.0.0.0 xscf#0-lan#1
lan#0 is already configured:
lan#0 ip address: 10.6.15.41

lan#0 netmask: 255.0.0.0

Do you want to configure lan#0? [y|n]: n
Do you want to configure lan#1? [y|n]: n
DSCP network is already configured:
DSCP network: 192.168.224.0
DSCP netmask: 255.255.255.0
Do you want to set up the DSCP network? [y|n]: y
DSCP network? [192.168.224.0]: 192.168.224.0
DSCP netmask? [255.255.255.0]: 255.255.255.0
DSCP network: 192.168.224.0
DSCP netmask: 255.255.255.0
XSCF> setdscp -q -y -i 192.168.224.0 -m 255.255.255.0
Domain name service is already configured:
Primary DNS server ip address: 10.0.0.81
Secondary DNS server ip address: 10.0.0.82
Tertiary DNS server ip address:
Domain name: sun.com
XSCF#0 hostname: kong-sp0
Do you want to set up the domain name service? [y|n]: n
Do you want to set up the network time protocol? [y|n]: n
The ssh service is: enabled
Do you want to set up ssh? [y|n]: n
The https service is: enabled
Do you want to set up https? [y|n]: n
Do you want to configure email reports? [y|n]: n
Do you want to apply the network changes? [y|n]: y
XSCF> applynetwork -y
xscf#0 hostname :kong-sp0
DNS domain name :sun.com
nameserver :10.0.0.81
nameserver :10.0.0.82
status :up
netmask :255.0.0.0
route :
status :up
netmask :255.255.255.0
route :
Continue? [y|n] :y

Please reset the XSCF by rebootxscf to apply the network settings.

Please confirm that the settings have been applied by executing
showhostname, shownetwork, showroute and shownameserver after rebooting
the XSCF.
Do you want to reboot the XSCF now? [y|n]: y
XSCF> rebootxscf -q -y
execute S10ioxoffDo you want to set up the chassis altitude? [y|n]: --
complete
Jan 30 13:32:16 kong-sp0 XSCF[104]: XSCF shutdown sequence start

Firmware Features and Functions

The service processor firmware is contained as a single software image,
which is known as the XSCF Control Package (XCP).
The XCP package is provided as a compressed file. The file name will be
representative of the server type that it should be used for:
IKXCPxxyy.tar.gz XCP firmware file for the M3000 entry-level

server: Ikkaku
FFXCPxxyy.tar.gz XCP firmware file for the MX000 mid-range
servers: Form Factor
DCXCPxxyy.tar.gz XCP firmware file for the MX000 high-end
servers: Data Center
XSCF Control Package

The XCP is the collective software and firmware that is resident on the
MX000 servers service processor. The main components of the XCP as
seen in Figure 3-4 are:
XSCF The extended system controller facility
OBP The OpenBoot PROM
POST The power-on self-test
XCP
XSCF
Uboot
Kernel
Linux open source pkgs
SCF applications
OBP/POST
(combined image)
Figure 3-4 XCP Overview Diagram

Firmware Update Overview

The firmware update procedure consists of four logical steps:
1. Verify the current version of firmware installed on the service
processor(s)
2. Download new firmware
a. http://www.sun.com/download
3. Import: This step consists of downloading the firmware from a:
a. Management Service Provider using FTP
b. Management Service Provider using HTTP
c. Management Service Provider using the Browser User Interface
(BUI)
d. USB drive
4. Update: This step consists of applying the imported firmware to the
service processor(s)

Firmware Update Features

The XSCF firmware update has the following features:
The new firmware is intended to be updated without the need to
stop running domains.
To update the OpenBoot PROM firmware for a domain, the target
domain must be rebooted so that the firmware can be applied.
When a component is replaced using the command replacefru,
the firmware is automatically updated. However, when a component
is cold replaced (input power off), the firmware is not updated
automatically.
If an error occurs during the update operation, the firmware
generation management mechanism (which retains spare firmware)
can prevent firmware data destruction.
Each service processor firmware update takes 20 minutes. During the
firmware update process, no service processor commands should be
entered as this may corrupt the firmware being applied.
Redundant Service Processors
In a system with redundant service processors, the firmware upgrade is:

Performed first on the Standby service processor
Performed second on the Active service processor
The Active service processor will become the Standby
service processor during this process
The Standby service processor will become the Active
service processor during this process
It takes 20 minutes to perform a flashupdate on the Standby
service processor
It takes 20 minutes to perform a flashupdate on the Active service
processor.

Upgrading the Firmware

Three commands are used to manage and upgrade the firmware on the
MX000 servers:
The version command
The getflashimage command
The flashupdate command
Note These commands require platadm or fieldeng privileges to

execute.
The version Command

The version command displays:
The comprehensive XCP firmware version currently applied to the
system
The version of OpenBoot PROM firmware (cmu)
The version of service processor (XSCF) firmware
The syntax of the version command is:
version -c [xcp cmu xscf] -h -t -v
-c xcp Displays the version of the XCP firmware

-c cmu Displays the version of the OpenBoot PROM firmware
-c xscf Displays the version of the service processor firmware
-h Displays command usage
-t Displays the XCP version that is registered in the XSCF
-v Displays detailed information

Displaying the XCP Version
To display the XCP version, execute the following command:

XSCF> version -c xcp
XSCF#0 (Active )
XCP0 (Reserve): 1080
XCP1 (Current): 1080
Displaying XCP Version Details
To display XCP version details, execute the following command:

XSCF> version -c xcp -v
XSCF#0 (Active )
OpenBoot PROM : 02.07.0000
XSCF : 01.08.0003
XSCF : 01.08.0003
XSCF#1 (Standby)
XSCF : 01.08.0003
XSCF : 01.08.0003
OpenBoot PROM BACKUP
#0: 02.03.0000
#1: 02.07.0000
Displaying the Registered XCP Version
To display the XCP version that is registered in the XSCF, execute the
following command:
XSCF> version -c xcp -t
XCP: 1080

Displaying Registered XCP Version Details
To display the details of the XCP version that is registered in the XSCF,
execute the following command:
XSCF> version -c xcp -v -t
XCP: 1080
XSCF : 01.08.0003
Displaying the OpenBoot PROM Version
To display the version of OpenBoot PROM firmware, execute the

following command:
XSCF> version -c cmu -v
DomainID 0: 02.07.0000
DomainID 1: 02.07.0000
DomainID 2: 02.07.0000
DomainID 3: 02.07.0000
DomainID 4: 02.07.0000
DomainID 5: 02.07.0000
DomainID 6: 02.07.0000
DomainID 7: 02.07.0000
DomainID 8: 02.07.0000
DomainID 9: 02.07.0000
DomainID 10: 02.07.0000
DomainID 11: 02.07.0000
DomainID 12: 02.07.0000
DomainID 13: 02.07.0000
DomainID 14: 02.07.0000
DomainID 15: 02.07.0000
XSB#00-0: 02.03.0000(Reserve) 02.07.0000(Current)
XSB#00-1: 02.07.0000(Current) 02.03.0000(Reserve)
XSB#01-0: 02.03.0000(Reserve) 02.07.0000(Current)

Displaying the XSCF Version
To display the version of XSCF firmware, execute the following command:

XSCF> version -c xscf -v
XSCF#0 (Active )
01.08.0003(Reserve) 01.08.0003(Current)
XSCF#1 (Standby)
01.08.0003(Current) 01.08.0003(Reserve)

Firmware Import Procedure

One of the key steps to performing the firmware update is to import the
firmware files into the service processor. Currently, you can perform this
import procedure using two methods:
The Browser User Interface (BUI)
The getflashimage command
Importing Firmware Using the BUI

The BUI uses https to provide an encrypted and authenticated internet
connection from the service processor to the Management Service
Provider (MSP) that contains the firmware files.
Importing the Firmware
To import the firmware, complete the following steps:

1. Open a browser on the Management Service Provider (MSP) that is
connected to the same network as the service processor.
2. Enter one of the IP address of the service processors External
Administration Network (EAN) in the browsers navigation bar (see
Figure 3-5 on page 3-61). Note the use of https and not http.
a. https://IP_Address

3. When prompted, log in to the service processor using the browser.

Make sure to log in with a user that has platadm privileges.
Figure 3-5 XSCF Login Screen
4. After logging in, select Utility from the drop-down menu.

5. Next, select Firmware Update from the drop-down menu.
6. Fill in the required information, including the location of the
firmware file to import:
a. IKXCPxxyy.tar.gz for an entry-level server
b. FFXCPxxyy.tar.gz for a mid-range server
c. DCXCPxxyy.tar.gz for a high-end server

The getflashimage Command

The getflashimage command allows you to store the firmware on a
remote server known as the MSP (set up to allow either ftp or http
access) and import the firmware to the service processor using the
command line. The getflashimage command can also be used to retrieve
the firmware from a USB drive.
The syntax of the getflashimage command is:

getflashimage [-v] [-q -{y|n}] [-u username] [-p proxy
[-t proxy_type]] URL
getflashimage -l
getflashimage [-q -{y|n}] -d
getflashimage -h
-d Deletes all previous firmware image files still on the

XSCF unit, then exits.
-h Displays command usage.
-l Lists firmware image files that are still on the XSCF
unit, then exits.
-n Automatically answers n (no) to all prompts.
-p proxy Specifies the proxy server to be used for transfers.
The default transfer type is http, unless modified
using the -t proxy_type option. The value for
proxy must be in the format servername:port.
-q Suppresses all messages to stdout, including
prompts.
-t proxy-type Used with the -p option to specify the type of proxy.
Possible values for proxy_type are: http, socks4,
and socks5. The default value is http.
-u user Specifies the user name when logging in to a remote
ftp or http server that requires authentication. You
will be prompted for a password.
-v Displays verbose output.

-y Automatically answers y (yes) to all prompts.
The following sample imports the firmware from an MSP (10.6.15.50) for a
high-end server that has enabled http access (the first attempt fails
because the wrong firmware is specified):
XSCF> getflashimage -v http://10.6.15.50/firmware/FFXCP1081.tar.gz
Error: invalid file name: FFXCP1081.tar.gz
XSCF> getflashimage -v http://10.6.15.50/firmware/DCXCP1081.tar.gz
Existing versions:
Version Size Date
DCXCP1080.tar.gz 51299678 Wed Jan 07 15:35:48 EST 2009
MD5: 314f0258d48c1d323034073b9270c44c
Warning: About to delete existing versions.
Continue? [y|n]: y
Removing DCXCP1080.tar.gz.
Free space: 97MB
0MB received
1MB received
2MB received
.
47MB received
The following sample imports the firmware from an MSP (10.6.15.50) for a
mid-range server that has enabled anonymous ftp access:
XSCF> getflashimage -v ftp://10.6.15.50/pub/FFXCP1081.tar.gz
Existing versions:
Version Size Date
FFXCP1080.tar.gz 51299678 Wed Jan 07 15:35:48 EST 2009
MD5: 314f0258d48c1d323034073b9270c44c
Continue? [y|n]: y
Removing FFXCP1080.tar.gz.
Free space: 97MB
0MB received
1MB received
2MB received
.
47MB received

The following sample imports the mid-range server firmware from the
images directory on a USB drive:
XSCF> getflashimage file:///media/usb_msd/images/FFXCP1081.tar.gz
The following sample lists which firmware file is currently imported:

XSCF> getflashimage -l
Existing versions:
Version Size Date
FFXCP1080.tar.gz 51299678 Fri Jan 30 19:39:02 EST 2009
The following sample deletes an older version of firmware:

XSCF> getflashimage -d
Existing versions:
Version Size Date
DCXCP1061.tar.gz 49217933 Wed Feb 20 20:43:28 EST 2008
Continue? [y|n]: y
Removing DCXCP1061.tar.gz.

The flashupdate Command

The flashupdate command is used to perform the firmware update for
the MX000 servers.
Note When the firmware is updated, the service processor is reset.

Therefore, all LAN connections to the service processor are dropped.
The syntax of the flashupdate command is:
flashupdate -c {check | update | sync} -m {xcp | xscf} -s

version
-c check Checks whether the specified firmware can be updated.

-c update Updates the specified firmware. In a dual service
processor configuration, both are updated.
-c sync Synchronizes the firmware versions of the XSCF units
when the XSCF units are duplicated configuration. This
option is used when replacing an XSCF unit.
-m xcp Specifies the entire firmware as the target.
-s version Specifies an XCP comprehensive firmware version. For
version, specify a major version and minor version
continuously in this order and respectively using two-
digit decimal numbers.

Checking Version Update Capability
To check whether the firmware can be updated to version xxyy, execute

the following command:
XSCF> flashupdate -c check -m xcp -s 1040
XCP update is possible with domains up
Note You can update to 1081, 1080, 1072, 1071, 1070, 1061, 1060 firmware
from 1050 firmware. If your service processor is currently running
firmware older then 1050, you must first upgrade to the 1050 firmware
before upgrading to a higher level firmware.
Note After upgrading to 1081 firmware, reboot the service processor

with the command rebootxscf.

Updating the Firmware
To update the firmware package from an older version (1080) to a new

version (1081), execute the following command:
XSCF> flashupdate -c update -m xcp -s 1081
Checking the XCP image file, please wait a minute
XCP update is started (XCP version=1081:last version=1080)
.
.
XSCF update has been completed (XSCFU=0,bank=1,XCP version=1081:last
version=1080)
XSCF is rebooting to update the reserve bank
XSCF> execute S10ioxoff -- complete
Jan 30 19:52:55 kong-sp0 XSCF[104]: XSCF shutdown sequence start

.
.
Jan 30 19:56:39 kong-sp0 XSCF[104]: XSCF Initialize complete.

.
.
Jan 30 20:04:09 kong-sp0 XSCF flashupdate[655]: XCP update has been
completed (XCP version=1081)
Synchronizing the XSCF Firmware
To synchronize the firmware across both the Active and Standby service
processors, execute the following command:
XSCF> flashupdate -c sync
Checking the XCP image file, please wait a minute
The XCP file send to stand-by XSCF, please wait a minute
The stand-by XSCF update starting, it takes about 20 minutes,
for more detail, use showmonitorlog command.
Note The sync process would be used when a failed service processor
in a high-end server has been replaced with chassis power turned off.

Exercise: Configuring the Service Processor

In this exercise, you complete the following tasks:
Perform an initial service processor login and create a user
Set the service processor date and time
Configure the XSCF external network
Enable Basic Services
Configure the DSCP network
Update the service processor firmware

Preparation
Your instructor will assign a server to each group. To complete this
exercise, you will need your servers hostname and the network
configuration. Use the Solaris cat command to read the /etc/hosts file
to determine your network settings.
Resource
NTS
IP Address
NTS Port #
Initial User Login installer
Initial User installer
Password
XSCF0-lan0
IP Address
XSCF0-lan0
netmask
XSCF0-lan1
IP Address
XSCF0-lan1
netmask
Service Processor
host name
Default Route None
IP Address
Domain 0
IP Address
Domain 0
netmask
Domain 1
IP Address
Domain 1
netmask

Task 1 Creating a User
In this task, you create a user on the service processor.
1. Open a terminal window on your local workstation.
2. Log in to your assigned service processor:
a. Open a connection to your remote MX000 server and then log
in using the following account:
username: installer
password: installer
3. Create a new user, called user1.
Which command did you use?________________________
4. Verify that the user was created.
5. Set the password for the newly created user1 to be cangetin.
6. Assign privileges to the newly created user that allow the user to
create other users, perform service processor configuration tasks, and
perform field engineer operations. Record the command:
__________________________________________________
7. Log out of the current session and log in using the user1 account.
Record your commands:
__________________________________________________
__________________________________________________
8. Verify the current user settings. Record the command used:
__________________________________________________
Task 2 Setting the Service Processor Time

In this task, you set the date and time.
1. Which privileges are required to set the date and
time?________________ or _______________
2. If needed, log in to the service processor using an account with
appropriate privileges.
a. What command did you use? _____________________________
b. What is the current time zone set to? ________________________
4. Set the appropriate time zone.
Which command did you use?__________________________________
5. Set the current date and time. (Note that the service processor will
reboot).
Which command did you use?__________________________________
6. Log back in to the service processor as the user user1.
7. Display the date and updated time:
a. What command did you use? _____________________________

Task 3 Configuring the XSCF External Network

In this task you will gather information regarding the service processor
XSCF External Network.
1. Log in to your assigned servers service processor using an account
with platadm privileges.
2. Verify the status and record the information regarding the current
XSCF External Network:
a. Which command did you use? ___________________________
b. What is the hostname of service processor?
______________________
c. What is the IP address for XSCF#0-lan0? ________________
d. What is the IP address for XSCF#0-lan1? ________________
1. What are the netmasks set to?
____________________________
3. Imagine a scenario in which the network information has changed.
Execute the commands you would use to configure the XSCF
External Network to match the information acquired in Preparation
for the lab. Record your commands below:
a. ___________________________________
b. ___________________________________
c. ___________________________________
d. ___________________________________
e. ___________________________________
f. ___________________________________

Task 4 Enabling Basic Network Services

In this task, you will enable ssh and telnet.
1. Enable telnet on your assigned service processor. Record the
commands used:
__________________________________________________
2. Enable ssh on your assigned service processor. Record the
commands used:
__________________________________________________
3. After the service processor reboots, log in as user1.
4. Verify the status of the ssh and telnet services. Record the
command used:
__________________________________________________
__________________________________________________
5. Test the External Network connection to your service processor,
using telnet:
a. Was the attempt successful? ______________________
b. If not, what is the problem? ______________________

Task 5 Configuring the DSCP Network

In this task you gather and configure information regarding the service
processor DSCP network.
1. Log in to your assigned servers service processor.
DSCP network:
a. Which command did you use? _______________________
b. What is the base network address used? ___________________
c. What is the netmask set to? _________________________
d. What is the IP for the XSCF? _________________________
e. What is the IP for Domain 00? _________________________
f. What is the IP for Domain 01? _________________________
3. Reconfigure the DSCP network so that Domain 01 will have an IP
address of 192.168.224.50.
b. Verify the network settings: _________________________
4. Reconfigure the DSCP network back to the original settings recorded
in Step 2.
b. Verify the network settings: _________________________

Task 6 Updating Firmware

In this task, you verify the existing service processor firmware and
perform a firmware update.
1. This firmware is provided in the /opt/firmware directory.
2. Configure https on your assigned service processor to allow the
import of the firmware to the service processor.
a. Log in to the service processor using an account with platadm
privileges.
b. Verify if the https service is enabled:
Which command did you use? ________________________
c. Configure the https service:
d. Enable the https service:
e. Verify the https settings:
3. Open a browser and connect to your assigned service processor by
entering the service processors IP address in the address bar. For
example, https://10.6.15.21.
4. Log in to the service processor using the BUI and the user1 account.
5. Select Utility and then Firmware Update from the drop-down
menus.
6. When prompted, select the appropriate firmware file to import:
a. For MX000 mid-range servers: /opt/firmware FFXCPxxyy.tar.gz
7. Import the firmware files to the service processor.
8. Log in to the service processor, or simply return to an open session
on the service processor.
9. Verify the current version of firmware running on the service
processor:
10. Verify the current version of firmware that has been imported to the
service processor:

11. Perform the firmware update.

12. After the service processor reboots, confirm that the firmware
version has been updated.

Exercise Summary
Exercise Summary

!
?
Experiences
Interpretations
Conclusions
Applications

Exercise Solutions
Exercise Solutions
This section contains solutions to the exercise.

Exercise Solutions
Task 1 Creating a User

In this task, you create a user on the service processor.
1. Open a terminal window on your local workstation.
2. Log in to your assigned service processor:
a. Open a connection to your remote MX000 server and then log
in using the following account:
username: installer
password: installer
3. Create a new user, called user1:
Which command did you use? adduser user1
4. Verify that the user was created.
Which command did you use? showuser -l
5. Set the password for the newly created user to be cangetin.
Which command did you use? password user1
6. Assign privileges to the newly created user that allow the user to
create other users, perform service processor configuration tasks, and
perform field engineer operations. Record the command:
setprivileges user1 platadm useradm fieldeng
7. Log out of the current session and log in using the user1 account.
exit
login: user1
8. Verify the current user settings. Record the command used:
showuser -l

Exercise Solutions
Task 2 Setting the Service Processor Time

In this task, you set the date and time.
1. Which privileges are required to set the date and time?
platadm or fieldeng
2. If needed, log in to the service processor using an account with
appropriate privileges.
a. Which command did you use? showdate
b. What is the current time zone set to? varies
4. Set the appropriate time zone.
Which command did you use?:
settimezone -c settz -s US/Eastern
5. Set the current date and time. (Note that the service processor will
reboot.)
Which command did you use?: setdate -s 0041509002009.00
6. Log back in to the service processor as the user user1.
7. Display the date and updated time:
a. What command did you use? showdate

Exercise Solutions
Task 3 Configuring the XSCF External Network

In this task you will gather information regarding the service processor
XSCF External Network.
1. Log in to your assigned servers service processor using an account
with platadm privileges.
XSCF External Network:
a. Which command did you use? shownetwork -a
b. What is the hostname of XSCF#0? answer varies
c. What is the IP address for XSCF#0-lan0? answer varies
d. What is the IP address for XSCF#0-lan1? answer varies
1. What are the netmasks set to? answer varies
3. Imagine a scenario in which the network information has changed.
Execute the commands you would use to configure the XSCF
External Network to match the information acquired in Step 2.
a. shownetwork -a
b. sethostname xscf#0 godzilla-sp0
c. setnetwork xscf#0-lan#0 -m 255.0.0.0 10.6.15.21
d. setnetwork xscf#0-lan#1 -m 255.255.255.0 192.1.1.21
e. setroute -c add -n 10.7.5.1 -m 255.0.0.0 xscf#0-lan#0
f. Apply the network settings
applynetwork

Exercise Solutions
Task 4 Enabling Basic Network Services

In this task, you enable ssh and telnet.
1. Enable telnet on your assigned service processor. Record the
commands used:
settelnet -c enable
2. Enable ssh on your assigned service processor. Record the
commands used:
setssh -c enable
3. After the service processor reboots, log in as user1.
4. Verify the status of the ssh and telnet services. Record the
command used:
showtelnet
showssh
5. Test the External Network connection to your service processor,
using telnet:
a. Was the attempt successful? ______________________
b. If not, what is the problem? ______________________

Exercise Solutions
Task 5 Configuring the DSCP Network

In this task, you gather and configure information regarding the service
processor DSCP network.
1. Log in to your assigned servers service processor.
DSCP network:
a. Which command did you use? showdscp
b. What is the base network address used? 192.168.224.0
c. What is the netmask set to? 255.255.255.0
d. What is the IP for the XSCF? 192.168.224.1
e. What is the IP for Domain 00? 192.168.224.2
f. What is the IP for Domain 01? 192.168.224.3
3. Reconfigure the DSCP network so that Domain 01 will have an IP
address of 192.168.224.50.
a. Which command did you use? setdscp
b. Verify the network settings: showdscp
4. Reconfigure the DSCP network back to the original settings recorded
in Step 2.
a. Which command did you use? setdscp
b. Verify the network settings: showdscp

Exercise Solutions
Task 6 Updating Firmware

In this task, you verify the existing service processor firmware and
perform a firmware update.
1. This firmware is provided in the /opt/firmware directory.
2. Configure https on your assigned service processor to allow the
import of the firmware to the service processor.
a. Log in to the service processor using an account with platadm
privileges.
b. Verify if the https service is enabled:
Which command did you use? showhttps
c. Configure the https service:
Which command did you use? sethttps -c selfsign US MA Burlington
SLS OPL ssp0 root@ssp0
d. Enable the https service:
What command did you use? sethttps -c enable
e. Verify the https settings:
Which command did you use? showhttps
3. Open a browser and connect to your assigned service processor by
entering the service processors IP address in the address bar. For
example, https://10.6.15.21.
4. Log in to the service processor using the BUI and the user1 account.
5. Select Utility and then Firmware Update from the drop-down
menus.
6. When prompted, select the appropriate firmware file to import:
a. For MX000 mid-range servers: /opt/firmware/FFXCPxxyy.tar.gz
7. Import the firmware files to the service processor.
8. Log in to the service processor, or simply return to an open session
9. Verify the current version of firmware running on the service
processor:
Which command did you use? version -c xcp

Exercise Solutions
10. Verify the current version of firmware that has been imported to the
service processor:
Which command did you use? getflashimage -l
11. Perform the firmware update.
Which command did you use?
flashupdate -c update -m xcp -s 1081
12. After the service processor reboots, confirm that the firmware
version has been updated.
Which command did you use? version -c xcp

Exercise Solutions

Objectives
Module 4
Platform Administration and Configuration
Objectives
Manage user accounts
Configure the service processor to make use of the Lightweight
Directory Access Protocol (LDAP)
Configure the Domain Name System (DNS)
Configure the Simple Network Management Protocol (SNMP)
View the platform environment
View hardware configurations
Manage Capacity on Demand (COD)
Use the XSCF Web
Platform Administration and Configuration 4-1

Objectives
Relevance
Discussion The following questions are relevant to understanding the

concepts of platform administration and configuration:
!
?
What are the requirements for managing the MX000 server platform?
Which tasks are associated with managing the platform?
How do you monitor the server environment?
What is Capacity on Demand?


5872-xx.
number 819-3601-xx.


http://docs.sun.com

Managing Sun SPARC Enterprise Servers
Managing Sun SPARC Enterprise Servers

Platform management for the MX000 servers consists of configuring,
monitoring, and maintaining the service processor, the platform
environment, and the domains.
This module examines:

Management of user accounts
How to configure the service processor to use LDAP and DNS
SNMP
Platform management
Hardware configuration management
COD
Note At this point, you should already have access to a properly

configured service processor.
Gathering Additional Service Processor Configuration

Information
Before continuing to configure the MX000 service processor, make sure to
have the following information:
Information for accessing the service processor with the appropriate
privileges for your tasks
Network configuration information for the service processor,
including DNS or LDAP information
Network configuration information for software monitoring
products

Managing XSCF User Accounts

The management of user accounts in the service processor requires a user
account with useradm privileges. Table 4-1 lists the administrative
commands, in the relative order in which they are initially used.
Table 4-1 User Management Commands
Command Result
setpasswordpolicy Allows an administrator to change the

system password policy
showpasswordpolicy Displays the password policy settings,
including default password expiration
settings for new accounts
disableuser Disables a local XSCF user account for
subsequent logins
Current sessions are not affected
enableuser Enables an XSCF user account
setautologout Sets the session timeout value
showautologout Displays the session timeout value
who Displays the users currently logged in
to the XSCF
Note Always refer to the Sun SPARC Enterprise Command Reference

Guide, the on-line reference guides, and man pages for a complete
definition of the options and operands for all commands listed.

The setpasswordpolicy Command

Before creating new user accounts, the system password policy must be
set. The setpasswordpolicy command allows an administrator (with
useradm privileges) to configure the system password policy. These
policies are enforced by XSCF on the service processor for all user
accounts.
The syntax for the setpasswordpolicy command is:

setpasswordpolicy [-d dcredit] [-e expiry] [-i
inactive] [-k difok] [-l lcredit] [-M maxdays] [-m
minlen] [-n mindays] [-o ocredit] [-r remember] [-u
ucredit] [-w warn] [-y retry]
The most common options and parameters for this command are:
-d dcredit Sets the maximum number of digits in a password.

Each digit counts as one credit.
-e expiry Number of days a new account will be valid before
expiring and becoming disabled. A value of zero
means that the account will not expire.
-i inactive Number of days after a password expires until the
account is locked.
-k difok Minimum number of new characters (characters
which were not present in the old password) that a
new password must contain.
-l lcredit Sets the maximum credit for lower case letters in a
password.
-M maxdays Maximum number of days that a password is valid.
-m minlen Minimum size for a new password. This value must
be six or greater.
-n mindays Minimum number of days between password
changes. A value of zero indicates that you can
change the password at any time.
-o ocredit Sets the maximum credit for non alphanumeric
characters in a password.

-r remember Number of passwords remembered in the password

history.
-u ucredit Sets the maximum credit for uppercase letters in a
password.
-w warn Default number of days before password expiration
at which to start warning the user.
-y retry Number of password request retries allowed.
The following example sets the minimum days and number of passwords
to remember:
XSCF> setpasswordpolicy -n 12 -r 5
The following example sets the minimum password length and maximum
number of days that passwords are valid.
XSCF> setpasswordpolicy -m 8 -M 30
The showpasswordpolicy Command

The showpasswordpolicy command allows an administrator
(with useradm privileges) to display the system password policy settings.

showpasswordpolicy [-h]

The following example of the showpasswordpolicy command displays

policy settings.
XSCF> showpasswordpolicy
Mindays: 0
Maxdays: 99999
Warn: 7
Inactive: -1
Expiry: 0
Retry: 3
Difok: 3
Minlen: 9
Dcredit: 1
Ucredit: 1
Lcredit: 1
Ocredit: 1
Remember: 3

The disableuser Command

The disableuser command disables a local XSCF user account for
subsequent logins. Current sessions are not affected.
When an account is disabled, it cannot be used for login. This applies to

the console, web login, and SSH. All local XSCF account data associated
with the user remains on the system, including password and SSH keys.
Note System accounts with UIDs less than 100 (such as root, bin, and
daemon), and UID 65534 and 65535 cannot be disabled.
The syntax for the disableuser command is:

disableuser user
user Specifies the user account to disable

The following example disables the bill user account:

XSCF> disableuser bill

The enableuser Command

The enableuser command enables an XSCF user account. An enabled
account can be used for login at the console, web login, or SSH. Using the
enableuser command, you can re-enable accounts disabled by the
disableuser command.
The syntax for the enableuser command is:

enableuser user
user Specifies the user account to enable

The following example enables the bill user account:

XSCF> enableuser bill

The setautologout Command

The setautologout command sets the session time out of the XSCF shell.
This command requires either the platadm or fieldeng privileges in
order to execute.

setautologout -s timeout [-h]
-s timeout Specifies the session timeout time of the XSCF shell.

Specify a timeout time value in units of minutes for
timeout. An integer ranging from 1 to 255 can be
specified.
Note The XSCFU needs to be reset for a new setautologout setting to

take effect.
The following example sets the session timeout of the XSCF shell to
30 minutes.
XSCF> setautologout -s 30
Note The default session timeout value is set to 10 minutes. The

specified session timeout becomes effective on the next login.

The showautologout Command

The showautologout command displays the session timeout of the XSCF
shell. All user privileges can execute this command.
The syntax of the showautologout command is:

showautologout [-h]
The following example displays the session timeout time of the XSCF
shell:
XSCF> showautologout
30 min

The who Command

The who command displays the users that are currently logged in to the
service processor. All user privileges can execute this command.
The syntax of the who command is:

who [-h]
The following example displays the users currently logged in to the

service processor:
XSCF> who
USER TTY IDLE FROM HOST
installer pts/0 00:00m Feb 25 16:52 spaceghost.brlg.sunedu.com

Managing XSCF User Accounts With LDAP

LDAP is a networking protocol for querying and modifying directory
services running over Transmission Control Protocol/Internet Protocol
(TCP/IP).
The LDAP service stores user authentication and privilege settings on a

server so that individual computers on the network do not need to store
the settings locally.
By default, the service processor stores user passwords and privileges

locally. Account information for users who have access to the service
processor are stored on the service processor itself.
However, if you would like to have this information stored on another

server, the service processor can be configured as an LDAP client.
Note The LDAP server must support Privileges and Users in the
LDAP schema. Reference the Sun SPARC Enterprise
M4000/M5000/M8000/M9000 Servers Administration Guide for more
information.
Note Do not confuse this with authentication and privilege lookups for
the servers domains, which are provided by the Solaris OS.
Commands Used to Configure LDAP

Four commands are used when configuring the service processor to use
LDAP authentication and privileges. These are listed in Table 4-2:
Table 4-2 LDAP Management Commands
Command Result
setlookup Enables or disables the use of the

LDAP server for authentication and
privilege lookup
showlookup Displays the configuration of the
authentication and privileges lookup

Table 4-2 LDAP Management Commands (Continued)
Command Result
setldap Configures the service processor as an
LDAP client
showldap Displays the LDAP configuration for
the service processor
General LDAP Setup Procedure

The general process for setting up the service processor to act as an LDAP
client is:
1. Enable the LDAP service.
2. Provide the LDAP server configuration information, including:
The IP address, or host name, and port of the primary LDAP
directory
The IP address, or host name, and port for one or two
alternative LDAP directories (optional)
A distinguished name (DN) of the search base to use for lookup
Whether Transport Layer Security (TLS) is to be used
3. Verify that the LDAP service is working.
Caution If you use the LDAP service, lookups are first performed
locally, and then through the LDAP server. If no privileges are specified
for a user, the setprivileges command deletes any local privilege data
for that user. Subsequently, if LDAP privilege is enabled, the users
privileges are looked up in LDAP. If the none privilege is specified for a
user, that user does not have any privileges, regardless of privilege data
in LDAP.
The setlookup Command

The setlookup command enables or disables the use of the LDAP server
for authentication and privilege lookup.

The syntax for the setlookup command is:

setlookup [-a local | ldap]
setlookup [-p local | ldap]
-a local Sets the authentication lookup to local only

-a ldap Sets the authentication lookup to look locally and
then look in the LDAP database
-p local Sets the privileges lookup to local only
-p ldap Sets the privileges lookup to look locally and then
look in the LDAP database
The following example enables LDAP lookup of privilege data:

XSCF> setlookup -p ldap
The showlookup Command

The showlookup command displays the configuration for authentication
and privilege lookup.
The syntax for the setlookup command is:

showlookup [-h]

The following example displays the current lookup configuration:

XSCF> showlookup
Privileges lookup: Local and LDAP
Authentication lookup: Local only
The setldap Command

The setldap command configures the service processor as an LDAP
client. The LDAP client only supports passwords in the UNIX Crypt or
MD5 format. Therefore, the passwords on the LDAP server must also
support these formats.
The syntax for the setldap command is:

setldap [-b bind] [-B base DN] [-c certchain] [-p]
[-s servers] [-t user] [-T LDAP timeout]
-b bind Sets the identity to use when binding to the LDAP

server. Maximum character length is 128 characters.
-B baseDN Specifies DN for the search base. Maximum
character length is 128 characters.
-c certchain Imports an LDAP server certificate chain from the
remote file specified in certchain. The certificate
chain must be in PEM format. The certificate chain
must be 64 Kbytes in size or less, and it must be
valid or it will be rejected.
-p Sets a password to use when binding to the LDAP
server. You will be prompted for the password.
-s servers Sets the primary and secondary LDAP servers and
ports. Servers is a comma-separated list of
server:port. Ports are specified numerically and
servers can be specified either by name or IP
address. For example, 10.8.31.14.636,company:636.
The first server in the list is the primary.

-b bind Sets the identity to use when binding to the LDAP

server. Maximum character length is 128 characters.
-t user Tests connections to all configured LDAP servers.
Attempts to retrieve the password data for the
specified user from each configured server and
reports success or failure in each case.
-T timeout Sets the maximum time allowed for an LDAP
search.
The showldap Command

The showldap command displays the service processors LDAP
configuration. When invoked without options, the showldap command
displays all LDAP configuration except for the certificate chain and the
password used when binding to the LDAP server.
The syntax for the showldap command is:

showldap [-c] [-h]
-c Displays the LDAP server certificate chain

The following section provides examples using both the setldap and
showldap commands for simplicity.
The following example configures a bind name:

XSCF> setldap -b user -p
Password: <Enter password>
XSCF>
XSCF> showldap
Bind Name: user

Base Distinguished Name: Not set

LDAP Search Timeout: 0
Bind Password: Set
LDAP Servers: None
CERTS: None
XSCF>
The following example configures a base DN:

XSCF> setldap -B ou=people,dc=sun,dc=com
XSCF>
XSCF> showldap
Bind Name: user
Base Distinguished Name: ou=people,dc=sun,dc=com
Bind Password: Set
LDAP Servers: None
CERTS: None
XSCF>
The following example sets the LDAP timeout value:

XSCF> setldap -T 60
XSCF>
XSCF> showldap
Bind Name: user
Base Distinguished Name: ou=people,dc=company,dc=com
Bind Password: Set
LDAP Servers: None
CERTS: None
XSCF>
The following example identifies the LDAP servers:

XSCF> setldap -s ldap://sun.com,ldaps://west.com
XSCF>
XSCF> showldap
Bind Name: user
Bind Password: Set
LDAP Servers: ldap://sun.com:389 ldaps://west.com:636
CERTS: None
XSCF>

The following setldap command imports a certificate (-c).

XSCF> setldap -c
user@remote.machine:/path/to/cacert.pem
XSCF>
sc0:opl-user> showldap
Bind Name: user
Bind Password: Set
LDAP Servers: ldap://sun.com:389 ldaps://west.com:636
CERTS: cacert.pem

Managing Additional Network Settings

This section covers the various commands that are used to manage and
retrieve basic network settings. Table 4-3 lists the commands.
Table 4-3 Additional Network Configuration Commands
Command Description
setsmtp Configures the SMTP settings

showsmtp Displays the SMTP configuration
setemailreport Configures the e-mail report configuration data
showemailreport Displays the e-mail report configuration data

The setsmtp and showsmtp Commands

The mail reporting function used by the XSCF can send messages to the
administrator and has the following features:
Notification by e-mail of any component faults in a server. Even if a
system failure or a serious error that disables reboot occurs, an
e-mail message is sent.
POP or SMTP authentication for sending of e-mail.
XSCF E-mail Notification Path
The e-mail notification path is described in Figure 4-1.
Mail server SMTP server / POP auth

SMTP auth server server
Authenti
Via SMTP sever
cation
Internet
XSCF
Parts fault
Unauthorized
Mail terminal System access
Figure 4-1 SMTP Overview
The setsmtp command configures an e-mail server for use on the XSCF.
The showsmtp command displays the current SMTP settings.
Note The setsmtp command requires platadm privileges to execute.

The showsmtp command requires either platadm or platop privileges.

The syntax of the setsmtp and showsmtp commands are:

setsmtp [-v] [-s variable] [-h]
showsmtp [-v] [-h]
The options and parameters for these commands are:

-s variable Sets the SMTP entries. Valid entries for variable
are:
mailserver, port, auth, popserver,
user, password, replyaddress
Valid entries for auth are:
none, pop, smtp-auth
The setsmtp command can also be used without options. This will
invoke an interactive mode that asks you to provide:
Name of the mail server to use
Port number to use (default is 25)
Authentication mode (none, POP, or smtp-auth)
Valid e-mail address as the reply-to address


The following example configures a mail server with POP authentication:
XSCF> setsmtp -s mailserver=10.4.1.1 -s auth=pop -s
port=25 -s user=jsmith -s password=jsmith -s
replyaddress=jsmith@company.com
The following example displays the SMTP configuration:

XSCF> showsmtp
Mail Server: 10.4.1.1
Port: 25
Authentication Mechanism: pop
POP Server:
User Name: jsmith
Password: ******
Reply Address: jsmith@company.com

The setemailreport Command

The setemailreport command configures e-mail reporting data for
remote maintenance. The command can be executed interactively or using
options. After the configuration data is configured, it is used by the fault
management daemon to send e-mail reports, as required.
Note This command requires platadm privileges to execute.
The syntax of the setemailreport command is:

setemailreport [-v] {-a | -d | -r} [-t] [-h]
-a Adds an e-mail recipient

-d Deletes an e-mail recipient
-r Replaces an e-mail
recipient
-t Sends a test e-mail
-v Displays verbose output
The following example enables e-mail reporting interactively:

XSCF> setemailreport
Enable Email Reporting? [no]:yes
Email Recipient Address :joe@10.6.15.50
Do you want to send a test mail now (Yes/No): no
The following example adds an e-mail recipient:

XSCF> setemailreport -a kathy@10.6.15.50

The showemailreport Command

The showemailreport command displays the current e-mail reporting
configuration.
Note This command requires platadm or platop privileges to execute.
The syntax of the showemailreport command is:

showemailreport[-v] [-h]

The following example displays the current e-mail reporting

configuration:
XSCF> showemailreport
EMail Reporting: enabled
Email Recipient Address: joe@10.6.15.50,
kathy@10.6.15.50

Configuring the Domain Name System

The Domain Name System (DNS) service allows computers on a network
to communicate with each other by using centrally maintained DNS
names instead of locally stored IP addresses. If you configure the service
processor to use the DNS service, it joins the DNS community and can
communicate with any other computer on the network through its DNS
server.
Commands Used to Configure DNS

To configure the service processor to use DNS, you must specify the
service processor host name, the DNS server name, and the IP address.
Two commands are used when configuring the service processor to use
DNS.
Table 4-4 DNS Management Commands
Command Result
setnameserver Sets the DNS servers to be used by the

service processor
shownameserver Displays the DNS servers configured
for use by the service processor
Note After the service processor is configured to use the DNS service, it
does not require day-to-day management. However, if you replace a
service processor board, you must reconfigure the new service processor
to use the DNS service.

The setnameserver Command

The setnameserver command sets the DNS servers used in the XSCF
network. One, two, or three DNS servers can be registered for the service
processor.
The syntax for the setnameserver command is:

setnameserver [-c add] [-c del] [-c del -a] address
-c add address Adds a host with the specified IP address as a DNS

server. This option is used together with address. If
the -c option is omitted, "-c add" is assumed.
-c del address Deletes the host with the specified IP address from
the DNS servers that are set. If the -c option is
omitted, "-c add" is assumed to be specified.
-c del -a Deletes all the DNS servers that are currently
registered. This option is used with the "-c del".
address Specifies the IP address of a DNS server to be added
or deleted using four sets of integers. Multiple
addresses, delimited by a space, can be specified.
The following example adds two hosts with the IP addresses 10.18.108.10
and 10.24.1.2 as DNS servers.
XSCF> setnameserver -c add 10.18.108.10 10.24.1.2
The following example deletes the host with the IP address 10.18.108.10.
XSCF> setnameserver -c del 10.18.108.10
The following example deletes all the DNS servers.

XSCF> setnameserver -c del -a

The shownameserver Command

The shownameserver command displays the registered DNS servers in
the XSCF network. This command does not require any specific privileges
to execute.
The following shownameserver command displays the DNS servers

currently configured:
XSCF> shownameserver
nameserver 192.168.1.2

Configuring SNMP
Configuring SNMP
Simple Network Management Protocol (SNMP) is an application-layer
protocol that facilitates the exchange of management information between
network devices. It is a standard part of the TCP/IP protocol suite.
In essence, SNMP is a protocol for managing networks. The SNMP

manager consolidates management of the operating conditions and the
SNMP agent responds with management information from the
Management Information Base (MIB) to requests from the manager.
There is also a function called TRAP which is used by the SNMP agent to
exchange special information in asynchronous communication with the
SNMP manager. The SNMP agent uses the 161 port and the 162 port for
traps by default (see Figure 4-2).
Figure 4-2 SNMP Overview

Configuring SNMP
SNMP Traps
When an event occurs, the SNMP agent function notifies the SNMP
manager of the event. This function is called a TRAP. The XSCF TRAP
covers the following events (see Figure 4-3):
XSCF SNMP agent startup
Occurrences of unauthorized access to the XSCF SNMP agent
Hardware fault occurrences in the system
Replacement of a faulty component in the system and system
recovery
Notification of another XSCF event
System
XSCF
Trap issued
XSCF SNMP agent function started
System
XSCF
Unauthorized access to XSCF SNMP agent
System
SNMP manager
XSCF
Parts fault
System
XSCF
Faulty part replaced
System
XSCF
Event reports.
Figure 4-3 SNMP Trap Events

Configuring SNMP
The service processor can export the following information to any SNMP
manager:
System information, such as chassis ID, platform type, total number
of CPUs, and total memory
Configuration of the MX000 server hardware
Dynamic reconfiguration information, including which
domain-configurable units are assigned to which domains
Domain status
Power status
Environmental status
Setup Information
The SNMP agent on the service processor is disabled by default and must
be configured and enabled by an administrator. The SNMP agent that is
bundled in the XSCF software includes the standard version 3 (v3)
protocols for:
User management
User Security Model (USM)
View Access Control Model (VACM)

Configuring SNMP
Commands Used to Configure SNMP

SNMP is configured using the commands shown in Table 4-5.
Table 4-5 SNMP Commands
Command Result
setsnmp Manages the SNMP agent

showsnmp Displays the SNMP agent status
setsnmpvacm Modifies the SNMP agents VACM
configuration
setsnmpusm Modifies the SNMP agents USM
configuration
setsunmc Manages the Sun Management Center agent
showsunmc Displays the Sun Management Center agent
status
The setsnmp Command

The setsnmp command enables or disables the SNMP agent and
configures the SNMP agent settings.
The syntax of the setsnmp command is:

setsnmp [enable | disable] [mib_name] [-l system-
location] [-c system-contact] [-d system-description]
[-p port] [addtraphost -t type -s community-string -p
trap-port traphost] [remtraphost -t type traphost] [-h]
enable Activates the SNMP agent with support for all

MIB modules.
disable Stops the SNMP agent.

Configuring SNMP
mib_name Name of the MIB module to be disabled. Valid

MIB modules are:
SP_MIB OPL-SP-MIB
FM_MIB SUN-FM-MIB
ALL All the MIB modules in this list.
addtraphost Enables the SNMP agent to send the chosen
type of trap to the desired host. If no trap-port is
provided, the default is 162. A community
string is mandatory.
remtraphost Disables the SNMP agent from sending the
chosen type of trap.
-t type Valid trap types are:
v1 = SNMPv1 traps
v2 = SNMPv2 traps
-c system-contact System contact information.
-d description System description for the agent.
-l location System location for the agent.
-p port Listening port for the agent. The default is 161.
-s string Text string that acts similar to a password to
control access to the SNMP v1 and v2 agents. It
is a clear text string which can be intercepted.
The following command is used to configure system information for an

M4000 server in San Diego:
XSCF> setsnmp -l sandiego -c joe@10.6.15.50 -d M4000
The following command is used to configure a trap host with password

options on port 161.
XSCF> setsnmp addtraphost -t v1 -s test -p 161
10.6.15.50
The following example is used to start the agent.

XSCF> setsnmp enable ALL

Configuring SNMP
The showsnmp Command

The showsnmp command displays the configuration information and
current status of the SNMP agent.
The syntax for the showsnmp command is:

showsnmp [-h]
The following example displays the SNMP configuration:

XSCF> showsnmp
Agent Status: Enabled
Agent Port: 161
System Location: SanDiego
System Contact: joe@10.6.15.50
System Description: M4000
Trap Hosts:
Hostname Port Type Community String Username Auth Protocol
-------- ---- ---- ---------------- -------- --------------
10.6.15.50 161 v1 test joe SHA
SNMP V1/V2c:
Status: Enabled
Community String: public
Enabled MIB Modules:

SP_MIB
FM_MIB

Configuring SNMP
The setsnmpusm Command

The setsnmpusm command specifies the SNMP agents USM
configuration.
The setsnmpusm command syntax is:

setsnmpusm create [-a authentication_protocol] [-p
authentication_password] [-e encyrption_password] user
setsnmpusm delete user
setsnmpusm clone -u clone_user user
setsnmpusm passwd [-c {auth|encrypt}] [-o old_password]
[-n new_password] user
create user Makes the supplied user known to the agent

for subsequent SNMP communication.
Specifies a valid user name.
-a authentication_protocol Specifies the authentication protocol.
-e encryption_password Specifies the encryption password.
-p authentication_password Specifies the authentication password.
delete user Removes the supplied user, making the user
unknown to the agent for subsequent SNMP
communication.
clone -u clone_user user Makes the supplied user known to the agent
for subsequent SNMP communication using
the identical settings as the specified
clone_user.
passwd Changes the appropriate password.
-c auth | encrypt Specifies whether to change the
authentication password or the encrypted
password.
-n new_password Specifies the new password. The password

must be equal to or greater than 8 characters.
Specifies the old password.

-o old_password

Configuring SNMP
The following example adds a user with password options.

XSCF> setsnmpusm create -a SHA -p xxxxxxxx jeff
The following example adds a user without specifying password options.

XSCF> setsnmpusm create -a SHA bob
Authetication Password:
Encryption Password:
The following example clones a user.

XSCF> setsnmpusm clone -u jeff joe
Authentication Password:
Encryption Password:
The following example deletes a user.

XSCF> setsnmpusm delete joe
The setsnmpvacm Command

The setsnmpvacm command modifies the SNMP agents VACM
configuration. Upon initialization, the VACM module registers as the
access control module with the agent infrastructure. The VACM module
implements access control checks according to several parameters that are
derived from the SNMP message.
The setsnmpvacm command syntax is:

setsnmpvacm creategroup -u username groupname
setsnmpvacm deletegroup -u username groupname
setsnmpvacm createview [-s OID_subtree] [-e] [-m
OID_Mask] viewname
setsnmpvacm deleteview [-s OID_subtree] viewname
setsnmpvacm createaccess [-r read_viewname] groupname
setsnmpvacm deleteaccess groupname

Configuring SNMP
createaccess Sets access to a MIB view for the specified group.
-r read_viewname Specifies an SNMP Agent view.

groupname Specifies a valid group name.
creategroup Sets up a group for view access.
-u username Specifies a valid user name.

createview Creates a view of the SNMP agent information.
-e Specifies an excluded view.

-m OID_Mask Specifies a valid OID subtree mask.
-s OID_subtree Specifies a MIB OID subtree.
viewname Specifies a valid view name.
deleteaccess groupname Removes access entry to the specified group name.
deletegroup Removes a group from use.
-u username Specifies a valid user name.

deleteview Removes this view from use.
-s OID_subtree Specifies a MIB OID subtree.

viewname Specifies a valid view name.
The following example creates a group.

XSCF> setsnmpvacm creategroup -u jsmith admin
The following example creates a view of the entire MIB.

XSCF> setsnmpvacm createview -s .1 all_view

Configuring SNMP
The setsunmc Command

The setsunmc command starts or stops the Sun Management Center
agent and modifies its configuration. When invoked with one or more of
the options, setsunmc makes changes to the agent configuration. When
invoked with the operands enable or disable, setsunmc starts or stops
the agent and notifies the startup daemon to persist the behavior across
reboots. The operands cannot be used together with the options.
Note This command requires platadm or fieldeng privileges to

execute.
The setsunmc command syntax is:

setsunmc {enable | disable}
setsunmc [-s server] [-z seed] [-c community_string]
[-p agent_port] [-t trap_port] [-e event_port]
[-a SNMP_agent_port] [-d dmn_agent_port] [-F] [-h]

Configuring SNMP
enable Activates the Sun Management Center agent.

disable Stops the Sun Management Center agent.
-a SNMP_agent_port Specifies the listening port on the SNMP agent.
-c community_string Specifies the community string used for SNMPv1
trap host SNMP setup.
-d dmn_agent_port Specifies the port for the Sun Management Center
agents running on the domains.
-e event_port Specifies the port on the Sun Management Center
server to which events are sent.
-p agent_port Specifies the port number that the Sun Management
Center agent listens on.
-s server Specifies the Sun Management Center server with
which the agent will be communicating.
-t trap_port Specifies the port on the Sun Management Center
server to which traps are sent.
-z seed Specifies the seed to generate a security key for
communication between server and agent.
-h Displays usage statement.
The following example creates a group.

XSCF> setsunmc -s 10.6.15.50 -z maplesyr
setsunmc: Updating Sun MC config file
Agent started successfully.
The following example stops the agent.

XSCF> setsunmc disable
setsunmc: Agent disabled.
setsunmc: Note that this command will return before
SunMC is completely disabled.

Configuring SNMP
The showsunmc Command

The showsunmc command shows the setup information and status of the
Sun Management Center agent.
Note This command requires platadm, platop, or fieldeng privileges

to execute.
The showsunmc command syntax is:

showsunmc [isenabled] [-h]
isenabled Displays only the agent status. The value 1 indicates

the agent is enabled; 0 indicates the agent is
disabled.
-h Displays usage statement.
The following example displays the setup information and the agent
status.
XSCF> showsunmc
Agent Status: Enabled, running
Setup Status: Set up
SunMC Server: 10.6.15.50
Security Seed: maplesyr
SNMPv1 Community String: public
Agent Port: 1161
Host Trap Port: 162
Host Event Port: 163
SNMP Agent Port: 161
Domain Agent Port: 1161
The following example displays just the agent status.

XSCF> showsunmc isenabled
1

Managing the Server Environment

Several commands are available to view the server settings and
configuration status of the MX000 servers. The commands available are
shown in Table 4-6.
Table 4-6 Platform Status Commands
Command Result
setaltitude Sets the altitude for the server

showaltitude Displays the current altitude setting
showenvironment Displays temperature, humidity, fan, and voltage
status
setlocator Sets the locator LED status
showlocator Displays the locator LED status
setpowerupdelay Sets the warm-up time of the system and wait time
before system startup
showpowerupdelay Displays the current settings for the power-up delay
setshutdowndelay Sets the shutdown wait time in case of interruption to
the uninterruptable power supply (UPS)
showshutdowndelay Displays the shutdown wait time

The setaltitude Command

The setaltitude command sets the altitude of the system. The effect of
setting the systems altitude is to modify the thresholds at which the fans
change speed due to the difference in cooling capability at different
altitudes.
The setaltitude command syntax is:

setaltitude -s altitude=value
-s altitude=value Sets the altitude to the specified value

In the following example, the altitude is set on a mid-range server to 1000

meters (m):
XSCF> setaltitude -s altitude=1000
1000m
In the following example, the altitude is set on a high-end server to 90m.

Notice that the result is set to 100m.
XSCF> setaltitude -s altitude=90
100m
Note If a value greater than 0m and less then 100m is specified, the
setting will still default to 100m and all values are rounded up to the
nearest 100m.
Note The specified altitude becomes valid when the service processor is
rebooted. The showaltitude man page has yet to be updated to state
this correctly. Refer to the current XCP release notes for more information.

Setting the altitude impacts the fan speed levels and ultimately the
temperature of the MX000 servers as shown in Table 4-7, Table 4-8, and
Table 4-9.
Table 4-7 Fan speed levels corresponding to altitude and environmental
temperature (Entry-level system)
Fan Speed 500m or 501 to 1001 to 1501 to

Levels less 1000m 1500m 3000m
Low speed 20C or less 18C or less 16C or less 14C or less
(level 1)
Low speed 19-22C 17-20C 15-18C 13-16C
(level 2)
Low speed 21-24C 19-22C 17-20C 15-18C
(level 3)
Low speed 23-26C 21-24C 19-22C 17-20C
(level 4)
Middle 25-28C 23-26C 21-24C 19-22C
speed
(level 5)
Middle 27-30C 25-28C 23-26C 21-24C
speed
(level 6)
High speed 29-32C 27-30C 25-28C 23-26C
(level 7)
High speed 31-34C 29-32C 27-30C 25-28C
(level 8)
High speed More than More than More than More than
(level 9) 33C 31C 29C 27C


temperature (Mid-range servers)

Middle 23-30C 21-28C 19-26C 17-24C

speed
28C 26C 24C 22C

temperature (High-end servers)

24C 22C 20C 18C

The showaltitude Command

The showaltitude command displays the current settings for the altitude
and mounting state of filters of the MX000 servers.

showaltitude [-h]
The following example displays the altitude of an MX000 server:

XSCF> showaltitude
100m

The showenvironment Command

The showenvironment command displays the following types of
information for the server:
Environment Intake temperature and humidity of the system
(humidity is only displayed for high-end servers)
Temperature Intake temperature of the system and exhaust
temperature for each component
Voltage Voltage sensor values
Fan rotation Fan rotational state and revolutions per unit of time
Note This command requires either useradm, platadm, platop, or

fieldeng to execute.
The syntax for the showenvironment command is:

showenvironment [-M] [type] [-h]
-M Displays output page by page. Similar to the more

command.
type Specifies a type of information to display. Valid
types are: temp, volt, and Fan
The following command displays the intake temperature (and humidity

on the high-end servers):
XSCF> showenvironment
Temperature:30.7C
Humidity:20%

The following command displays temperature information for a high-end

server and each CMU within the server:
XSCF> showenvironment temp
Temperature:29.72C
CMU#0:37.50C
CPUM#0-CHIP#0:43.09C
CMU#1:37.00C
The following example displays temperature information for a mid-range

server.
MBU_B
IOU#0:30.00C
The following example displays temperature information for an entry-

level server.

Temperature:20.00C
MBU_A:0.00C
CPU-CHIP:0.00C

The setlocator Command

The setlocator command controls the status of the check LED on the
operator panel of the servers cabinet. The check LED can be used to help
identify a particular server in a data center or to serve as a visual
indication or reminder to perform service on that server.
The setlocator command syntax is:

setlocator value [-h]
value Valid values are:

blink Sets the LED to blink
reset Sets the LED to stop blinking

The following example sets the check LED to blink:

XSCF> setlocator blink
The following example stops the check LED from blinking:

XSCF> setlocator reset

The showlocator Command

The showlocator command displays the status of the check LED.
The syntax for the showlocator command is:

showlocator [-h]
The following example sets the check LED to blink:

XSCF> setlocator blink
XSCF> showlocator
Locator LED status:Blinking

The setpowerupdelay Commands

The setpowerupdelay command sets the wait time and warmup time
before the system startup. The wait and warmup times are used to ensure
that the ambient temperature is suitable for system operation.
Wait Time
The air-conditioning wait time is intended to prevent the server from

performing power-on processing until the room temperature environment
is prepared by air-conditioning facilities. Once the air-conditioning wait
time is set, the server will start power-on processing after its input power
supply is turned on and the set air-conditioning time elapses.
Warmup Time
The warm-up time is intended to prevent the PSU and the FAN from
running until the power supply environments of peripheral units are
prepared after the server starts the power-on processing. Once the warm-
up time is set, the OpenBoot PROM will start after the server power
supply is turned on, the power-on processing starts, and the set warm-up
time elapses.
If the system power has already been turned on and the system is
operating, the setting takes effect at the next startup.
Note The setpowerupdelay command requires either platadm or

fieldeng privileges to execute.

The syntax for the setpowerupdelay command is:

setpowerupdelay -c warmup -s time
setpowerupdelay -c wait -s time
setpowerupdelay -h
-c warmup Specifies the warmup time

-c wait Specifies the wait time
-s time Specifies the warm-up time or wait
time before system startup in minutes,
from 0 to 255
The following example sets the warm-up time to 10 minutes:

XSCF> setpowerupdelay -c warmup -s 10
The following example sets the wait time to 20 minutes:

XSCF> setpowerupdelay -c wait -s 20

The showpowerupdelay Command

The showpowerupdelay command displays the current settings for the
system startup wait time and warm-up time.
Note This command requires one of the following privileges to execute:

platadm, platop, domainadm, domainmgr, domainop, or fieldeng.
The syntax for the showpowerupdelay command is:

showpowerupdelay [-h]
The following example displays the current settings for the wait time and
warmup time:
XSCF> showpowerupdelay
warmup time : 10 minute(s)
wait time : 20 minute(s)

The setshutdowndelay Command

The setshutdowndelay command sets the wait time before the system
begins to shut down due to a power interruption to the UPS.
If a power recovery is reported by the UPS within the specified time, then
a shutdown will not occur.
Note This command requires either platadm or fieldeng privileges to

execute.
The syntax for the setshutdowndelay command is:

setshutdowndelay -s time [-h]
-s time Specifies the wait time before system shutdown,

specified in seconds ranging from 0 to 9999. The
default value is 10 seconds.
The following example sets the shutdown delay to 5 minutes:

XSCF> setshutdowndelay -s 300

The showshutdowndelay Command

The showshutdowndelay command displays the current setting for the
shutdown delay related to a UPS power interruption.
Note This command requires any of the following privileges to execute:

platadm, platop, domainadm, domainmgr, domainop, or fieldeng.
The syntax for the showshutdowndelay command is:

showshutdowndelay [-h]
The following example displays the current setting for the shutdown
delay in seconds:
XSCF> showshutdowndelay
UPS shutdown wait time : 300 second(s)

Viewing Hardware Status and Configurations

Several commands are available to view the hardware configuration,
power, and cooling status of the MX000 servers. The commands available
are shown in Table 4-10.
Table 4-10 Hardware Status Commands
Command Result
showhardconf Displays information for field replaceable units (FRUs)

showstatus Displays information about degraded units
replacefru Replaces a field replaceable unit (FRU)
testsb Performs an initial diagnosis of the specified physical
system board (PSB) set
prtfru Displays FRUID data for the platform
cfgdevice Assigns the DVD/DAT drive
(High-end servers)
switchscf Switches the XSCF unit between active and standby
(High-end servers)
clockboard Sets the master clock board to be used for system
startup
(High-end servers)

The showhardconf Command

The showhardconf command displays information about FRUs installed
in the server, including:
Current configuration and status
Number of installed FRUs
Domain information
IO-Box information
Properties of PCI cards
Status States
The status for each FRU may be any of the following states:
Normal The unit is functioning normally.
Maintenance The unit is in a maintenance state.
Faulted The unit has been degraded due to a failure.
Degraded The unit has been partially degraded.
Deconfigured A unit has been degraded due to an error, or a unit
that was normal has now been degraded because another unit was
degraded.

The syntax for the showhardconf command is:

showhardconf [-u] [-M]
-M Displays text one page at a time. This option

provides a function that is similar to the more
command.
-u Displays the number of FRUs installed in each unit.
For CPU modules, operating frequencies are
displayed. For memory units, the capacity of each
memory unit is displayed. If this option is omitted,
the current configuration and status information
regarding FRUs and domain information are
displayed.

M8000 Sample Command Output
The following example displays the configuration of an M8000 server:

XSCF> showhardconf
SPARC Enterprise M8000;
+ Serial:2030643007; Operator_Panel_Switch:Locked;
+ Power_Supply_System:Dual-1Phase; SCF-ID:XSCF#1;
+ System_Power:On; System_Phase:Cabinet Power On;
Domain#0 Domain_Status:OpenBoot Execution Completed;
Domain#1 Domain_Status:Powered Off;
CMU#0 Status:Normal; Ver:0101h; Serial:PP0640T672 ;

+ FRU-Part-Number:CA06620-D001 A8 ;
+ Memory_Size:48 GB;
CPUM#0-CHIP#0 Status:Normal; Ver:0201h; Serial:PP06445076 ;
+ Freq:2.280 GHz; Type:16;
+ Core:2; Strand:2;
CPUM#1-CHIP#0 Status:Normal; Ver:0201h; Serial:PP0645B252 ;
+ Core:2; Strand:2;
+ Core:2; Strand:2;
+ Core:2; Strand:2;
MEM#00A Status:Normal;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d504d385;
+ Type:2B; Size:2 GB;
MEM#00B Status:Normal;
+ Code:c1000000000000005372T128000HR3.7A 352f-0d054324;
+ Type:1A; Size:1 GB;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d504d34b;
+ Code:ce0000000000000001M3 93T2950CZ3-CD5 3343-46009e56;

+ Code:c1000000000000005372T128000HR3.7A 352f-0d054027;
+ Code:c1000000000000005372T128000HR3.7A 352f-0d054820;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d504d38c;
+ Code:ce0000000000000001M3 93T2950CZ3-CD5 3343-46009f19;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409db0f;
+ Code:ce0000000000000001M3 93T2950CZ3-CD5 3343-46009f25;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409dafb;
+ Code:ce0000000000000001M3 93T2950CZ3-CD5 3343-46009ec8;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d504d3e0;
+ Code:ce0000000000000001M3 93T2950CZ3-CD5 3343-46009ec4;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d504d3e4;
+ Code:ce0000000000000001M3 93T2950CZ3-CD5 3343-46009e62;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409daf0;
+ Code:ce0000000000000001M3 93T2950CZ3-CD5 3343-46009e35;

+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409da83;
+ Code:c1000000000000005372T128000HR3.7A 352f-0d054b25;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409daea;
+ Code:c1000000000000005372T128000HR3.7A 352f-0d054327;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409db09;
+ Code:c1000000000000005372T128000HR3.7A 352f-0d053f22;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d504d38a;
+ Code:ce0000000000000001M3 93T2950CZ3-CD5 3343-46009f18;
+ Code:c1000000000000005372T128000HR3.7A 352f-0d054423;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409daed;
+ Code:c1000000000000005372T128000HR3.7A 352f-0d054921;
CMU#1 Status:Normal; Ver:0101h; Serial:PP0640T679 ;
+ Memory_Size:64 GB;
+ Core:2; Strand:2;
CPUM#1-CHIP#0 Status:Normal; Ver:0201h; Serial:PP0646C268 ;
+ Core:2; Strand:2;


+ Core:2; Strand:2;
+ Core:2; Strand:2;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409db2c;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409dad5;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409dadd;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409dae6;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409dac5;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409dad0;


+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409daaa;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409dadb;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409da2f;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409da6b;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409dab4;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409dd9d;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409ddb5;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409dda4;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d409dd93;

+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d504d3aa;
+ Code:2cffffffffffffff0836HTF25672Y-53EB1 0100-d504d38b;
IOU#0 Status:Normal; Ver:0101h; Serial:PP06433532 ;
PCI#0 Name_Property:pci; Card_Type:IOUA;
IOU#1 Status:Normal; Ver:0101h; Serial:PP06420636 ;
XSCFU_B#0 Status:Normal,Standby; Ver:0201h; Serial:PP0711002C ;
+ FRU-Part-Number:CA06620-D342 B0 /371-2228-02 ;
XSCFU_B#1 Status:Normal,Active; Ver:0201h; Serial:PP0638J133 ;
BP_A#0 Status:Normal; Ver:0101h; Serial:PP0640S354 ;
+ FRU-Part-Number:CA20006-B37X 013AL ;
DDC_A#0 Status:Normal; Ver:05D; Serial:MD06440124;
+ FRU-Part-Number:CA01022-0680 05D /371-2227-04 ;
DDC_A#1 Status:Normal; Ver:05D; Serial:MD06440096;
+ FRU-Part-Number:CA01022-0680 05D /371-2227-04 ;
OPNL#0 Status:Normal; Ver:0101h; Serial:PP0640S619 ;
PSU#0 Status:Normal; Serial:;
+ FRU-Part-Number:CA01022-0690;
+ Power_Status:On;
+ Power_Status:On;
+ Power_Status:On;
+ Power_Status:On;
+ Power_Status:On;

+ Power_Status:On;
+ Power_Status:On;
+ Power_Status:On;
+ Power_Status:On;
+ Power_Status:Breaker off;
FANBP_C#0 Status:Normal; Ver:0301h; Serial:PP0637A712 ;
+ FRU-Part-Number:CA21128-B73X 004AC ;
FAN_A#0 Status:Normal; Serial:PP0637D547;
+ FRU-Part-Number:CA06622-D011 A0;

FAN_B#0 Status:Normal; Serial:PP0637C351;
FANBP_C#1 Status:Normal; Ver:0301h; Serial:PP0637A732 ;
SWBP#0 Status:Normal; Ver:0101h; Serial:PP06369451 ;
+ FRU-Part-Number:CA20396-B67X 006AE ;
MEDBP#0 Status:Normal; Ver:0101h; Serial:PP0638F685 ;

The following example displays the number of installed FRUs in this

M8000 server:
XSCF> showhardconf -u
SPARC Enterprise M8000; Memory_Size:112 GB;
+-----------------------------------+------------+
| FRU | Quantity |
+-----------------------------------+------------+
| CMU | 2 |
| CPUM | 8 |
| Freq:2.280 GHz; | ( 8) |
| MEM | 64 |
| Type:1A; Size:1 GB; | ( 16) |
| Type:2B; Size:2 GB; | ( 48) |
| IOU | 2 |
| XSCFU_B | 2 |
| BP_A | 1 |
| DDCA | 2 |
| OPNL | 1 |
| PSU | 18 |
| FANBP_C | 2 |
| FAN_A | 4 |
| FAN_B | 8 |
| SWBP | 1 |
| MEDBP | 1 |
+-----------------------------------+------------+

The showstatus Command

The showstatus command displays information about degraded units in
the server.
The showstatus command syntax is:

showstatus [-M] [-h]
-M Displays text page by page (similar to

the more command)
The following example displays a CPU module and memory module in a

CPU memory unit that are degraded because of an error:
XSCF> showstatus
CMU#0;
* CPUM#0-Chip#0; Status:Faulted;
* MEM#00A; Status:Faulted;
The following example displays a memory module on a memory board

that is degraded because of an error:
XSCF> showstatus
MBU_B;
MEMB#0;
* MEM#0A; Status:Faulted;
The following example displays a CPU memory unit and memory module
on a motherboard that are degraded because of an error:
XSCF> showstatus
* CMU#0; Status:Deconfigured;
* XBU_B#0; Status:Faulted;

The replacefru Command

The replacefru command allows the user to select, confirm, and replace
the following FRUs using an interactive menu:
CPU memory unit (CMU) (M8000 and M9000 servers)
I/O unit (IOU) (M8000 and M9000 servers)
FAN unit (FANU)
Power supply unit (PSU)
XSCF unit (XSCFU) (M8000 and M9000 servers)
DDC (M8000 server only)
Note This command requires fieldeng privileges to execute.
The syntax for the replacefru command is: replacefru -h
The following example displays the usage of the replacefru command

and the sub-menus for a high-end server:
XSCF> replacefru
---------------------------------------------------------------
Maintenance/Replacement Menu
Please select a type of FRU to be replaced.
1. CMU/IOU (CPU Memory Board Unit/IO Unit)

2. FAN (Fan Unit)
3. PSU (Power Supply Unit)
4. XSCFU (Extended System Control Facility Unit)
5. DDC_A (DDC for BP_A)
---------------------------------------------------------------

Select [1-5|c:cancel] :1
---------------------------------------------------------------
Please select whether to replace a CMU only, an IOU only,
or both a CMU and an IOU.
1. Replace CMU only.

2. Replace IOU only.
3. Replace both CMU and IOU.
---------------------------------------------------------------
Select [1-3|b:back] :1
---------------------------------------------------------------
Please select a CMU to be replaced.
DomainID
No. FRU XSB#0 XSB#1 XSB#2 XSB#3 Power Status
--- ------------- ----------------------- ----- ---------------
1. CMU#0 SP SP SP SP Off Normal
2. CMU#1 SP SP SP SP Off Normal
3. CMU#2 -- -- -- -- --- Not installed
4. CMU#3 -- -- -- -- --- Not installed
---------------------------------------------------------------
Select [1-4|b:back] :b
---------------------------------------------------------------

---------------------------------------------------------------
---------------------------------------------------------------
Please select an IOU to be replaced.
DomainID
--- ------------- ----------------------- ----- ---------------
1. IOU#0 SP SP SP SP Off Normal

2. IOU#1 SP SP SP SP Off Normal

3. IOU#2 -- -- -- -- --- Not installed
4. IOU#3 -- -- -- -- --- Not installed
---------------------------------------------------------------
---------------------------------------------------------------

---------------------------------------------------------------
---------------------------------------------------------------
Please select a CMU/IOU to be replaced.
DomainID
--- ------------- ----------------------- ----- ---------------
1. CMU#0/IOU#0 SP SP SP SP Off Normal
2. CMU#1/IOU#1 SP SP SP SP Off Normal
3. CMU#2/IOU#2 -- -- -- -- --- Not installed
4. CMU#3/IOU#3 -- -- -- -- --- Not installed
---------------------------------------------------------------
---------------------------------------------------------------

---------------------------------------------------------------
---------------------------------------------------------------


2. FAN (Fan Unit)
---------------------------------------------------------------
---------------------------------------------------------------
Please select a FAN to be replaced.
No. FRU Status

--- --------------- ------------------
1. FAN_A#0 Normal
2. FAN_A#1 Normal
3. FAN_A#2 Normal
4. FAN_A#3 Normal
5. FAN_B#0 Normal
6. FAN_B#1 Normal
7. FAN_B#2 Normal
8. FAN_B#3 Normal
9. FAN_B#4 Normal
10. FAN_B#5 Normal
11. FAN_B#6 Normal
12. FAN_B#7 Normal
---------------------------------------------------------------
---------------------------------------------------------------

2. FAN (Fan Unit)
---------------------------------------------------------------
---------------------------------------------------------------
Please select a PSU to be replaced.
No. FRU Status

--- --------------- ------------------

1. PSU#0 Normal
2. PSU#1 Normal
3. PSU#2 Normal
4. PSU#3 Normal
5. PSU#4 Normal
6. PSU#5 Normal
7. PSU#6 Normal
8. PSU#7 Normal
9. PSU#8 Normal
10. PSU#40 Normal
11. PSU#41 Normal
12. PSU#42 Normal
13. PSU#43 Normal
14. PSU#44 Normal
15. PSU#45 Normal
16. PSU#46 Normal
17. PSU#47 Normal
18. PSU#48 Normal
---------------------------------------------------------------
---------------------------------------------------------------

2. FAN (Fan Unit)
---------------------------------------------------------------
---------------------------------------------------------------
Please select an XSCF to be replaced.
No. FRU Status

--- --------------- ------------------
1. XSCFU_B#0 Active
2. XSCFU_B#1 Not Ready
---------------------------------------------------------------
Select [1,2|b:back] :b

---------------------------------------------------------------

2. FAN (Fan Unit)
---------------------------------------------------------------
---------------------------------------------------------------
Please select a DDC_A to be replaced.
No. FRU Status

--- --------------- ------------------
1. DDC_A#0 Normal
2. DDC_A#1 Normal
---------------------------------------------------------------
Select [1,2|b:back] :b
---------------------------------------------------------------

2. FAN (Fan Unit)
---------------------------------------------------------------
Select [1-5|c:cancel] :c

The testsb Command

The testsb command performs an initial diagnosis of the specified
physical system board (PSB). The configuration of the PSB and operation
of each device mounted on the PSB are checked.
The selected PSB must not be configured in a domain, or the domain in

which the PSB is configured must be powered off.

execute.
The syntax for the testsb command is:

testsb [ [-q] -{y|n}] [-m diag=mode] location
testsb [ [-q] -{y|n}] -v [-m diag=mode] location
-m diag-mode Specifies the diagnostic level of initial diagnosis.

Valid values for diag=mode are:
min Normal (default)
max Maximum
-n Automatically answers 'n' (no) to all prompts.
prompts.
-v Displays a detailed message of initial diagnosis. If
this option is specified with the -q option, the -v
option is ignored.
-y Automatically answers 'y' (yes) to all prompts.
location Specifies the PSB number. An integer from 00-15
can be specified.

The following example performs an initial test on PSB 00:

XSCF> testsb 0
Initial diagnosis is about to start, Continue?[y|n] :y
SB#00 power on sequence started.
0..... 30...end
Initial diagnosis started. [1800sec]
0..... 30..... 60.....end
Initial diagnosis has completed.
SB power off sequence started. [1200sec]
0.end
SB powered off.
XSB Test Fault
---- ------- --------
00-0 Passed Normal
Where:
XSB One XSB number is displayed for the Uni-XSB type,

and four XSB numbers are displayed for the Quad-XSB
type.
Test Status of the initial diagnosis of XSBs. One of the
following status is displayed:
Umount No XSB could be recognized because
no XSB is mounted or because an error occurred.
Unknown Not tested.
Testing Initial diagnosis is in progress.
Passed Initial diagnosis ended normally.
Failed An error was detected during the initial
diagnosis.
Fault Displays XSB errors. One or more states are displayed:
Normal No errors.
Degraded One or more components are
degraded. Each XSB can still operate, however.
Faulted An XSB cannot operate because an
error occurred.

The prtfru Command

The prtfru command is used to obtain Field-Replaceable Unit Identifier
(FRIUID) data from the system. Its output is a tree structure, echoing the
path in the FRU tree to each container.
When a container is found, the data from that container is printed in a tree
structure as well. Without any arguments, the command prints the FRU
hierarchy and all of the FRUID container data.
Note The prtfru command requires either platadm or fieldeng

privileges to execute.
The syntax for the prtfru command is:

prtfru [-c] [-l] [-M] [-x] container -h
-c Prints only the containers and their

data. This option does not print the
FRU tree hierarchy.
-l Prints the FRU tree hierarchy and lists
the available containers. This option
does not print the container data.
-M Displays text by page. This option
provides a function that is the same as
that of the more command.
-x Prints in XML format.
container Specifies which hardware component
to display FRU data for. The available
containers are displayed using the -l
option.

The following example prints the FRU tree and lists the available
containers:
XSCF> prtfru -l
/frutree
/frutree/chassis (fru)
/frutree/chassis/CMU#0 (fru)
/frutree/chassis/CMU#0/CMU (container)
/frutree/chassis/CMU#0/CMU/CPUM#0/CPUM (container)
/frutree/chassis/CMU#0/CMU/MEM#0/MEM (container)
... <output omitted>
/frutree/chassis/CMU#1 (fru)
/frutree/chassis/CMU#1/CMU (container)
... <output omitted>
/frutree/chassis/IOU#0 (fru)
/frutree/chassis/IOU#0/IOU (container)
/frutree/chassis/IOU#0/IOU/IOUA#0/IOUA (container)
/frutree/chassis/IOU#0/IOU/IOUA#2/IOUA (container)
/frutree/chassis/IOU#1 (fru)
/frutree/chassis/IOU#1/IOU (container)
/frutree/chassis/PSU#0 (fru)
/frutree/chassis/PSU#0/PSU (container)
...<output omitted>

/frutree/chassis/FANBP_C#0 (fru)
/frutree/chassis/FANBP_C#0/FANBP_C (container)
/frutree/chassis/FANBP_C#1 (fru)
/frutree/chassis/FANBP_C#1/FANBP_C (container)
/frutree/chassis/FAN_B#0 (fru)
/frutree/chassis/FAN_B#0/FAN_B (container)
/frutree/chassis/FAN_A#0 (fru)
/frutree/chassis/FAN_A#0/FAN_A (container)
/frutree/chassis/BP_A (container)
/frutree/chassis/BP_A/DDC#0/DDC (container)
/frutree/chassis/BP_A/DDC#1/DDC (container)
/frutree/chassis/SWBP#0 (fru)
/frutree/chassis/SWBP0/SWBP (container)
/frutree/chassis/MEDBP#0 (fru)
/frutree/chassis/MEDBP#0/MEDBP (container)
/frutree/chassis/XSCFU_B#0 (fru)
/frutree/chassis/XSCFU_B#0/XSCFU_B (container)
/frutree/chassis/OPNL (container)

The following example displays FRUID data for the CMU container;
notice the use of the fully qualified container name:
XSCF> prtfru -c /frutree/chassis/OPNL
/frutree/chassis/OPNL (container)
AREA NAME:Board_Area
Language: 25
Manufacture_Data_Time: Sat May 25 16:02:30 1996
Manufacturer: FUJITSU LIMITED
Product_name: OPNL
Serial_number: PP0640S619
Part_number: CA06620-D381 A1
AREA NAME:Internal_Area
board_id: 257
fan_high_level0: 27
fan_low_level0: 24
start_over_temp_level0: 36
stop_over_temp_level0: 32
start_under_temp_level0: 1
stop_under_temp_level0: 5
fan_high_level1: 25
fan_low_level1: 22
fan_high_level2: 23
fan_low_level2: 20
fan_high_level3: 21
AREA NAME:TroubleInfo_Area
AREA NAME:System_Area
cod_board_info: 0x00

The cfgdevice Command

The cfgdevice command connects or disconnects the DVD/DAT drive to
the specified port on an MX000 high-end server. The command can also
display the current status of the DVD/DAT drive. This command requires
platadm privileges to connect and disconnect, or fieldeng to view status
information.
If connection or disconnection is made when the power supply of the

system is ON, settings are made immediately after cfgdevice command
execution. When the power supply of the system is OFF, connection or
disconnection is reserved and settings are made after the power supply is
turned on.
Note The DVD/DAT drive is accessed through IOU card A (IOUA)

mounted on the I/O unit and can only be connected to a domain within
the cabinet in which the drive is mounted.
The syntax for the cfgdevice command is:
cfgdevice [-y] -c [attach|detach] [-p port] -l
-c attach Connects a DVD/TAPE drive to the specified

port.
-c detach Disconnects the DVD/TAPE drive from the
specified port.
-l Displays the current status of the
DVD/TAPE drive.
-M Displays text by pages. Similar to the more
command.
-p port Port to attach the DVD/TAPE drive. Can be
specified in the IOU-number-PCI slot
number format, such as -p 1-0 for IOU#1
slot 0.
-y Automatically answers yes to all prompts.

The following example connects a DVD/DAT drive to port 0-0:

XSCF> cfgdevice -c attach -p 0-0
Are you sure you want to <attach the device> [y|n]: y
Completed.
The following example disconnects a DVD/DAT drive from port 0-0:

XSCF> cfgdevice -c detach -p 0-0
Are you sure you want to <detach the device> [y|n]: y
Completed.
The following example displays the status of the DVD/DAT drive:

XSCF> cfgdevice -l
Current connection for DVD/DAT: port 0-0
Expander status
Port No. IOU/SAS-status SAS-status
-----------------------------------
0-0 enable up enable up
0-4 disable up enable up

The switchscf Command

The switchscf command switches the XSCF unit that the user is
currently logged into between the active and standby states. When the
current XSCF unit is switched from active to standby or the reverse, the
state of the other XSCF unit is also switched.

execute.
Note This functionality is only available on the high-end servers with

two service processors installed.
The syntax for the switchscf command is:

switchscf -t {Active | Standby} [-f] [-h]
-t Active Switches the state of the XSCF unit to active

-t Standby Switches the state of the XSCF unit to standby
-f Forces the command to execute

The following example switches the state of the current XSCF to

Standby:
XSCF> switchscf -t Standby
The following example switches the state of the current XSCF to Active:
XSCF> switchscf -t Active
Note If the error Switching of XSCF state is disabled due to a

maintenance operation. Try again later" is displayed, check whether the
addfru, deletefru, replacefru, or flashupdate maintenance
command is being executed and wait until the command ends. If the
XSCFs still cannot be switched, force the operation using the -f option.
The following example forces a switch of the current XSCF to standby:
XSCF> switchscf -t Standby -f

The clockboard Command

The clockboard command specifies which clock board unit to use on an
MX000 high-end server when the system is powered on. The target clock
board is specified using the numbers 0 or 1.
When the clockboard command is executed with no options, the clock

control unit that is currently used and the one to be used at the next
system startup are displayed.
Note The clockboard command requires fieldeng privileges to

execute.
The syntax for the clockboard command is:

clockboard -s board# -h
-s 0 Configures the system to use clock board 0

-s 1 Configures the system to use clock board 1
The following example displays the current clock board settings:

XSCF> clockboard
current CLKU_B number :0
next CLKU_B number :0
The following example sets the system to use clock board 1 at the next
system startup and then verifies the setting:
XSCF> clockboard -s 1
XSCF> clockboard
current CLKU_B number :0
next CLKU_B number :1

Configuring Capacity on Demand

Capacity on Demand (COD) is an option that allows you to purchase
spare processing resources (CPUs) for the server. The spare resources are
provided in the form of one or more CPUs on COD boards that are
installed on your server. However, to access these COD CPUs, you must
first purchase the COD right-to-use (RTU) licenses for them.
COD Overview
COD Boards
A COD board is a system board that has been configured at the factory for
COD capability. COD boards come in the same configurations as standard
system boards. The number of CPUs per COD board depends on the
server configuration that is purchased.
COD License Purchase
The purchase of a COD right to use (RTU) license from the Sun License
Center entitles you to receive a license key, which enables the appropriate
number of COD processors.
License Installation and Allocation
A license key issued by the Sun License Center is comprised of text lines,
which can be e-mailed and then added to the COD license database. A
single license key can grant access to multiple RTUs, as specified when
the key is generated.
The software allocates COD licenses automatically on a first-come,

first-served basis. However, you can reserve licenses if you want to make
sure a specific number of COD licenses are allocated to a particular
domain.
Headroom Management
Headroom is the capability to use as many as four COD processors per

server before actually purchasing a license. Headroom allows you to
activate a COD board under the following conditions:
As a hot spare to replace a failed system board

When you intend to purchase a license but need to use the resources
immediately
By default, COD resources arrive with headroom disabled. You can use
the setcod command to enable headroom. However, if all your COD
resources are already licensed, configuring headroom has no effect. In that
case, you must install additional COD boards to retain your headroom
capacity. You can also reduce or disable headroom at any time.
COD Commands Summary

The commands required to manage and configure COD are listed in
Table 4-11:
Table 4-11 COD Usage Commands
Command Result
addcodlicense Installs a COD license

deletecodlicense Deletes a COD license
showcodusage Displays usage statistics for COD resources
setcod Reserves licenses for allocation, increase,
decrease, or disable headroom
showcod Displays COD information
showcodlicense Displays COD license status

Installing a COD License

To add a COD license, complete the following steps:
1. Log in to the service processor with platadm privileges.
2. Execute the addcodlicense command:
XSCF> addcodlicense license-key
3. Verify that the license key was added:
XSCF> showcodlicense -r
Note If headroom is enabled, headroom decreases to compensate for

each new license. This automatic reduction in headroom is designed to
avoid accidental abuse of headroom. You can increase headroom again
manually after installing the COD license.
Deleting a COD License

Before deleting a license, the COD software determines whether sufficient
licenses are available from the pool of installed licenses plus headroom. If
all licenses are in use and no headroom is available, the operation fails.
You can force the operation by using the -f option, but doing so
overcommits any license reservations that are in effect.
To remove a COD license, complete the following steps:

2. Execute the deletecodlicense command:
XSCF> deletecodlicense license-key
3. Verify that the license key has been removed:
Note If you need to trade a COD license for example, the license is
corrupted or move licenses from one server to another, use the
deletecodlicense to remove the old license and use the addcodlicense
to install the new license.

Reserving Licenses for Allocation

To reserve licenses for a particular domain, complete the following steps:
2. Execute the setcod command, specifying the domain and how
many licenses to reserve:
XSCF> setcod -d domain license-quantity
For example:
XSCF> setcod -d 1 4
3. Verify that the license keys have been reserved:
XSCF> showcod
Managing Headroom
Three procedures can be performed when managing headroom. These are:
Increasing headroom
Decreasing headroom
Disabling headroom
Increasing or Decreasing Headroom
To increase or decrease headroom, complete the following steps:

2. Execute the setcod command, specifying the headroom desired:
XSCF> setcod headroom
For example:
XSCF> setcod 4
3. Verify that the headroom quantity has been set:
XSCF> showcod
Chassis HostID: 80a88809
PROC RTUs installed: 8
PROC Headroom Quantity: 4

Disabling Headroom
To disable headroom, complete the following steps:

2. Execute the setcod command setting the headroom value to 0:
XSCF> setcod 0
3. Verify that the headroom value has been set to 0:
XSCF> showcod
Displaying COD Reservation Information

To display COD reservation information, complete the following steps:
1. Log in to the service processor with platadm, platop, domainadm, or
domainop privileges.
2. Execute the showcod command with no options to view COD
information for the whole server:
XSCF> showcod
PROC RTUs reserved for domain 0: 4
...
3. To view COD information for a specific domain, execute the showcod
command with the -d domain option:
XSCF> showcod -d 0

Displaying COD License Status

To check the status of the COD licenses, use the showcodlicense
command. This command can display license information in raw or
formatted output.
To display COD usage information, complete the following steps:

2. To display the formatted COD license output, use the
showcodlicense command:
XSCF> showcodlicense
Description Ver Expiration Count Status

----------- --- ---------- ----- ------
PROC 01 NONE 8 GOOD
3. To display the raw COD license output, use the showcodlicense -r
command:
01:84000000:104:0301010100:3:00000000:xxxxxxxxxxxxxxx
Displaying COD Usage Statistics

To display COD usage statistics, complete the following steps:
1. Log in to the service processor with platadm, platop, domainadm, or
domainop privileges.
2. Execute the showcodusage command:
XSCF> showcodusage
Resource In Use Installed Licensed Status

-------- ------ --------- -------- ------
PROC 0 4 0 OK: 0
available
Domain/Resource In Use Installed Reserved
--------------- ------ --------- --------
0 - PROC 0 4 0
1 - PROC 0 0 0
2 - PROC 0 0 0
3 - PROC 0 0 0
Unused - PROC 0 0 0

Using the XSCF Web
Using the XSCF Web

The XSCF Web uses https and the SSL/TLS (secure sockets
layer/transport layer security) protocols for connection to the server over
the network and for web-based support of server status display, server
operation control, and configuration information display.
When a configured user establishes a connection with a web browser to

the XSCF Web from a client terminal and logs in with an XSCF user
account, a tree index of available pages is displayed.
Each of the functions listed in the following table provides the same
results as those of the corresponding XSCF shell commands.
Table 4-12 outlines each of the pages.
Table 4-12 XSCF Web Pages
Basic Page Description
Login page XSCF Wed console login page. Log in with an XSCF
user account.
Menu frame This page is displayed by default after login. There
are three navigators available from the menu frame.
They are:
Menu The menu of various settings, operations,
and state displays that are displayed in the tree.
Physical The physical components of the server
are displayed in this tree.
Logical The logical components of each domain
are displayed in the tree.
Main page A generic name of the detailed page located at the
right of the screen. When you select an item from the
menu in the tree frame, the target page is displayed
here.
Event frame A page that displays the entire system events. The
content of the display is refreshed every 60 seconds.
You can change the interval on the same frame.
Status display This page displays the status of the entire system and
the domain status. The page display includes the
External I/O expansion unit status.

Using the XSCF Web
Table 4-12 XSCF Web Pages (Continued)
Basic Page Description

System/domain This page is for operations for the entire system as
operation well as individual domains. Functionality includes
power operations, domain configuration
management and DR operations.
XSCF settings This page is for making XSCF operation settings.
Utility pages This page is for things such as firmware updates,
remote maintenance service, XSCF reset, and XSCF
switch (high-end systems only).
Log display This page displays the logs which include error logs,
power logs, event logs, and console logs.
Standby side This page is displayed when you log in to the standby
page (high-end XSCF. It includes XSCF switch and log collection.
systems only)

Exercise: Administering and Configuring the MX000 Server
Exercise: Administering and Configuring the MX000

Server
In this exercise, you will complete the following tasks:
Managing User Accounts and Privileges
Monitoring Environmental Factors
Viewing Hardware Status
Managing Capacity on Demand (Optional)
Note This exercise has been written with the assumption that you have
remote access to an MX000 server.

Preparation
Your instructor will assign a server to each group. To complete this
exercise, you will need your servers hostname and the network
configuration. Use the Solaris cat command to read the /etc/hosts file
to determine your network settings.
Resource
NTS
IP Address
NTS Port #
User Login user1
User Password cangetin
XSCF0-lan0
IP Address
XSCF0-lan0
netmask
XSCF0-lan1
IP Address
XSCF0-lan1
netmask
Service Processor
host name

Task 1 Verifying Basic Network Settings

In this task, you review and configure the basic network functions of the
MX000 server.
1. Open a terminal window from your local workstation.
2. Telnet to the NTS, chose the port for your assigned server, and log in
as user1.
3. Display the network configuration information for the primary
external interface of your service processor. Record the command
used:
Command: _______________________________________________
4. Identify the values for the following:
IP address: _______________________
Netmask: _________________________
MAC Address: ____________________
Number of transmitted packets: ________________
Number of dropped packets: __________________
Number of collisions: ________________________
5. Verify the status of the telnet protocol on your assigned service
processor and record the command used:
Command: _______________________________________________
Status: __________________________
6. Open a second terminal window and telnet to the service
processor, logging in again as the user user1.
7. From the telnet session, display the network configuration
information for the secondary external interface of your service
processor. Record the command used:
Command: _______________________________________________
8. From the telnet window, disable the telnet service. Record the
command used. Is your connection still responsive? What about
from the serial connection?
Command: _______________________________________________
Status: __________________________________________________

9. From the serial connection, view the status of the telnet protocol.
Record the command used:
Command: _______________________________________________
Status: __________________________
10. From the serial connection, re-enable the telnet service, record the
command used, and verify that telnet is again working.
Command: _______________________________________________
Status: __________________________________________________

Task 2 Managing User Accounts

In this task, you configure and manage user accounts and their associated
privileges. Complete the following steps:
1. Log in to your assigned service processor as the userid user1.
2. View the current global password policy, and record the command
used:
Command: __________________________________________
3. Identify the values of the following fields displayed:
Mindays: __________________
Maxdays:__________________
Warn: _____________________
4. Modify the global password policy to reflect the following, and
record the command used:
Minimum password length = 8
Minimum number of new characters in a new password = 4
Maximum number of retries = 2
Command: __________________________________________
5. Create a new user account that will give that user privileges to
power on or off domains 0 and 1. Choose any username you prefer,
within reason. Record the command used:
Command: __________________________________________
6. Create a password for the new account just created.
Which command(s) did you use to accomplish this task?
Command: __________________________________________
Which password did you use? (It is important that you record the
password here in case you forget it later.)
Command: __________________________________________
7. Log out of the XSCFU.
Command: __________________________________________
8. Log in to the XSCFU with the newly created user.

9. Display the user account information for the user account just
created. Record the command used:
Command: __________________________________________
10. Display the privileges assigned to this user account. Record the
command used:
Command: __________________________________________
11. Configure all user accounts to automatically log out of the XSCF
after two minutes. Record the command used:
Command: __________________________________________
12. Verify the logout setting from step 11. Did the value change? Record
the command used:
Command: __________________________________________
13. Log out and log back in using the same account.
14. Re-verify the previous logout setting Did the value change? Record
the command used:
Command: __________________________________________
15. Allow enough time to pass so that the users session is automatically
logged out.
16. Log in to the XSCFU using the user1 account.
17. Disable the new account you created earlier in this lab. Record the
command used:
Command: __________________________________________
18. Log out of the XSCF.
19. Attempt to log back in to the XSCFU using the account you just
disabled. Was your attempt successful? __________________
20. Log in to the XSCF using the user1 account and re-enable the
disabled account. Record the command used:
Command: _________________________________________
21. Log out of the XSCF and re-login as your new user.
22. Attempt to change the password for this user by only changing two
characters of the original password. Record the command used and
whether you were successful or not and why:
Command: _________________________________________
__________________________________________________

23. As your final step for this task, execute the steps needed to delete
this user from the system. Record your steps:
Command: _________________________________________
__________________________________________________

Task 3 Monitoring Environmental Factors

In this lab, you monitor the servers environment.
1. Log in to your assigned service processor using an account that has
platadm privileges, such as the user1 account.
2. Check the current setting for the servers altitude. Record the
command used:
Command: _______________________________________________
Status: _________________________
3. Set the servers altitude to 50 meters. Record the command used.
Command: _______________________________________________
4. What was the altitude set to? Why?
Status: __________________________________________________
5. Display the intake temperature and humidity (high-end servers
only) of the server. Record the command used:
Command: _______________________________________________
6. Identify the current value for the following:
Temperature: _____________________________
7. Display the temperature for each of the CPUM boards in the server.
Command: _______________________________________________
8. Display the status of the fans within the server. Record the command
used:
Command: _______________________________________________
9. Display the status of the locator LED on the operator panel of your
assigned server. Record the command used:
Command: _______________________________________________
Status: _________________________
10. Set the locator LED to blink, display the status of the LED and, if
using a local server, visually confirm the LED is blinking. Record the
commands used:
Command: _______________________________________________
Command: _______________________________________________

11. Display the current settings for the servers power-up wait time and
warmup time. Record the command used:
Command: _______________________________________________
12. Identify the current values for the following:
Warmup time: _____________________________
Wait time: ________________________________
13. Change the warmup and wait times to the following values:
Warmup time: 4 minutes
Wait time: 2 minutes
Command: _______________________________________________
14. When would these new values take effect? _______________________
15. Reset the warmup and wait times to their previous settings:
Command: _______________________________________________
16. Display the current settings for the servers shutdown delay time.
Command: _______________________________________________
Status: _________________________
17. Change the shutdown delay to 30 seconds:
Command: _______________________________________________
18. When would this new value take effect? _______________________
19. Reset the shutdown delay to the previous setting:
Command: _______________________________________________

Task 4 Viewing Hardware Status

In this task, you view the hardware configuration and status of your
assigned server.
1. If not already done, log in to your assigned service processor using
the user1 account.
2. Which command would you use to display the following
information?
Command: _______________________________________________
3. Using the same command that was used in step 2, which specific
PSB set resources are installed in your server?
Installed and Status of Normal?

Resource
(y or n)
PSB#00
CPUM#0-CHIP#0
CPUM#0-CHIP#1
CPUM#1-CHIP#0
CPUM#1-CHIP#1
MEMB#0
MEMB#1
MEMB#2
MEMB#3
IOU#0
PSB#01
CPUM#2-CHIP#0
CPUM#2-CHIP#1
CPUM#3-CHIP#0
CPUM#3-CHIP#1


Resource
(y or n)
MEMB#4
MEMB#5
MEMB#6
MEMB#7
IOU#1
4. Using a version of the command in Step 2 of this task, fill in the

blanks:
SPARC Enterprise M_000; Memory_Size:___ GB;
+-----------------------------------+------------+
| FRU | Quantity |
+-----------------------------------+------------+
| MBU_B | __ |
| CPUM | __ |
| Freq:__- GHz; | ( __) |
| MEMB | __ |
| MEM | __ |
| Type:__; Size:_ GB; | ( __) |
| DDC_A | __ |
| DDC_B | __ |
| IOU | __ |
| DDC_A | __ |
| DDCR | __ |
| DDC_B | __ |
| XSCFU | __ |
| OPNL | __ |
| PSU | __ |
| FANBP_C | __ |
| FAN_A | __ |
+-----------------------------------+------------+
5. Which command would you execute to display degraded unit

status?
Command: _______________________________________________
6. Execute this command and record any findings:
Status: _______________________________________________
Status: _______________________________________________

Status: _______________________________________________
7. Which command would be used to display FRUID data for the
server as well as list all available containers?
Command: _______________________________________________
8. Using this command, display the FRU tree for the operator panel of
your assigned server. Record the command used:
Command: _______________________________________________
Manufacturer: _____________________________
Serial Number: ____________________________
Part Number: _____________________________
10. Perform an initial diagnosis test of a physical system board (PSB)
that has been assigned for your use. Initially use the default
diagnostic level, but if time permits, execute a maximum diagnostic
level as well. Record the command used:
Command: _______________________________________________
Status: _________________________________
Task 5 Managing Capacity on Demand (Optional)

In this lab, you configure and manage Capacity on Demand.
the user1 account.
2. Check the current status of COD licenses on your assigned server.
Command: _______________________________________________
Status: _________________________________
3. Display the current COD usage statistics for your assigned server.
Command: _______________________________________________
Status: _________________________________
Number of installed processors: ____________________________

Number of licensed processors: ____________________________

Number of licenses in use: ________________________________
5. Display the COD reservation information for the entire server.
Command: _______________________________________________
Chassis hostid: ____________________________________
RTUs installed: ___________________________________
Headroom quantity: ________________________________
RTUs reserved for domain 0: ________________________
RTUs reserved for domain 1: ________________________

Exercise Summary
Exercise Summary

!
?
Experiences
Interpretations
Conclusions
Applications

Exercise Solutions
Exercise Solutions
This section provides solutions to the exercises.
Task 1 Verifying Basic Network Settings

In this task, you review and configure the basic network functions of the
MX000 server.
1. Open a terminal window from your local workstation.
2. Telnet to the NTS, chose the port for your assigned server, and log in
as user1.
3. Display the network configuration information for the primary
external interface of your service processor. Record the command
used:
Command: shownetwork xscf#0-lan#0
IP address: varies
Netmask: varies
MAC Address: varies
Number of transmitted packets: varies
Number of dropped Packets: varies
Number of collisions: varies
5. Verify the status of the telnet protocol on your assigned service
processor and record the command used:
Command: showtelnet
Status: should be enabled based on previous lab.
6. Open a second terminal window and telnet to the service
processor, logging in again as the user user1.
7. From the telnet session, display the network configuration
information for the secondary external interface of your service
processor. Record the command used:
Command: shownetwork xscf#0-lan#0
8. From the telnet window, disable the telnet service. Record the
command used. Is your connection still responsive? What about
from the serial connection?

Exercise Solutions
Command: settelnet -c disable

Status: The telnet session should no longer be responsive.
9. From the serial connection, view the status of the telnet protocol.
Command: showtelnet
Status: disabled
10. From the serial connection, re-enable the telnet service, record the
command used, and verify that telnet is again working.
Command: settelnet -c enable
Status: showtelnet

Exercise Solutions
Task 2 Managing User Accounts

2. View the current global password policy, and record the command
used:
Command: showpasswordpolicy
Mindays: varies
Maxdays: varies
Warn: varies
4. Modify the global password policy to reflect the following, and
record the command used:
Minimum password length = 8
Minimum number of new characters in a new password = 4
Maximum number of retries = 2
Command: setpasswordpolicy -m 8 -k 4 -y 2
5. Create a new user account that will give that user privileges to
power on or off domains 0 and 1. Choose any username you prefer,
within reason. Record the command used:
Command: adduser joe
Command:setprivileges joe domainadm@0-1
6. Create a password for the new account just created.
Command: password joe
Which password did you use? (It is important that you record the
password here in case you forget it later.)
Password used: varies

Exercise Solutions
7. Log out of the XSCFU.

Command: exit
8. Log in to the XSCFU with the newly created user.
9. Display the user account information for the user account just
created. Record the command used:
Command: showuser joe
10. Display the privileges assigned to this user account. Record the
command used:
Command: showuser -p
11. Configure all user accounts to automatically log out of the XSCF
after two minutes. Record the command used:
Command: setautologout -s 2
12. Verify the logout setting from step 11. Record the command used:
Command: showautologout
13. Log out and log back in using the same account.
14. Re-verify the logout setting. Did the value change? Record the
command used:
Command: showautologout
15. Allow enough time to pass so that the users session is automatically
logged out.
16. Log in to the XSCFU using the user1 account.
17. Disable the new account you created earlier in this lab. Record the
command used:
Command: disableuser joe
18. Log out of the XSCF.
19. Attempt to log back in to the XSCFU using the account you just
disabled. Was your attempt successful? No
20. Log in to the XSCF using the user1 account and re-enable the
disabled account. Record the command used:
Command: enableuser joe
21. Log out of the XSCF and re-log in as your new user.

Exercise Solutions
22. Attempt to change the password for this user by only changing two
characters of the original password. Record the command used and
whether you were successful or not and why:
Command: password -- should not be successful due to the setting earlier in
setpasswordpolicy requiring a minimum of four characters to be changed.
23. As your final step for this task, execute the steps needed to delete
this user from the system. Record your steps:
Command: deleteuser joe -- if successful you are deleting your current account and
may just exit you out. To be safe, run these commands:
1. exit
2. Log in as another user with proper privileges, such as
user1.
3. deleteuser joe

Exercise Solutions
Task 3 Monitoring Environmental Factors

In this lab, you monitor the servers environment.
1. Log in to your assigned service processor using an account that has
platadm privileges, such as the user1 account.
2. Check the current setting for the servers altitude. Record the
command used:
Command: showaltitude
Status: varies; likely 100m
3. Set the servers altitude to 50 meters. Record the command used.
Command: setaltitude -s altitude=50
4. What was the altitude set to? Why?
Status: Altitude set to 100m as anything less then 100m defaults to 100m.
5. Display the intake temperature and humidity of the server (high-end
servers only). Record the command used:
Command: showenvironment
6. Identify the current value for the following:
Temperature: varies
7. Display the temperature for each of the CPUM boards in the server.
Command: showenvironment temp
8. Display the status of the fans within the server.
Command: showenvironment Fan
9. Display the status of the locator LED on the operator panel of your
assigned server. Record the command used:
Command: showlocator
Status: varies
10. Set the locator LED to blink, display the status of the LED and, if
using a local server, visually confirm the LED is blinking. Record the
commands used:
Command: setlocator blink
Command: showlocator
11. Display the current settings for the servers power-up wait time and
warm-up time. Record the command used:

Exercise Solutions
Command: showpowerupdelay
12. Identify the current values for the following:
Warm-up time: varies
Wait time: varies
13. Change the warm-up and wait times to the following values:
Warm-up time: 4 minutes
Wait time: 2 minutes
Command: setpowerupdelay -c warmup -s 4
Command: setpowerupdelay -c wait -s 2
14. When would these new values take effect? After a server reboot
15. Reset the warm-up and wait times to their previous settings:
Command: setpowerupdelay -c warmup -s 0
Command: setpowerupdelay -c wait -s 0
16. Display the current settings for the servers shutdown delay time.
Command: showshutdowndelay
Status: varies
17. Change the shutdown delay to 30 seconds:
Command: setshutdowndelay -s 30
18. When would this new value take effect? A power failure
19. Reset the shutdown delay to the previous setting:
Command: setshutdowndelay -s X

Exercise Solutions
Task 4 Viewing Hardware Status

In this task, you view the hardware configuration and status of your
assigned server.
the user1 account.
2. Which command would you use to display the following
information?
Command: showhardconf
3. Using the same command that was used in step 2, which specific
PSB set resources are installed in your server?

Resource
(y or n)
PSB#00
CPUM#0-CHIP#0
CPUM#0-CHIP#1
CPUM#1-CHIP#0
CPUM#1-CHIP#1
MEMB#0
MEMB#1
MEMB#2
MEMB#3
IOU#0
PSB#01
CPUM#2-CHIP#0
CPUM#2-CHIP#1
CPUM#3-CHIP#0
CPUM#3-CHIP#1

Exercise Solutions

Resource
(y or n)
MEMB#4
MEMB#5
MEMB#6
MEMB#7
IOU#1
4. Using a version of the command in Step 2 of this task, fill in the

blanks: answers will vary
SPARC Enterprise M_000; Memory_Size:___ GB;
+-----------------------------------+------------+
| FRU | Quantity |
+-----------------------------------+------------+
| MBU_B | __ |
| CPUM | __ |
| Freq:__- GHz; | ( __) |
| MEMB | __ |
| MEM | __ |
| Type:__; Size:_ GB; | ( __) |
| DDC_A | __ |
| DDC_B | __ |
| IOU | __ |
| DDC_A | __ |
| DDCR | __ |
| DDC_B | __ |
| XSCFU | __ |
| OPNL | __ |
| PSU | __ |
| FANBP_C | __ |
| FAN_A | __ |
+-----------------------------------+------------+
5. Which command would you execute to display degraded unit
status?
Command: showstatus
6. Execute this command and record any findings:
Status: varies - hopefully nothing serious!
7. Which command would be used to display FRUID data for the
server as well as list all available containers?

Exercise Solutions
Command: prtfru -l
8. Using this command, display the FRU tree for the operator panel of
your assigned server. Record the command used:
Command: prtfru -c /frutree/chassis/OPNL
Manufacturer: Sun or Fujitsu
Serial Number: varies
Part Number: CA06620-D381, but may vary
10. Perform an initial diagnosis test of a physical system board (PSB)
that has been assigned for your use. Initially use the default
diagnostic level, but if time permits, execute a maximum diagnostic
level as well. Record the command used:
Command: testsb X
Command: testsb -m diag=max X
Status: varies

Exercise Solutions
Task 5 Managing Capacity on Demand (Optional)

In this lab, you configure and manage Capacity on Demand.
the user1 account.
2. Check the current status of COD licenses on your assigned server.
Command: showcodlicense
Status: varies
3. Display the current COD usage statistics for your assigned server.
Command: showcodusage
Status: varies
Number of installed processors: varies
Number of licensed processors: varies
Number of licenses in use: varies
5. Display the COD reservation information for the entire server.
Command: showcod
Chassis hostid: varies
RTUs installed: varies
Headroom quantity: varies
RTUs reserved for domain 0: varies
RTUs reserved for domain 1: varies

Exercise Solutions

Objectives
Module 5
Domain Administration and Configuration
Objectives
Document the characteristics of a domain
Chose between Uni-mode or Quad-mode for a Physical System
Board (PSB) set
Modify the Domain Component List (DCL)
Allocate Extended System Boards (XSBs) to a domain
Power on a domain
Document the structure of the OpenBoot PROM (OBP) device tree
for the MX000 servers
Access domain information using standard Solaris OS utilities
Domain Administration and Configuration 5-1

Objectives
Relevance
Discussion The following questions are relevant to understanding what

domains are all about:
!
? What is the definition of a domain?
What is a Physical System Board (PSB) set?
What is an Extended System Board (XSB)?
What is the expected service level for the domain and what resources
are needed to meet the expected service level?
When would you want to have multiple domains in a server?
What advantage does configuring a server into multiple domains
have?
What disadvantages does configuring a server into multiple domains
have?
What is the OpenBoot Prom (OBP)?


5872-xx.
number 819-3601-xx.


http://docs.sun.com

Exploring Domains
Exploring Domains
The MX000 mid-range and high-end servers have the ability to run
several instances of the Solaris OS. These separate and independent
instances are called domains.
Note The M3000 is capable of only one domain.
The domain definition requires:

CPU
Memory
I/O
Access to an image (Solaris OS)
Each domain runs its own Solaris Operating System and
handles its own workload.
The MX000 mid-range and high-end server domains have the following
characteristics:
Domains are based on allocated extended system boards (XSBs)
Domains do not depend on each other and are isolated
A panic in one domain does not affect the other domains running in
the server
Before configuring the server, the administrator must determine the

number of domains, the expected service level, and how best to configure
each domain.
Domain Implementation
There are two implementations of domain configuration:
Static (inactive)
Dynamic (active)

Domain Configuration
To configure a domain, you must assign system resources, or Extended
System Boards (XSBs), to each domain that you intend to use.
The service processor supports commands that allow you to group XSBs
into domains.
When the configuration has been set and the domain is initialized, the
initialization process isolates a domains resources. This is referred to as a
Dynamic System Domain (DSD).
You can create and delete domains without interrupting the
operation of other domains.
You can use domains for many purposes, such as:
Testing a new Solaris OS update
Setting up a development environment
Setting up a testing environment
You can also configure several domains to support different
departments, with one domain per department
You can also temporarily reconfigure the system into one domain to
run a large job

Domain Configuration on the Entry-level Server

The M3000 server supports only one domain.
The domain is referenced as Domain ID (DID) 0
Domain Configuration on the Mid-Range Servers

The M4000 server supports one or two domains.
The domains are referenced as Domain IDs (DIDs) 0 and 1
The M5000 server supports as many as four domains.

The domains are referenced as Domain IDs (DIDs) 0, 1, 2, and 3
Domain Configuration on the High-End Servers

The M8000 server supports as many as 16 domains.
The domains are referenced as Domain IDs (DIDs) 0 through 15
The M9000 servers support as many as 24 domains.

The domains are referenced as Domain IDs (DIDs) 0 through 23

Domain Configuration Unit (DCU)

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 a domain can be constructed.
The DCUs in the MX000 servers consist of XSBs. Before configuring the
XSBs, you should be familiar with the following terms:
Physical System Board (PSB) set Consists of CPU, memory, and I/O
Specific boards are associated with specific with each PSB set
eXtended System Board (XSB)
Is the result of using your PSB in uni-mode (XX-0) with all of
the associated CPUs, memory boards, and IO being assigned to
the XSB
Is the result of using your PSB in quad-mode (XX-0, XX-1, XX-2,
XX-3) with the associated CPUs, memory boards, and IO being
divided among as many as four extents
The numbering scheme is based on the PSB number coming
first, followed by a dash and then the extent number
Logical System Board (LSB) number To create domains, you must
first assign an LSB number to an XSB
There are 16 LSB numbers for every domain
The LSB numbers range from 0 to 15

The High-End Servers

The M8000 server contains four PSB sets. The M9000 server contains eight
PSB sets. The M9000 server with Expansion Cabinet contains 16 PSB sets.
Each PSB set consists of:
One IOU containing:
Eight PCI-E slots
Four Disk Drive slots
One CPU Memory Unit (CMU) containing:
Two or Four CPUs
16 or 32 DIMMs
Configuring PSB#00 in uni-mode results in XSB#00-0 with the following

resources:
CMU#0
CPU#0
CPU#1
CPU#2
CPU#3
32 DIMM banks
IOU#0
PCI-E slots 0, 1, 2, 3, 4, 5, 6, 7
HDD drive slots 0, 1, 2, 3

Configuring a PSB#00 in quad-mode results in the following XSBs:

CMU#0/CPU#0
CMU#0/CPU#1
CMU#0/CPU#2
CMU#0/CPU#3
High-End Server PSB numbers range from PSB#00 to PSB#15.

The M8000 has PSB#00 to PSB#03.
Note A uni-mode PSB#15 offers the same amount of resources as a uni-

mode PSB#00. Using PSB#15 in quad-mode results in the same resource
breakout as PSB#00 in quad-mode; only the PSB#s are different.

You can create a domain out of any group of XSBs if the following
conditions are met:
The domain must contain at least one XSB with CPU, Memory, and
I/O.
The domain should have at least one network interface.
The domain must have sufficient memory to support the OS and
applications.
At least one boot disk should be connected to the domains I/O. If a
domain does not have its own disk, at least one network interface
must exist so that you can boot the domain from the network.
Note The domain should contain enough physical resources to meet the
requirements of the planned workload. Prior to constructing the domain,
a resource needs assessment should be performed to ensure that the assigned
resources meet these requirements.

Configuring Static Domains

A domain can be configured by the platform administrator or by the
assigned domain administrator. If a system resource is already in use
(active) by another domain, the service processor software does not let
you manage that resource until it is released by that domain.
There are nine XSCF commands available for managing boards in a

domain and setting domain boot parameters:
The setupfru command
The showboards command
The setdcl command
The addboard command
The deleteboard command
The moveboard command
The setdomainmode command
The setdomparam command
Note The addboard, deleteboard, and moveboard commands work on

both static and dynamic domains. You must know the state of the domain
and DCU before executing these commands. If these commands are run
on a dynamic domain, they may invoke a DR operation. Use the
showboards command to get the DCU status before proceeding.

The showboards Command

Use the showboards command to display:
Extended System Board (XSB) numbers
Domain Id (DID)
Logical System Board (LSB) numbers
Assignment states
Power status
If a resource is connected and/or configured
If a resource has been tested
Status information
Valid syntaxes of the showboards command are:
showboards [-v] -d domain_id [-c sp]
showboards [-v] -a [-c sp] [xsb]

-v Displays detailed information on XSB.
-d Specifies the ID of the domain whose status of XSB is displayed.
-c Displays the system boards located in the system board pool.
-a Displays the state of XSBs configured in or assigned to a
domain and the state of all mounted XSBs.
The following output is from the showboards command. The field

labeled as Fault is used to display status.
XSCF> showboards -a
XSB DID(LSB) Assignment Pwr Conn Conf Test Fault
---- -------- ----------- ---- ---- ---- ------- --------
00-0 SP Unavailable n n n Unknown Normal

The setupfru Command

Use the setupfru command to set up hardware settings for a specified
PSB. To reconfigure a PSB, it must be disconnected from the domain
configuration and placed under the system board pool. You must have
platform administrator or field engineer privileges to execute this
command.
The syntax of the setupfru command is:
setupfru [-m {y | n}] [-x {1 | 4}] device location

-m [y | n] Specifies whether to use the memory mounted on the
XSB in mirror mode
-x [1 | 4] Specifies whether to configure the PSB as a Uni-XSB
or Quad-XSB
device Can only be specified as sb (for system board)
location Specifies an integer from 0-15
In the following example from the M5000, sb 0 is configured into a quad-

XSB. A configuration error occurred because each processor did not have
an associated memory board.
XSCF> setupfru -x 4 sb 0
Operation has completed. However, a configuration error was detected.

The showfru Command
The showfru command displays the hardware settings for a specified

device. The output of showboards changes as a result of the setupfru
command.
XSCF> showfru -a sb
Device Location XSB Mode Memory Mirror Mode
sb 00 Quad no
sb 01 Uni no
XSCF> showboards -a
---- -------- ----------- ---- ---- ---- ------- --------

The setdcl Command

Use the setdcl command to set a domain component list (DCL). For
every possible domain on the MX000 server, there is a DCL. Logical
System Board (LSB) numbers are found in the DCL.
An extended system board (XSB) is a Domain Configuration Unit (DCU).

An XSB is represented by xx-y, a combination of a PSB number (xx) and
the number of one partition of the partitioned PSB (y). The value of xx is
an integer ranging from 00 to 15 and y is an integer ranging from 0 to 3.
The setdcl command associates an LSB with an XSB that can be

recognized by an OS in a domain. Its settings enable the OS in the domain
to use hardware resources on the associated XSB. You must have platform
administrator privileges to run this command.
Note The same XSB can be assigned to an LSB in multiple domains.

That allows any of the domains to add the board to them. However, the
XSB can only be added to a single domain at a time with the addboard
command.
The syntax of the setdcl command is:
setdcl -d domain_id [-a lsb=xsb][-p policy=value]

[-s variable=value lsb] [-r lsb]

-d domain_id Specifies the domain ID to be set. An integer
ranging from 0 to 23 can be specified, depending on the system
configuration.
-a lsb=xsb Specifies an XSB number to be associated with an LSB
number in the domain. The lsb is an integer ranging from 0 to 15.
The xsb is in the form of xx-y where xx can be in the range of 00-15
and y can be in the range of 0-3. The lsb=xsb can be repeated
multiple times by using a space character as a delimiter.
-p policy=value Specifies a degradation range applicable for a
detected error during initial hardware diagnosis. This setting can be
made only once. One of the following can be specified for value:

fru If an error occurs during diagnosis, degradation by

component occurs.
xsb If an error occurs, degradation by XSB occurs.
system If an error occurs, degradation by domain occurs.
-s variable=value Makes settings regarding hardware resources
of the XSB associated with an LSB. One of the following can be
specified for variable:
no-mem Whether to omit the use of memory. If no-mem is
specified for variable, either of the following can be specified
for value:
true Omits the use of memory by the domain.
false Does not omit the use of memory by the domain
(default).
no-io Whether to omit the use of I/O devices. If no-io is
specified for variable, either of the following can be specified
for value:
true Omits the use of I/O devices in a domain.
false Does not omit the use of I/O devices in a domain
(default).
float Whether to set a priority for the board as a floating
board, relative to other boards. If float is specified for
variable, either of the following can be specified for value:
true Gives a higher priority regarding floating boards.
false Does not give a higher priority regarding floating
boards (default).
- r lsb Clears the XSB number associated with an LSB number in
the specified domain.
In the following example, XSB 00-0 is assigned to LSB 0 for domain 0.

XSCF> setdcl -d 0 -a 0=00-0
To remove the LSB number assigned to the XSB for domain 0:

XSCF> setdcl -d 0 -r 0
Note The M3000 does not support quad-mode.

The showdcl Command
The showdcl command displays the current DCL. You can get
information about all of the domains by using the -a option and for a
specific domain by using the -d with the domain_id option.
In the following example, the XSB 00-0 is assigned to LSB 0 and it is part
of domain 0, which is currently powered off.
XSCF> showdcl -a
DID LSB XSB System
00 Powered Off
00 00-0
This next example of the showdcl command on an M9000 server shows

the same XSB, XSB 08-0, as part of the domain component list of both
domains 0 and 1. The other interesting piece of this output is that DID 0 is
running and DID 1 is at the OpenBoot PROM. The next section on the
addboard and showboards commands proves that the DCL does not
show what is currently configured into our domains.
XSCF> showdcl -a
DID LSB XSB System
00 Running
00 00-0
01 01-0
02 02-0
04 08-0
05 09-0
06 10-0
---------------------------
01 OpenBoot Execution Completed
00 08-0
---------------------------
02 Powered Off
00 08-1
---------------------------
03 Powered Off
00 08-2
---------------------------
04 Powered Off
00 08-3

The addboard Command

The addboard command, based on an LSB number having been
associated with an XSB, assigns, attaches, and configures the XSB to the
specified domain. The -c option specifies the transition of the board from
the current configuration state to the new configuration state. XSBs are
also known as Domain Configurable Units (DCUs).
Configuration states are assign, configure, and reserve. If the -c

option is not specified, the default expected configuration state is
configure.
You must have platform administrator or domain administrator privileges

to execute this command.
The syntax of the addboard command is:
addboard [-q] [-y | -n] [-f] [-v] -c function -d domain_id

xsb

-q Suppresses all messages to stdout, including prompts. Must be
used with either the -y or -n option.
-y Automatically answers yes to all prompts. Prompts are
displayed unless used with the -q option.
-n Automatically answers no to all prompts. Prompts are
displayed unless used with the -q option.
-f Forcibly incorporates an XSB into a domain for which no
diagnosis has been performed.
-v Displays a detailed message.
-c function, where function can be:
assign Assigns an XSB into the domain configuration.
configure Configures an XSB into the domain configuration.
If the -c option is not specified, then -c configure is used by
default.
reserve Reserves incorporation of an XSB into the domain
configuration. The action of reserve is the same as assign.

-d domain_id Specifies the ID of the domain to which an XSB is to

be configured or to which it is to be assigned. The domain_id can be
023 depending on the system configuration.
xsb Specifies the XSB number to be configured or assigned.
Multiple xsb operands are permitted, separated by spaces. The xsb is
in the form of xx-y, where x is an integer from 00-15 and y is an
integer from 03.
Prior to any addboard operation, it is good practice to execute the

showboards command to verify if a resource has already been allocated to
a domain. In the following example, XSB 00-0 is configured into domain 0.
The responding message is that domain 0 is not currently running,
therefore, it is performing a static operation.
XSCF> addboard -d 0 -c assign 00-0
XSB#00-0 will be assigned to DomainID 0. Continue?[y|n] :y
In the following output of showboards, there are five XSBs. XSB 00-0 is
assigned to domain 0. The remaining four XSBs or Domain Configurable
Units (DCUs) are in the system board pool (SP).
XSCF> showboards -a
---- -------- ----------- ---- ---- ---- ------- --------
00-0 00(00) Assigned n n n Unknown Normal

The deleteboard Command

The deleteboard command removes an XSB from the domain to which it
is currently assigned. The -c option specifies the transition of the board
from the current configuration state to the new configuration state.
Configuration states are disconnect, unassign, and reserve. If the -c

disconnect.

The syntax of the deleteboard command is:
deleteboard [-q] [-y | -n] [-f] [-v] -c function xsb

disconnect Disconnects the XSB from the domain
configuration but keeps it assigned. Because the XSB remains
assigned to the domain configuration, it can be configured
again in the domain by a reboot or the execution of the
addboard command.
unassign Completely disconnects the XSB from the main
configuration and puts it in the system board pool. The XSB in
the system board pool can be incorporated into or assigned to
another domain.
reserve Does not immediately disconnect the XSB from the
domain configuration but only reserves detachment. When the
domain power is shut down, the reserved XSB is disconnected
from the domain configuration and put back in the system
board pool.
Prior to any deleteboard operation, it is good practice to execute the

showboards command to verify where or if a resource is allocated. In the
following example, XSB 00-1 is deleted from the domain that it is
currently assigned to.

XSCF> deleteboard -c unassign 00-0

XSB#00-0 will be unassigned from domain immediately. Continue?[y|n]:y
The resulting output from the showboards command is:

XSCF> showboards -a
---- -------- ----------- ---- ---- ---- ------- --------

The moveboard Command

The moveboard command moves an XSB from its current domain to
another domain. The -c option specifies the transition of the board from
the current configuration state to the new configuration state.
Configuration states are configure, assign, and reserve. If the -c

configure.

The syntax of the moveboard command is:
moveboard [-q] [-y | -n] [-f] [-v] -c function -d domain_id

xsb

assign Disconnects a configured XSB from its domain
configuration and assigns it to the specified destination domain
configuration.
configure Disconnects a configured XSB from its domain
configuration and configures it into the specified destination
domain configuration. If the -c option is not specified, then -c
configure is used by default.
reserve Reserves disconnection of the specified XSB from the
source domain, and reserves assignment of the XSB to the
destination domain. The XSB is assigned to the destination
domain when the source domain is turned off or rebooted. The
XSB is subsequently incorporated into the destination when the
domain power is turned on or upon reboot.
Prior to any moveboard operation, it is good practice to execute the

showboards command to verify where or if a resource is allocated. In the
following example, XSB 00-0 is being moved to domain 1.
XSCF> moveboard -d 1 -c assign 00-0
XSB#00-0 will be assigned to DomainID 1 immediately. Continue?[y|n] :y

The setdomainmode Command

The setdomainmode command is used to set the domain mode for the
specified domain. The domain mode includes the following settings:
OpenBoot PROM diagnostic level (Diagnostics Level).
Whether to enable or disable the host watchdog and suppress the
break signal (Secure Mode). The default of secure mode is disable.
Whether to enable or disable the auto boot function (Autoboot).
You must have the following privileges to run this command:

Diagnostic Level Field engineer
Secure Mode and Autoboot Platform or domain administrator
The syntax of the setdomainmode command is:
setdomainmode [-y] -d domain_id -m function=mode

-m function=mode Sets the domain mode and specifies its values.
The following functions and their corresponding modes can be
specified:
diag none, min, or max
secure on or off
autoboot on or off
cpumode auto or compatible
Way of determining the CPU operational mode mounted
on the domain. The CPU operational mode can be
automatically determined at domain startup (auto), or
manually set to the compatible mode (compatible). The
default is to let it automatically determined at domain
startup.

SPARC64 VII auto mode

Consists only of SPARC64 VII processors: SPARC64 VII
enhanced mode
SPARC64 VII and VI processors mixed: SPARC64 VI
compatible mode
Consists only of SPARC64 VI processors: SPARC64 VI
compatible mode
SPARC64 VI compatible mode
Regardless of the CPUs mounted, sets the operational
mode of CPU to the SPARC64 VI compatible mode.
Note On the M3000 server, you cannot specify CPU Mode.
In the following example, autoboot is set to off for domain 0.

XSCF> setdomainmode -d 0 -m autoboot=off
.
.
Continue? [y|n] :y
The showdomainmode Command
The showdomainmode command displays the current mode settings for

the domain.
In the following example, you can see the domain modes that are set for
domain 0.
XSCF> showdomainmode -d 0
Host-ID :80920ed0
Diagnostic Level :min
Secure Mode :off
Autoboot :off
CPU Mode :auto

The setdomparam Command

The setdomparam command forcibly sets OBP environment variables. You
must have platform administrator or domain administrator privileges to
run this command.
The syntax of the setdomparam command is:
setdomparam -d domain_id [use-nvramrc] [security-mode]

[set-defaults]

use-nvramrc Sets the use-nvramrc? variable to false.
security-mode Sets the security-mode? variable to none.
set-defaults Restores the OBP variables to their defaults.
In the following example, use-nvramrc? is set to false for domain 0.

XSCF> setdomparam -d 0 use-nvramrc
DomainIDs of domains that will be affected:00
OpenBoot PROM variable use-nvramc will be set to false.
Continue? [y|n] :y

Controlling Power to the Domain

After the domain has been configured, it then needs to have power
applied to the boards and POST run against them. You apply power to the
boards by executing the poweron command.
The poweron Command

The poweron command is used to power on the specified domain or all
domains. A user with platform administrator or field engineer privileges
can run this command for all domains. Users with domain administrator
or domain manager privileges can run this command for their respective
domain.
The syntax of the poweron command is:

poweron [[-q] -{y|n}] [-M] -d domain_id
poweron [[-q] -{y|n}] [-M] -a
poweron -h
The only option or parameter for this command is -a, which turns on
power to every domain that has been completely set up.
In the following example, power is applied to domain 0.

XSCF> poweron -d 0
DomainIDs to power on:00
Continue? [y|n] :y
00 :Powering on
*Note*
This command only issues the instruction to power-on.
The result of the instruction can be checked by the "showlogs power".

The poweroff Command

The poweroff command is used to power off the specified domain or all
domains. After the OS is shut down in an orderly fashion, the power is
turned off. A user with platform administrator or field engineer privileges
can run the poweroff command for all domains. Users with domain
administration or domain manager privileges can run the poweroff
command for their respective domain. The syntax of the poweroff
command is:
poweroff [[-q] -{y|n}] [-f] [-M] -d domain_id
poweroff [[-q] -{y|n}] [-M] -a
poweroff -h
The only option or parameter for this command is -a, which turns off
power to every domain that is running.
In the following example, we are connected into the serial console and
power is turned off to domain 0.
XSCF> poweroff -d 0
DomainIDs to be powered off:0
Continue? [y|n] :y
Note The power-off command at the OBP can also be used to power off
the domain.

Accessing the Domain Console

After logging into the service processor, a domain administrator must
become a domain client on the service processor. After doing so, the
domain administrator can run commands that affect the domain of which
you are a client. The command to perform this action is console.
The console Command

The console command creates a remote connection to the domains
virtual console driver, making the window in which the command is run
a console window for the specified domain (domain_id). Many console
commands can be attached simultaneously to a domain, but only one
console has write permissions; all others have read-only permissions.
A user with platform administrator, platform operator, or field engineer

privileges can run this command for all domains. Users with domain
administrator, domain manager, or domain operator privileges can run
this command for their accessible domain.
To exit the domain console and return to the XSCF shell, press the Enter
key, and then type a #..
The syntax of the console command is:
console -d domain_id [-y][-f | -r][-e escapeChar]

-f Forces a write session.
-r Initiates a read-only session.
-e escapeChar Allows you to specify an escape character sequence
if you want to change the default. The character specified must be
enclosed in double quotation marks ().
In the following example, a console is opened to domain 0.

XSCF> console -d 0
Connect to DomainID 0?[y|n] :y
POST Sequence 01 CPU Check

POST Sequence 02 Banner

LSB#00 (XSB#00-0): POST 2.8.0 (2008/11/19 11:25)
POST Sequence 03 Fatal Check
POST Sequence 04 CPU Register
POST Sequence 05 STICK
POST Sequence 06 MMU
POST Sequence 07 Memory Initialize
POST Sequence 08 Memory
POST Sequence 09 Raw UE In Cache
POST Sequence 0A Floating Point Unit
POST Sequence 0B SC
POST Sequence 0C Cacheable Instruction
POST Sequence 0D Softint
POST Sequence 0E CPU Cross Call
POST Sequence 0F CMU-CH
POST Sequence 10 PCI-CH
POST Sequence 11 Master Device
POST Sequence 12 DSCP
POST Sequence 13 SC Check Before STICK Diag
POST Sequence 14 STICK Stop
POST Sequence 15 STICK Start
POST Sequence 16 Error CPU Check
POST Sequence 17 System Configuration
POST Sequence 18 System Status Check
POST Sequence 19 System Status Check After Sync
POST Sequence 1A OpenBoot Start...
POST Sequence Complete.
Sun SPARC Enterprise M5000 Server, using Domain console

Copyright 2008 Sun Microsystems, Inc. All rights reserved.
Copyright 2008 Sun Microsystems, Inc. and Fujitsu Limited. All rights
reserved.
OpenBoot 4.24.10, 16384 MB memory installed, Serial #70949601.
Ethernet address 0:14:4f:3a:9a:e1, Host ID: 843a9ae1.
{0} ok
Note The console command with the -f option forcibly connects to a

writable console. The currently connected writable console is
disconnected. Only users who have platadm or domainadm privileges can
specify this option.

The showconsolepath Command

The showconsolepath command displays information about the domain
console that is currently connected. The following information can be
displayed:
user User account on the XSCF that is connected to the domain
console
DID Domain ID
ro/rw Domain console type; read-only or read-write
date Date connected to the domain console.
A user with user platform administrator, platform operator, or user

administrator privileges can run this command for all domains. Users
with domain administrator, domain manager, or domain operator
privileges can run this command for their respective domain.
The syntax of the showconsolepath command is:
showconsolepath [-a] [-d domain_id]
In the following example, the console path is shown for all domains that
can be accessed.
XSCF> showconsolepath -a
User DID ro/rw escape Date
installer 0 rw # Wed Feb 25 21:46:04 2009

Displaying the Domain Devices and Status

The XSCF software provides multiple ways for you to gather information
about the domains configured in your system. This section provides
information about the following two commands:
The showdevices command
The showdomainstatus command
The showdevices Command

The showdevices command displays configured physical devices on
XSBs. The information about available resources can be obtained for the
devices managed by the OS. The OS must be running for this command to
succeed.
A user with platform administrator, platform operator, or field engineer

privileges can run this command for all domains. Users with domain
administrator, domain manager, or domain operator privileges can run
this command for their respective domain.
The following types of information are displayed:

Common:
DID Domain ID
XSB XSB number
CPU:
ID Processor ID
State Status of processor
Speed CPU frequency (MHz)
ecache CPU external cache size (MB)
Memory:
Board memory Size of memory mounted on XSB (MB)
Permanent memory Size of permanent memory
Base address Physical address of memory mounted on XSB
Domain memory Size of memory on the domain (MB)

I/O devices:
Device Instance name of I/O device
Resource Managed resource name
Usage Description of the instance using resources
Query Results of an off-line inquiry about resources
The syntax of the showdevices command is:
showdevices [-v] [-p bydevice | byboard | query | force]

[xsb | -d domain_id]

-p bydevice Displays results organized by device type
-p byboard Displays results organized by XSB
-p force Predicts system resources deleted from the OS when a
board is forcibly disconnected by the deleteboard -f command
-p query Predicts system resources deleted from the OS when a
system board is disconnected by the deleteboard command
XSCF> showdevices -d 0
CPU:
----
DID XSB id state speed ecache
00 00-0 0 on-line 2280 5
00 00-0 1 on-line 2280 5
00 00-0 2 on-line 2280 5
00 00-0 3 on-line 2280 5
Memory:
-------
board perm base domain target deleted remaining
DID XSB mem MB mem MB address mem MB XSB mem MB mem MB
00 00-0 12288 1438 0x000003c000000000 12288
IO Devices:
----------
DID XSB device resource usage
00 00-0 sd0 /dev/dsk/c0t0d0s0 mounted filesystem "/"
00 00-0 sd0 /dev/dsk/c0t0d0s1 swap area
00 00-0 sd0 /dev/dsk/c0t0d0s1 dump device (swap)
00 00-0 bge0 SUNW_network/bge0 bge0 hosts IP addresses: 10.6.15.2

Note The Processor ID values are described in the upcoming section

about the OBP device tree.
The showdomainstatus Command

The showdomainstatus command displays the current domain status.
This command requires one of the privileges to execute: platadm, platop,
fieldeng, or useradm.
One of the following states is displayed for each domain:

Powered Off Power is off.
Panic State A panic occurred, and the domain is in the reset
state.
Shutdown Started The power-off process is starting.
Initialization Phase OpenBoot PROM initialization is in
progress.
OpenBoot Execution Completed The system is in the OpenBoot
PROM (ok prompt) state.
Booting/OpenBoot PROM prompt The operating system is booting.
Or due to the domain shutdown or reset, the system is in the
OpenBoot PROM running state or is suspended in the OpenBoot
PROM (ok prompt) state.
Running Operating system is running.
- The domain is not configured.
The syntax of the showdomainstatus command is:

showdomainstatus -a
showdomainstatus -d domain_id
showdomainstatus -h

-a Displays status information about all domains that can be
accessed

-d domain_id Displays the specified domain, where domain_id

can be 023 depending on the system configuration
-h Displays command usage
The following example displays information for all configured domains:

XSCF> showdomainstatus -a
DID Domain Status
00 Running
01 Powered Off
02 -
03 -
04 -
05 -
06 -
07 -
08 -
09 -
10 -
11 -
12 -
13 -
14 -
15 -

Resetting the Domain

Certain error conditions can occur in a domain that require aborting the
domain software or issuing a reset to the domain software or hardware.
The sendbreak Command

The sendbreak command sends a break signal to the specified domain.
When a break signal is sent from the service processor to the domain OS,
control is transferred from the OS to the OBP and the OBP prompt (ok) is
displayed.
A user with platform administrator privileges can run this command for
all domains. Users with domain administrator privileges can run this for
their domain only.
The syntax of the sendbreak command is:
sendbreak -d domain_id
In the following example, a break is sent to domain 0 and then a console

session is opened. You can verify that the domain is at the OBP ok
prompt.
XSCF> sendbreak -d 0
Send break signal to DomainID 0?[y|n] :y
View of the sendbreak from the domain:

godzilla-dom0 console login: Type 'go' to resume
{2} ok
The reset Command

XSCF provides the reset command, which aborts the domain software
and issues a reset to the domain hardware.
Control is passed to the OBP after the reset command is issued. If a

user-initiated reset command is issued, the OBP uses its default
configuration to determine whether the domain is booted to the Solaris
OS.

A user with platform administrator or field engineer privileges can run

this command for all domains. Users with domain administrator or
domain manager privileges can run this for their respective domains only.
The syntax of the reset command is:
reset [-y] -d domain_id level
The following three levels of resets can be specified:

por Resets the domain system.
panic Instructs the domain OS to generate a panic. The command
is ignored if issued during power-off or shutdown.
xir Resets the domain CPU.
In the following example, an externally initiated reset (XIR) is issued to

domain 0.
XSCF> reset -d 0 xir
DomainID to reset:00
Continue? [y|n] :y
00 :Reset
*Note*
This command only issues the instruction to reset.
The result of the instruction can be checked by the "showlogs power".
View of the reset from the domain:
godzilla-dom0 console login:

ERROR: Externally Initiated Reset has occurred.
{3} ok

The OBP Device Tree
The OBP Device Tree

The OBP directly handles hardware devices in the system. Each device
has a unique name representing the type of device and the location of that
device in the system addressing structure.
After the domain completes POST, the available healthy devices are
identified to the domain. The OpenBoot PROM represents the
interconnected buses and their attached devices as a tree of nodes. This
tree is called the device tree. A node representing the host computers
main physical address bus forms the trees root node.
Each device node in the tree can have:

Properties Data elements describing the node and its capabilities
and configuration
Methods The software procedures that access the device
Data The initial value of the private data used by the methods
Children Other device nodes attached to a given node and that lie
directly below it in the device tree
A parent The node that lies directly above a given node in the
device tree
Nodes with children usually represent buses and their associated

controllers, if any. Each node defines a physical address space in which
the device drivers communicate with the devices at and below that node.
Each child of that node is assigned a physical address in a section of the
parents address space.
Nodes without children are called leaf nodes and generally represent
devices. However, some nodes represent system-supplied firmware
services or other objects.

The OBP Device Tree
M8000 Uni-mode XSB 00-0 OBP Device Tre

This domain is created with XSB 00-0.
XSB 00-0 (Uni-mode).
The assigned LSB # is 0.
The output from the obp commands probe-scsi-all and show-nets

is displayed below. Two different controllers from two IOU A cards are
shown. The IOU A card in slot # 0 is shown as /pci@4,600000. The IOU A
card in slot # 4 is shown as /pci@0,600000. Each IOU A card also offers
two Gigabit Ethernet ports. All four network interfaces are show in the
show-nets output.
{0} ok probe-scsi-all
/pci@4,600000/pci@0/scsi@1
MPT Version 1.05, Firmware Version 1.11.00.00
Target 0
Unit 0 Disk FUJITSU MAY2073RC 3701 143374738 Blocks, 73 GB
SASAddress 500000e01295e0e2 PhyNum 0
Target 1
SASAddress 500000e012919cc2 PhyNum 1
/pci@0,600000/pci@0/scsi@1
MPT Version 1.05, Firmware Version 1.11.00.00
Target 0
SASAddress 500000e01292e3e2 PhyNum 0
Target 1
SASAddress 500000e0127c65b2 PhyNum 1
Target 4
Unit 0 Removable Read Only device MATSHITADVD-RAM UJ-85JS FFU0
SATA device PhyNum 0
Target 5
Unit 0 Removable Tape SEAGATE DAT DAT72-000C091
SATA device PhyNum 1
{0} ok show-nets
a) /pci@4,600000/pci@0,1/network@1,1
b) /pci@4,600000/pci@0,1/network@1
c) /pci@0,600000/pci@0,1/network@1,1
d) /pci@0,600000/pci@0,1/network@1
q) NO SELECTION
Enter Selection, q to quit: q

The OBP Device Tree
The M8000 show-devs command
The output from the obp command show-devs is displayed below.

{0} ok show-devs
/pci@7,700000 Physical Card Slot 7
/pci@8,4000
/cmp@418,0 Processor
/pseudo-mc@200,200
/pseudo-console
/virtual-memory
/memory@m3c000000000
/aliases
/options
/openprom
/packages
/pci@4,600000/pci@0,1
/pci@4,600000/pci@0
/pci@4,600000/pci@0,1/network@1,1
/pci@4,600000/pci@0,1/network@1
/pci@4,600000/pci@0/scsi@1
/pci@4,600000/pci@0/scsi@1/disk
/pci@4,600000/pci@0/scsi@1/tape
/pci@0,600000/pci@0,1
/pci@0,600000/pci@0
/pci@0,600000/pci@0,1/network@1,1
/pci@0,600000/pci@0,1/network@1
/pci@0,600000/pci@0/scsi@1
/pci@0,600000/pci@0/scsi@1/disk
/pci@0,600000/pci@0/scsi@1/tape
/pci@8,4000/ebus@1
/pci@8,4000/ebus@1/panel@14,280030
/pci@8,4000/ebus@1/scfc@14,200000
/pci@8,4000/ebus@1/serial@14,400000
/pci@8,4000/ebus@1/flashprom@10,0

The OBP Device Tree
The M8000 show-devs command continued
The obp device tree listings for the Processors are bolded below.
The Processor numbers are 400, 408, 410, and 418.
There are two cores, each core having two threads.
The cores are numbered 0 and 1.
The two threads are shown as cpu@0 and cpu@1.
These are dual-core, dual-threaded processors (SPARC 64 VI).
/cmp@418,0/core@1
/cmp@418,0/core@0
/cmp@418,0/core@1/cpu@1
/cmp@410,0/core@1
/cmp@410,0/core@0
/cmp@408,0/core@1
/cmp@408,0/core@0
/cmp@400,0/core@1
/cmp@400,0/core@0
/openprom/client-services
/packages/obp-tftp
/packages/terminal-emulator
/packages/disk-label
/packages/deblocker
/packages/SUNW,builtin-drivers
/packages/SUNW,probe-error-handler

The OBP Device Tree
The M8000 booted to Solaris
The following command takes us from the OBP to Solaris.

{0} ok boot
Boot device: /pci@0,600000/pci@0/scsi@1/disk@0,0:a File and args:
The Solaris prtdiag command
The Solaris prtdiag command shows the LSB number for the allocated
XSB. The four processors and their Agent Identifiers (AIDs) are show as
well. The speed of the processors is 2.15 GHz and L2 cache is 5 MB.
# prtdiag -v
# prtdiag -v
System Configuration: Sun Microsystems sun4u Sun SPARC Enter M8000 Server
System clock frequency: 960 MHz
Memory size: 32768 Megabytes
==================================== CPUs ===========================
CPU CPU Run L2$

LSB Chip ID MHz MB
--- ---- -------------------------------- ---- ---
00 0 0, 1, 2, 3 2280 5.0
00 1 8, 9, 10, 11 2280 5.0
00 2 16, 17, 18, 19 2280 5.0
00 3 24, 25, 26, 27 2280 5.0
============================ Memory Configuration ===================
Memory Available Memory DIMM # of Mirror Interleave

LSB Group Size Status Size DIMMs Mode Factor
--- ------ ---------- ------- ------ ----- ------- ----------
00 A 32768MB okay 2048MB 16 no 8-way
========================= IO Devices ================

The OBP Device Tree
The Solaris cfgadm command
The Solaris cfgadm command shows the Attachment Point Identifier

(Ap_Id) SB0 as connected and configured.
The System Board number (0) is in direct reference to the LSB
number (0) that was assigned to the XSB that was used to create this
domain.
Four processors are shown as SB0::cpu0, SB0::cpu1, SB0::cpu2,
SB0::cpu3.
32 dimms are represented as SB0::memory.
Pathways to IO are shown as SB0::pci0 , SB0::pci1, SB0::pci2,
SB0::pci3, SB0::pci4, SB0::pci5, SB0::pci6, SB0::pci7.
# cfgadm -a
Ap_Id Type Receptacle Occupant Condition
SB0 System_Brd connected configured ok
SB0::cpu0 cpu connected configured ok
SB0::memory memory connected configured ok
SB0::pci0 io connected configured ok
SB1 disconnected unconfigured unknown

The OBP Device Tree

c0 scsi-bus connected configured unknown
c0::dsk/c0t0d0 disk connected configured unknown
c0::dsk/c0t4d0 CD-ROM connected configured unknown
c0::rmt/0 tape connected configured unknown
c0::smp/expd0 smp connected configured unknown
c0::smp/expd1 smp connected configured unknown
c1 scsi-bus connected configured unknown
iou#0-pci#0 pci-pci/hp connected configured ok
iou#0-pci#1 unknown empty unconfigured unknown
iou#0-pci#4 pci-pci/hp connected configured ok

Processor Device Mapping

The physical address generally represents a physical characteristic unique
to the device, such as the bus address or the slot number where the device
is installed. The use of physical addresses to identify devices prevents
device addresses from changing when other devices are installed or
removed. Each physical device is referenced by its agent identifier.
Decoding Processor Locations on the MX000 Servers

Remember the following information when you decode Processor
locations on the MX000 servers:
There is one Processor on the M3000 motherboard.
There are two Processors per mid-range server CPUM.
There are four Processors per high-end server CMU.
Each Processor is a dual-core processor or quad-core.
Each processor runs two threads.
To OBP and the Solaris OS, a Processor presents four or eight virtual
Processors.

Each LSB has a bank of 32 processor numbers assigned to it, as shown in

Table 5-1.
Table 5-1 Processor Numbering Based on LSB
Processor Numbers
Processor Numbers
LSB (Decimal in the Solaris
(HEX in OBP)
OS)
0 400 (CPU CHIP # 0) 0-7

408 (CPU CHIP # 1) 8-15
410 (CPU CHIP # 2) 16- 23
418 (CPU CHIP # 3) 24-31
1 420 (CPU CHIP # 0) 32-39
428 (CPU CHIP # 1) 40-47
430 (CPU CHIP # 2) 48-55
438 (CPU CHIP # 3) 56-63
2 440 (CPU CHIP # 0) 64-71
448 (CPU CHIP # 1) 72-79
450 (CPU CHIP # 2) 80-87
458 (CPU CHIP # 3) 88-95
3 460 (CPU CHIP # 0) 96-103
468 (CPU CHIP # 1) 104-111
470 (CPU CHIP # 2) 112-119
478 (CPU CHIP # 3) 120-127
4 480 (CPU CHIP # 0) 128-135
488 (CPU CHIP # 1) 136-143
490 (CPU CHIP # 2) 144-151
498 (CPU CHIP # 3) 152-159
5 4a0 (CPU CHIP # 0) 160-167
4a8 (CPU CHIP # 1) 168-175
4b0 (CPU CHIP # 2) 176-183
4b8 (CPU CHIP # 3) 184-191
6 4c0 (CPU CHIP # 0) 192-199
4c8 (CPU CHIP # 1) 200-207
4d0 (CPU CHIP # 2) 208-215
4d8 (CPU CHIP # 3) 216-223
7 4e0 (CPU CHIP # 0) 224-231
4e8 (CPU CHIP # 1) 232-239
4f0 (CPU CHIP # 2) 240-247
4f8 (CPU CHIP # 3) 248-255

Table 5-1 Processor Numbering Based on LSB (Continued)
Processor Numbers
Processor Numbers
LSB (Decimal in the Solaris
(HEX in OBP)
OS)
8 500 (CPU CHIP # 0) 256-263
508 (CPU CHIP # 1) 264-271
510 (CPU CHIP # 2) 272-279
518 (CPU CHIP # 3) 280-287
9 520 (CPU CHIP # 0) 288-295
528 (CPU CHIP # 1) 296-303
530 (CPU CHIP # 2) 304-311
538 (CPU CHIP # 3) 312-319
10 540 (CPU CHIP # 0) 320-327
548 (CPU CHIP # 1) 328-335
550 (CPU CHIP # 2) 336-343
558 (CPU CHIP # 3) 344-351
11 560 (CPU CHIP # 0) 352-359
568 (CPU CHIP # 1) 360-367
570 (CPU CHIP # 2) 368-375
578 (CPU CHIP # 3) 376-383
12 580 (CPU CHIP # 0) 384-391
588 (CPU CHIP # 1) 392-399
590 (CPU CHIP # 2) 400-407
598 (CPU CHIP # 3) 408-415
13 5a0 (CPU CHIP # 0) 416-423
5a8 (CPU CHIP # 1) 424-431
5b0 (CPU CHIP # 2) 432-439
5b8 (CPU CHIP # 3) 440-447
14 5c0 (CPU CHIP # 0) 448-455
5c8 (CPU CHIP # 1) 456-463
5d0 (CPU CHIP # 2) 464-472
5d8 (CPU CHIP # 3) 473-479
15 5e0 (CPU CHIP # 0) 480-487
5e8 (CPU CHIP # 1) 488-495
5f0 (CPU CHIP # 2) 496-503
5f8 (CPU CHIP # 3) 504-511

Decoding I/O Card Locations on the High-End Servers

When mapping an I/O device tree entry to a physical component in the
high-end servers, there are as many as four nodes in the device tree that
must be considered:
Agent ID Determines the LSB location and which Sun Fire server
chip
IOC PCI bus identifier Determines which PCI bus (A or B) is being
referenced
The PCI-E to PCI-E switch
The device identifier
Now, start with the two I/O controller (Oberons in Figure 5-1) and break
down their structure.
Figure 5-1 I/O Controllers on the High-End Servers

That identifies the first part of the address, /pci@0,600000. The second
part of the address is resolved from the PCI-E to OCI-X bridge chip on the
IOUA card, /pci@0,600000/pci@0 (as shown in Figure 5-2).
Figure 5-2 IOU on the High-End Servers
All of the branches from this chip are pci@0.
These are the internal disks shown in the format command output, so
they are connected to the LSI1064 SAS controller. The path is translated up
through /pci@0,600000/pci@0. There is one SCSI path coming off of
pci@0, scsi@1 and the last piece of information in the string shows you
that they are sd@0,0 and sd@1,0, which are SCSI disks at 0 and 1,
respectively, and both at LUN0. Two disks are accessible from controller 0
and two disks are accessible from controller 1. The full device alias that
you would see both at the OBP and in the Solaris OS is:
/pci@0,600000/pci@0/scsi@1/sd@1,0.

The slots on the physical IOU are numbered 03 on the bottom from left
to right and 47 on the top from left to right, as shown in Figure 5-3.
Figure 5-3 IOU Slot Layout on the High-End Servers
As with the CPU IDs, the AIDs are going to change for I/O based on your
LSB assignments. In the following example, the device alias is:
/devices/pci@x,y
where x is the portid and y is 600000 for leaf A and 700000 for leaf B.
The portid (x) changes for LSBs 0 through 15 are shown in Table 5-2.
Table 5-2 I/O Mapping Based on LSB
LSB Device Path
0 /pci@0,600000/
1 /pci@10,600000/
2 /pci@20,600000/
3 /pci@30,600000/

Table 5-2 I/O Mapping Based on LSB (Continued)
LSB Device Path
4 /pci@40,600000/
5 /pci@50,600000/
6 /pci@60,600000/
7 /pci@70,600000/
8 /pci@80,600000/
9 /pci@90,600000/
10 /pci@a0,600000/
11 /pci@b0,600000/
12 /pci@c0,600000/
13 /pci@d0,600000/
14 /pci@e0,600000/
15 /pci@f0,600000/

External I/O Expansion Unit

The External I/O Expansion Unit, which was mentioned in a previous
module, presents some changes to the pathing structure at the OBP based
on whether you are using a PCI-E unit or a PCI-X unit. These units are
administered from the XSCF using the ioxadm command. Figure 5-4
shows a diagram of the I/O Expansion Unit PCI-E I/O Boat.
Figure 5-4 I/O Expansion Unit PCI-E I/O Boat
The OBP device pathing structure for the I/O Expansion Unit PCI-E I/O
Boat is shown in Figure 5-5.
Figure 5-5 I/O Expansion Unit PCI-E I/O Boat Device Paths

The I/O Expansion Unit PCI-X I/O Boat which is shown in Figure 5-6 is
also supported.
Figure 5-6 I/O Expansion Unit PCI-X I/O Boat
The OBP device path structure for the I/O Expansion Unit PCI-X I/O
Boat can be seen in Figure 5-7.
Figure 5-7 I/O Expansion Unit PCI-X I/O Boat Device Paths

The Solaris OS
The Solaris OS
Remember the following about the Solaris OS running on your server:
Each domain has its own, independent copy of Solaris.
The minimum level of the Solaris OS required for a domain is the
Solaris 10 OS, update 4 (08/07). The best performance comes with
Solaris 10 update 7 (05/09).
Remember to install the recommended patches.
All applications that are not platform-dependent should run in a
domain without requiring change.
Because a domain does not have a keyboard, monitor, or serial port,
it is controlled through a console window from the service processor.
The Solaris OS detects the service processor as interface ttya.
Note A domain must be populated with enough resources to meet the

requirements of the applications. Before you configure the domains,
determine what these requirements are in order to ensure proper
operation.

Configuring the Solaris OS in a New Domain

After the domain has been built and you have installed the Solaris OS,
configure the system to operate properly in your environment.
Configuring Services for the Solaris 10 OS

The following services should be enabled on all MX000 servers:
svc:/platform/sun4u/dscp:default
svc:/platform/sun4u/sckmd:default
svc:/platform/sun4u/dcs:default
Use the svcs command to verify the listed services are online. The
svcadm command is used to enable or disable services. Enable the dscp
service first. Check your network configuration using ifconfig. If the
sppp0 interface does not exist, that is an indication that the dscp service is
NOT enabled.
godzilla-dom0 # ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
inet 127.0.0.1 netmask ff000000
bge0: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 2
inet 10.6.15.30 netmask ff000000 broadcast 10.255.255.255
ether 0:b:5d:e0:5:1a
godzilla-dom0 # svcadm -v enable dscp

svc:/platform/sun4u/dscp:default enabled.
godzilla-dom0 # Feb 26 23:06:46 godzilla-dom0 ip:
ipsec_check_inbound_policy: Policy Failure for the incoming packet (not
secure); Source 192.168.224.001, Destination 192.168.224.002.
godzilla-dom0 # ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
inet 127.0.0.1 netmask ff000000
bge0: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 2
inet 10.6.15.30 netmask ff000000 broadcast 10.255.255.255
ether 0:b:5d:e0:5:1a

sppp0:
flags=10010008d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,IPv4,FIXEDMTU>
mtu 1500 index 4
inet 192.168.224.2 --> 192.168.224.1 netmask ffffff00
ether 0
godzilla-dom0 # svcadm -v enable sckmd

svc:/platform/sun4u/sckmd:default enabled.
godzilla-dom0 # svcadm -v enable dcs

svc:/platform/sun4u/dcs:default enabled.
Finishing the Installation

Configure any disk or network multipathing software that you intend to
use.

Exercise: Administering and Configuring the Domain

Build a domain with a uni-mode XSB
Power up the domain
Decoding OBP aliases and mapping them to their corresponding
XSBs
Boot the Solaris OS
Build a domain with a quad-mode XSB
Power up the domain
Decoding OBP aliases and mapping them to their corresponding
XSBs
Boot the Solaris OS
Note This exercise has been written with the assumption that the
student will have remote access to an MX000 server.
Preparation
To prepare for this exercise:
Your instructor will assign a server to each group. Your assigned server is:
_________________________________________________________________

Task 1 Building a Domain with a uni-mode XSB

In this task, you reconfigure your existing domain. Complete the
following steps:
1. Log in to your assigned service processor.
2. What CPUM, MEMB, and IOU resources are in on your server?
Command:___________________________________________________
3. Are your XSB resources allocated to a domain or in the system pool?
Command:___________________________________________________
4. Put PSB set #00 in uni-mode. Record the command used:
Command:___________________________________________________
5. Add an LSB# of 0 to XSB 00-0 for domain 0. Record the command
used:
Command:___________________________________________________
6. Verify if a power-up delay has been set. Record the command used:
Command:___________________________________________________
7. Set the auto-boot parameter to off for domain 0. Record the
command used:
Command:___________________________________________________
8. Set the secure parameter to off for domain 0. Record the command
used:
Command:___________________________________________________
9. Add XSB 00-0 to domain 0. Record the command used:
Command:___________________________________________________
10. Run the power-on self-test for domain 0. Record the command used:
Command:___________________________________________________
11. What command will allow you to access you domain? Record the
command used:
Command:___________________________________________________
12. At the obp, determine how many disk devices your domain has and
their target ids. Record the command used:
Command:___________________________________________________

13. At the obp, determine how many network interfaces your domain
has. Record the command used:
Command:___________________________________________________
14. At the obp, determine how many processors your domain has.
Command:___________________________________________________
15. How many processors you have for domain 0? Record the command
used:
Command:___________________________________________________
16. Boot to Solaris. Record the command used:
Command:___________________________________________________
17. Verify your network interfaces. Record the command used:
Command:___________________________________________________
18. Verify your LSB #s. Record the command used:
Command:___________________________________________________
19. Determine what SBs are connected and configured. Record the
command used:
Command:___________________________________________________
20. Halt your domain. Record the command used:
Command:___________________________________________________
21. Return to the service processor XSCF prompt. Record the command
used:
Command:___________________________________________________
22. Power off domain 0. Record the command used:
Command:___________________________________________________
23. Delete XSB 00-0. Record the command used:
Command:___________________________________________________
24. Remove LSB #0. Record the command used:
Command:___________________________________________________

Task 2 Building a Domain with a quad-mode XSB

following steps:
Command:___________________________________________________
2. Put PSB set #00 in quad-mode. Record the command used:
Command:___________________________________________________
used:
Command:___________________________________________________
Command:___________________________________________________
Command:___________________________________________________
command used:
Command:___________________________________________________
Command:___________________________________________________
Command:___________________________________________________
Command:___________________________________________________
used:
Command:___________________________________________________
Command:___________________________________________________

Command:___________________________________________________
command used:
Command:___________________________________________________
Command:___________________________________________________
used:
Command:___________________________________________________
Command:___________________________________________________
Command:___________________________________________________
Command:___________________________________________________

Task 3 Building a Domain with two quad-mode XSBs

following steps:
Command:___________________________________________________
2. Add an LSB# of 0 to XSB 00-0 and a LSB# of 5 to XSB 00-1 for domain
0. Record the command used:
Command:___________________________________________________
3. Add XSB 00-0 and XSB 00-1 to domain 0. Record the command used:
Command:___________________________________________________
Command:___________________________________________________
command used:
Command:___________________________________________________
Command:___________________________________________________
Command:___________________________________________________
Command:___________________________________________________
used:
Command:___________________________________________________
10. What are the device paths for PCI-E card slot 3 and 4? Record the
command used and the device path information:
Command:___________________________________________________
Device path card slot 3:________________________________________
Device path card slot 4:________________________________________


Command:___________________________________________________
Command:___________________________________________________
command used:
Command:___________________________________________________
Command:___________________________________________________
used:
Command:___________________________________________________
Command:___________________________________________________
17. Delete XSB 00-0 and XSB 00-1. Record the command used:
Command:___________________________________________________
18. Remove LSB #0 and LSB #5. Record the command used:
Command:___________________________________________________
19. Put PSB set # 00 in uni-mode. Record the command used:
Command:___________________________________________________

Task 4 Sending a break signal to the OS

In this task, will cause the OS to stop abruptly. Complete the following
steps:
1. Build domain 0 with a uni-mode XSB or quad-mode XSB.
Commands:__________________________________________________
2. Power on the domain 0.
Command:___________________________________________________
3. Console to the domain 0.
Command:___________________________________________________
4. Boot to Solaris.
Command:___________________________________________________
used:
Command:___________________________________________________
6. Send a break to take domain 0. Record the command used:
Command:___________________________________________________

Exercise Summary
Exercise Summary

!
?
Experiences
Interpretations
Conclusions
Applications

Exercise Solutions
Exercise Solutions
This section provides solutions to the exercises.

Exercise Solutions
Task 1 Building a Domain with a uni-mode XSB

following steps:
1. Log in to your assigned service processor.
2. What CPUM, MEMB, and IOU resources are in on your server?
Command: showhardconf

Resource
(y or n)
PSB#00
CPUM#0-CHIP#0
CPUM#0-CHIP#1
CPUM#1-CHIP#0
CPUM#1-CHIP#1
MEMB#0
MEMB#1
MEMB#2
MEMB#3
IOU#0
PSB#01
CPUM#2-CHIP#0
CPUM#2-CHIP#1
CPUM#3-CHIP#0
CPUM#3-CHIP#1
MEMB#4
MEMB#5
MEMB#6

Exercise Solutions

Resource
(y or n)
MEMB#7
IOU#1

Command: showboards -a
4. Put PSB set #00 in uni-mode. Record the command used:
Command: setupfru -x 1 sb 0
used:
Command: setdcl -d 0 -a 0=00-0
6. Verify if a power-up delay has been set. Record the command used:
Command: showpowerupdelay
7. Set the auto-boot parameter to off for domain 0. Record the
command used:
Command: setdomainmode -d 0 -m autoboot=off
8. Set the secure parameter to off for domain 0. Record the command
used:
Command: setdomainmode -d 0 -m secure=off
Command: addboard -d 0 -c assign 00-0
Command: poweron -d 0 -y
command used:
Command: console -d 0 -y
Command: probe-scsi-all
Command: show-nets

Exercise Solutions
Command: show-devs
used:
Command: four, show-devs
Command: boot
17. Verify your network interfaces. Record the command used:
Command: ifconfig -a
Command: prtdiag -v
command used:
Command: cfgadm -a
Command: init 0
used:
Command: #.
Command: poweroff -d 0 -y
Command: deleteboard -c unassign 00-0
Command: setdcl -d 0 -r 0

Exercise Solutions
Task 2 Building a Domain with a quad-mode XSB

following steps:
used:
command used:
Command: show-nets
Command: show-devs
used:
Command: one, show-devs
Command: boot

Exercise Solutions
Command: prtdiag -v
command used:
Command: cfgadm -a
Command: init 0
used:
Command: #.
Command: deleteboard -c unassign 00--0
Command: setdcl -d 0 -r 0

Exercise Solutions
Task 3 Building a Domain with two quad-mode XSBs

following steps:
2. Add an LSB# of 0 to XSB 00-0 and a LSB# of 5 to XSB 00-1 for domain
0. Record the command used:
Command: setdcl -d 0 -a 0=00-0 5=00-1
3. Add XSB 00-0 and XSB 00-1 to domain 0. Record the command used:
Command: addboard -d 0 -c assign 00-0 00-1
command used:
Command: show-nets
Command: show-devs
used:
Command: two, show-devs
10. What are the device paths for PCI-E card slot 3 and 4? Record the
command used and the device path information:
Command: show-devs
Device path card slot 3: /pci@52,600000
Device path card slot 4: /pci@53,700000

Exercise Solutions

Command: boot
Command: prtdiag -v
command used:
Command: cfgadm -a
Command: init 0
used:
Command: #.
17. Delete XSB 00-0 and XSB 00-1. Record the command used:
Command: deleteboard -c unassign 00-0 00-1
18. Remove LSB #0 and LSB #5. Record the command used:
Command: setdcl -d 0 -r 0 5
19. Put PSB set # 00 in uni-mode. Record the command used:

Exercise Solutions
Task 4 Sending a break signal to the OS

In this task, will cause the OS to stop abruptly. Complete the following
steps:
1. Build domain 0 with a uni-mode XSB or quad-mode XSB.
Commands: setupfru -x 1 sb 0 or setupfru -x 4 sb 0
Commands: setdcl -d 0 -a 0=00-0
Commands: addboard -d 0 -c assign 00-0
2. Power on the domain 0.
3. Console to the domain 0.
4. Boot to Solaris.
Command: boot
used:
Command: #.
6. Send a break to take domain 0. Record the command used:
Command: sendbreak -d 0 -y

Objectives
Module 6
Dynamic Domain Reconfiguration
Objectives
Document the purpose and benefits of Dynamic Reconfiguration
(DR)
Analyze the locations from which DR can be performed
Discuss the concepts of DR in preparation for attaching and
detaching XSBs
Describe I/O restrictions and concerns in regards to DR
Describe memory restrictions and concerns in regards to DR
Describe CPU restrictions and concerns in regards to DR
Describe Extended System Board (XSB) considerations and directives
Perform DR using the Service Processor to add or remove an XSB
from a domain
Dynamic Domain Reconfiguration 6-1

Objectives
Relevance

dynamic reconfiguration ia all about:
!
? What is the purpose of Dynamic Reconfiguration on the MX000
servers?
What are the attach operations?
What are the detach operations?
What factors must be considered before performing Dynamic
Reconfiguration on the MX000 servers?
What are the XSB considerations and what impact do they have in a
Dynamic Reconfiguration operation?
Which commands perform Dynamic Reconfiguration?
What are the steps involved in performing various Dynamic
Reconfiguration tasks?


5872-xx.
number 819-3601-xx.


http://docs.sun.com

Introducing Dynamic Reconfiguration
Introducing Dynamic Reconfiguration

Dynamic Reconfiguration, or DR, performs resource management by
altering the configuration of a running domain.
Dynamic Reconfiguration does this by adding or removing XSB resources

with minimal or no interruption to domain operations.
A Dynamic Reconfiguration operation avoids down time because a

domain reboot is not required.
Dynamic Reconfiguration functions of Sun SPARC Enterprise MX000

servers are performed on Extended System Boards (XSBs) or PCI cards.
The M3000 does not support DR operations.
Note The MX000 servers XSBs may consist of CPU, Memory, and I/O.
Its important to know your domain configuration including expected
service levels before performing the removal of an XSB.
DR is also useful on a high-end server if a Physical System Board set has

a failure and components must be replaced. DR capability is a critical part
of the concurrent maintenance strategy on the high-end servers.
Benefits of DR
Dynamic Reconfiguration allows you to:
Dynamically configure XSBs into domains
Dynamically unassign XSBs from domains
Dynamically move XSBs between domains
Display XSB status
Hot-plug individual PCI cards from a domain using the Solaris
cfgadm command
Note You cannot use DR in concert with the replacefru command to

service a CPUM, MEMB, or IOU board in a mid-range server. To service a
CPUM, MEMB, or IOU board in a mid-range server, you must turn off the
power to all domains, turn off power to the server, and then service the
degraded CPUM, MEMB, or IOU board.

DR Operational Locations
DR Operational Locations
DR operations can be performed from two locations:
From the service processor
From the domain
Sun SPARC Enterprise Service Processor

You can execute DR operations from the service processor by using the
XSCF commands addboard, deleteboard, and moveboard to
accomplish the following tasks:
XSB addition (addboard) Dynamically adds an XSB to a domain
XSB deletion (deleteboard) Dynamically deletes an XSB from a
domain
XSB deletion and addition (moveboard) - Dynamically deletes an
XSB from one domain and Dynamically adds the XSB to another
domain
Domain
The cfgadm command can be run directly from the domain to get
resource status and to dynamically reconfigure PCI adapters only. The
cfgadm command was first introduced for the previous Sun Enterprise
server line of platforms.
Note In the MX000 server line, the cfgadm command does not support
DR operations for XSBs.

DR Concepts
DR Concepts
DR lets you perform maintenance on an active domain by disconnecting
and then reconnecting XSBs without bringing the domain down. In
addition to maintenance on the high-end servers, DR also provides
enhanced performance by allowing XSB addition (thus more processors,
memory, and I/O) at periods when resource requirements are high.
Preparing the Domain for DR Operations

The domain must be properly configured so that XSBs containing critical
domain resources can be removed. You must plan ahead to ensure that
the domain is properly configured.
This means that critical domain disks must be configured with

multipathing, disk mirroring, or both. If the root or /usr partition is on
a disk attached to an I/O controller on the XSB to be removed, the XSB
cannot be detached unless there is a hardware alternate path to the disk or
the disk is mirrored using an I/O controller on another XSBs.
The same applies to network controllers. The XSB that hosts the primary
network interface that connects to the domain cannot be detached unless
multiple network paths exist to the same network using another XSB in
the same domain.
In addition to planning for the XSB resource changes, you must also make
sure that the XSB is in the domain component list for whichever domain
or domains the XSB will be added to or removed from. This can be
verified from the output of the showdcl -a command. If a XSB needs to
be added to a domains component list prior to a DR operation, use the
setdcl command to do this.

DR attach Operation
DR attach Operation
The DR attach operation adds the specified XSB to a domain running the
Solaris OS. When the XSB is added and the XSBs resources and interfaces
are configured to the domain, the domain uses them without any
difficulty. The steps for an attach operation include:
Assign the XSB.
Configure the XSB.
DR attach States
When performing a DR attach operation, two levels of state change are
supported:
Assign When assign is specified, the DR software reserves the XSB
for the specified domain. At this point the XSB cannot be configured
in or assigned to other domains.
The assigned XSB is configured in the domain by a reboot or
execution of the addboard command with the configure option.
Reserve When reserve is specified, the DR software reserves the
XSB for the specified domain. At this point the XSB cannot be
configured in or assigned to other domains.
The assigned XSB is configured in the domain by a reboot or
execution of the addboard command with the configure option.
Configure When configure is specified, the DR software performs
hardware-specific operations that allow an XSBs resources for use
by the Solaris OS. XSBs that are configured are part of the domain
configuration and are available for manipulation by the Solaris OS
software device manipulation maintenance commands, such as
psradm, mount, and ifconfig.
When the configure operation is complete, the XSB in question is
recognized by the Solaris OS.
If you are attaching an XSB with I/O devices you might still have to run
the devfsadm command manually to create new device files.
Note When attaching XSB to a domain, the existing controllers retain

their original numbering. New disk controllers on a newly attached XSB
are assigned the next available lowest number.

DR detach Operation
DR detach Operation
A DR detach operation removes the specified XSB from a domain, which
must be already running the Solaris OS.
While attaching an XSB is a straightforward operation, detaching an XSB

can be complex. When removing an XSB from a running domain, the
operating environment must stop using all of the XSBs resources. These
resources fall into three general categories:
Input/Output to the interface controllers, both disk and network,
connected to the XSB
Data from the XSBs memory, including the kernel if detaching the
XSB where the kernel resides
Work from the processors, including interrupts from device drivers
Each resource has inherent issues that determine whether DR can be

performed. For example, the issues associated with dynamically
reconfiguring an XSB with non-pageable memory are different from an
XSB with pageable memory. These types of issues are described
throughout this module. The steps for a detach operation include:
7. Unassign the XSB.
8. Disconnect the XSB.
9. Reserve the XSB.

DR detach Operation
DR detach States
When performing a DR detach operation, three levels of state change are
supported:
Unassign When unassign is specified, the DR software completely
disconnects the XSB from the domain configuration and puts it in the
available system pool where it can be incorporated into other
domain configurations.
Disconnect This changes the receptacle state to disconnected. If the
occupant state is configured, the disconnect function first attempts to
unconfigure the XSB. The disconnect function powers the XSB off by
default. The disconnect function powers off a PCI Card which can
now be removed from its PCI slot. Because the XSB remains
assigned to the domain, it can be configured again by a domain
reboot or the execution of the addboard command.
Reserve When reserve is specified, the DR software does not
immediately disconnect the XSB from the domain configuration but
only reserves detachment. When the domain is powered off or
rebooted, the reserved XSB is disconnected and unassigned from the
domain and the XSB is placed in the system pool.

I/O Unit Considerations

When a new XSB with I/O is configured into a domain, the new XSB and
its I/O are automatically tested. XSB testing requires dedicated CPU and
memory resources.
When performing DR detach operations on XSBs with I/O, you must

consider the following:
Multipath I/O configuration
Detach-safe and suspend-safe devices
Multipathed I/O Configuration

In a multipath I/O configuration, multiple physical paths (channels) to
the same media are mapped to the same logical device. The logical device
then accesses the media. The benefit of this configuration is that if one of
the physical paths is disabled, I/O access continues on the remaining
physical path with little interruption. The Solaris OS provides two forms
of multipathed I/O:
Sun StorageTek Traffic Manager software
IP network multipathing (IPMP)
Both Sun StorageTek Traffic Manager software and IPMP are key
components of DR operations on XSBs with I/O components. If the
domains vital system resources are multipath configured, then a DR
operation can be performed on one of the physical paths without
interrupting access to the device.
If you are planning to perform DR operations on XSBs with I/O

components, you must first determine whether multipathing is currently
implemented.

Detach-Safe and Suspend-Safe Devices

While all Sun Microsystems device drivers support DR operations, other
third-party drivers might not. This means that devices managed by those
drivers will require special attention during DR detach.
To support DR, a driver must be able to perform two specific operations:

DDI_DETACH and DDI_SUSPEND/DDI_RESUME. These two functions affect
DR in different ways:
DDI_DETACH support is required to detach a device from the
operating system. It means that the driver can close the device, as if
it was never used.
DDI_SUSPEND/DDI_RESUME must be supported if the device is to be
suspended (quiesced) while moving permanent memory, such as
moving the kernel.
If the driver does not detach or suspend, you must unload the device
driver using the modunload command.
Note While detach-safe and suspend-safe are both characteristics of I/O

device drivers, these issues never arise simultaneously. A device must be
detach-safe only when you are detaching the controller device (I/O unit
or card) itself. A device needs to be suspend-safe when you are detaching
the XSB with the permanent memory.
The modunload Command
When you have identified the driver to remove from memory, run the
modunload command to delete it from the kernel. Use the modinfo
command to get the device drivers ID number. It is not always the same
and is not the driver major number from the /etc/name_to_major file.
1. Run the modinfo command to get the driver ID. The driver ID is the
first number in the modinfo command output; in this case, 307.
# modinfo | grep -i joe
307 f66a0000 dfe9 33 1 jn (Joes Non-compliant driver, v. 0.6)
2. Run the modunload command, specifying the driver number
from the modinfo command.
# modunload -i 307

System Memory Considerations

When performing DR detach operations on the MX000 servers, two types
of memory must be considered: permanent (non-pageable) memory and
swap space
Detaching Permanent Memory

Some of the memory used by the Solaris OS must be fixed in real
memory. This memory contains the kernel structures that control the
internal system and configuration information, such as page tables and
device drivers. This memory is non-pageable. It cannot be paged out of
real memory and, in fact, cannot be moved at all. It is referred to as
permanent or non-pageable memory.
Note By default, the kernel is caged on the XSB with the lowest LSB #.
An XSB with non-permanent or pageable memory can be easily detach.

The contents of memory are moved to swap, and the processes are moved
to other memory locations on another XSB without interrupting current
activity.
Performing a DR detach operation on an XSB that contains non-pageable

memory, however, needs special considerations. The memory cannot be
paged out to swap to free the XSBs memory banks, and the XSB cannot
be unconfigured with the kernel running without causing the failure of
most current activity in the system.
Quiescence
To remove an XSB with non-pageable memory, DR must quiesce the

operating system. All operating system and device activity in the domain
must cease during a critical phase of the operation. Quiesce implies that
all system operations, including I/O operations, are suspended for the
period of time that it takes to move the data from the XSB being detached
to a remaining XSB. All device drivers must be suspended and then
resumed after the kernel memory is moved to another XSB.
Note Permanent memory can only be relocated to another XSB with the
same amount of memory or a greater amount of memory.

Swap Space
Configure system swap space as multiple partitions or files on disks
attached to controllers owned by different XSBs. This allows any swap
partition or file to be easily replaced with the swap command. It also has a
side benefit of providing better swap performance because any swap load
is spread over several I/O controllers.
When detaching memory or disk swap space, there must be enough

memory and swap disk space remaining in the system to accommodate
all of the currently running programs. The domain must contain enough
remaining configured swap space so it can flush pageable memory from
the XSB being detached. For example, if you want to remove 1 Gbyte of
memory from a 2-Gbyte system, you might need 2 Gbytes of swap space
just for DR.
The amount of additional swap space that you need is equal to the
amount of main storage on two domain XSBs. To be able to handle every
case, you must plan to use the largest memory amount on any domain
XSB.
Insufficient swap space prevents DR from completing the detach of a XSB

that contains memory. If this happens, the memory drain phase of the
detach operation is not able to complete, and you must abort the detach
operation.
Depending on how short of swap space you are, the DR operation might
fill all available swap space and hang the DR operation.
Ensure that you have enough space in the new primary swap partition
(and in the /var directory) to contain a full domain panic dump.
Note DR does not verify whether enough swap space is available before
starting the detach operation. You can use DR to determine how much
memory must be drained from the XSB and then use the swap -l
command to determine if the current amount of system swap space is
sufficient.

CPU Considerations
CPU Considerations
Two conditions can make it impossible for you to detach an XSB related
to the CPUs themselves:
A running process has threads bound to a CPU being removed.
A processor being removed is the last in its processor set.
Bound Threads
Process threads can be programatically or administratively bound to a
particular CPU. That is, they run on only that particular CPU. A CPU that
has any bound threads cannot be removed through a DR operation.
You can use the pbind command to list any processes that have bound
threads and to unbind those threads if you need to remove a particular
CPU:
# pbind
process id 40848: 0
# pbind -u 40848
process id 40848: was 0, now not bound
Processor Sets
Threads can be bound to processor sets rather than individual processors.
By default, no processor sets exist, but they can be created by the root
user.
Removing a CPU that is a member of a processor set is a problem only if

it is the last member of the set. If you need to remove a CPU, you can
remove the processor set, which will also unbind any threads that are
bound to the set:
# psrset -d 1
or you can add another CPU to the set:

# psrset -a 1 320

CPU Considerations
Dynamic Reconfiguration Operations and Resource

Pools
Dynamic Reconfiguration (DR) enables you to reconfigure hardware
while the system is running. A Dynamic Reconfiguration operation can
increase, reduce, or have no effect on a given type of resource. Because
DR can affect available resource amounts, the pools facility must be
included in these operations. When a Dynamic Reconfiguration operation
is initiated, the pools framework acts to validate the configuration.
If the Dynamic Reconfiguration operation can proceed without causing

the current pools configuration to become invalid, then the private
configuration file is updated. An invalid configuration is one that cannot
be supported by the available resources.
If the Dynamic Reconfiguration operation would cause the pools

configuration to be invalid, then the operation fails and you are notified
by a message to the message log.

XSB Settings and Considerations

The DR command set provides users with some options to help avoid the
complexities of reconfiguration and memory allocation within the Solaris
OS and to make DR operations smoother. You can set these options on the
XSCFU with the setdcl command and they pertain to the following:
Configuration policy
Floating board
Omit-memory
Omit-I/O
Configuration Policy Option

DR attach operations involve automatic hardware testing to add or
move an XSB safely. Degradation of components occurs when a hardware
error is detected. The range of degradation is set according to the
configuration policy option.
The unit of degradation can be a component where the hardware error is

detected (fru), the extended system board (xsb) where the component
resides, or the domain as a whole (system).
This option is set using setdcl -s policy=value. The default value of

the configuration policy option is FRU.
The default policy is fru. If any resource for the XSB fails post, then the
domain will not be able to use that resource.
XSCF> setdcl -d 0 -s policy=fru
If you change the value of the policy to xsb, any post failure of an XSB
resource causes the entire XSB to be unusable.
XSCF> setdcl -d 0 -s policy=xsb
If you change the value of the policy to system, any failure during post
causes the entire domain to fail post.
XSCF> setdcl -d 0 -s policy=system

Floating Board Option

The floating board option is a way to control where the kernel memory
gets allocated. When deleting an XSB that contains the kernel memory,
the OS is temporarily suspended. There must be another XSB in the
domain with memory that does not have the floating board option set to
true so the kernel can move.
The floating board option allows you to control if an XSB can have
permanent memory.
Note An XSB with the float option set to true can never hold the kernel
cage. The only exception to the rule is: If all XSBs are set to float (static
domain creation), the kernel must get caged somewhere.
By default, kernel memory is allocated to memory on the XSB (with the

lowest LSB #) with the float option set to false. When all of the XSBs in a
domain are set to be floating XSBs, one of them is selected and used as the
kernel memory XSB. When this happens, the status of that XSB is changed
to non-floating.
The value of this option can be set to true to enable the floating board
setting or false to disable it with setdcl -s float=value LSB#. The
default value is false. An XSB that has this option set to true is called a
floating board.
XSCF> setdcl -d 0 -s float=true 1 2 3

Omit-Memory Option
When the omit-memory option is enabled, the memory on an XSB cannot
be used in the domain. This option can be used when the domain needs
the XSBs CPU resources and not the memory. It will make the attach
operation much faster because the XSBs memory will not be tested.
Note This option will not allow unmounted XSBs with no associated
memory to be used. The associated memory must exist to be omitted.
The value of this option can be set true to omit memory or false to not
omit memory on the XSB with the setdcl -s no-mem=value LSB#. The
default value is false.
XSCF> setdcl -d 0 -s no-mem=true 1 2 3
Omit-I/O Option
The omit-I/O option disables the PCI cards, disk drives, and network
ports on an XSB to prevent the target domain from using them. You set
the omit-I/O option to true when the target domain only needs to use
the XSBs CPU and memory. Having the option set to false allows the
target domain to use all of the I/O resources on the XSB.
The value of this option can be set to true to omit the I/O units or false
to not omit them with setdcl -s no-io=value LSB#. The default value
is false.
XSCF> setdcl -d 0 -s no-io=true 1 2 3
Verifying XSB settings and configuration
To verify the XSB settings and configuration, use the showdcl command
with the verbose option.
XSCF> showdcl -av
DID LSB XSB Status No-Mem No-IO Float Cfg-policy
00 Powered Off FRU
00 00-0 False False False
01 00-1 True True True

Performing DR From the XSCFU

The XSCF software on the system controller supports DR operations
through its CLI when domains are active. In a static domain environment,
the commands addboard, deleteboard, and moveboard are used with
the domain power set to off. These same commands used on an active
domain initiate a DR operation.
XSCF Commands
Before a DR operation can be performed, the administrator must have the
proper privileges to perform the DR operation. The following commands
perform a DR operation from the XSCF softwares CLI:
The addboard command Dynamically configures, attaches, and
incorporates an XSB into the specified domain.
The deleteboard command Dynamically unconfigures, detaches,
and removes an XSB from the specified domain.
The moveboard command Dynamically unconfigures, detaches,
and removes an XSB from the specified domain and dynamically
configures, attaches, and incorporates this XSB into another specified
domain.
The showdcl and setdcl commands Displays and allows you to
set the current domain component list. XSBs must be in a domains
DCL prior to executing a DR operation.
The showdomainstatus command Displays the domains current
status and should be used both before and after DR operations.
The showboards command Displays XSB information and should
be used both before and after DR operations.
The showdevices command Displays device information
including CPUs, memory, and PCI card information and should be
used before a DR detach operation.
The showfru and setupfru commands Displays and allows you to
modify XSB configuration. They should be used before DR
operations if you need to change the XSBs configuration.

The addboard Command

The addboard command configures an XSB into the domain configuration
or assigns it to the domain configuration. A user with platadm privileges
can run this command for all domains. Users with domainadm privileges
can run this command for their managed domain only. If the XSBs are not
already assigned to the domain, they must be in the DCL of the domain.
In the following example, XSB 01-0 is in the system pool (SP) and is not in
the domain component list for any domain.
XSCF> showboards -a
---- -------- ----------- ---- ---- ---- ------- --------
00-0 00(00) Assigned y y y Passed Normal
XSCF> showdcl -a
DID LSB XSB Status
00 Running
00 00-0
In the next set of examples, XSB 01-0 is added to the domain component
list for domain 0 and its status is verified.
XSCF> showdcl -a
DID LSB XSB Status
00 Running
00 00-0
01 01-0
The XSB now has an LSB # but is still not allocated to domain 0.
XSCF> showboards -a
---- -------- ----------- ---- ---- ---- ------- --------

Configuring the XSB into Domain 0
In this next example: XSB 01-0 is currently in the system pool and is not
yet assigned to domain 0. When you execute the addboard command, the
configure function also performs the assign function if it has not been
performed yet.
XSCF> addboard -d 0 -c configure 01-0
XSB#01-0 will be configured into DomainID 0. Continue?[y|n] :y
Initial diagnosis started. [1800sec]
0..... 30..... 60..... 90.....120.....150.....180.....210.....end
Initial diagnosis has completed.
Start configuring XSB to domain.
Configured XSB to domain.
XSCF> showboards -a
---- -------- ----------- ---- ---- ---- ------- --------
Clips of messages viewed from the active domain:

<output omitted>
Feb 26 21:17:01 godzilla-dom0 unix: [ID 950921 kern.info] cpu59: SPARC64-
VI (portid 1080 impl 0x6 ver 0x92 clock 2280 MHz)
...
Feb 26 21:17:02 godzilla-dom0 drmach: [ID 713682 kern.info] cpu59
initialization complete - restarted
...
Feb 26 21:17:02 godzilla-dom0 dr: [ID 606818 kern.notice] OS configure
dr@0:SB1::memory
...
Feb 26 21:17:12 godzilla-dom0 dr: [ID 606818 kern.notice] OS configure
dr@0:SB1::pci0
...

The deleteboard Command

The deleteboard command is used to delete an XSB from a domain and
assign it to the system pool. A user with platadm privileges can run this
command for all domains. Users with domainadm privileges can run this
command for their managed domain only.
The unassign function calls the disconnect function if the domain is

active and the XSB is not yet disconnected.
There is no -d option. The deleteboard command automatically figures

out in which domain the XSB is configured.
It is a good idea to run the showboards command prior to a

deleteboard command to verify where XSBs are allocated.
In the following example, XSB 01-0 is unassigned from domain 0. Notice

from the showboards output that the XSB goes back into the system pool
(SP) but the LSB/XSB association in the domains component list remains.
XSCF> showboards -a
---- -------- ----------- ---- ---- ---- ------- --------
XSCF> deleteboard -c unassign 01-0

XSB#01-0 will be unassigned from domain immediately. Continue?[y|n] :y
Start unconfiguring XSB from domain.
Unconfigured XSB from domain.
XSB power off sequence started. [1200sec]
0.end
Operation has completed.
XSCF> showboards -a
---- -------- ----------- ---- ---- ---- ------- --------
01-0 SP Available y n n Passed Normal
XSCF> showdcl -a
DID LSB XSB Status
00 Running
00 00-0
01 01-0

Clips of messages viewed from the active domain:

<output omitted>
Feb 26 21:29:40 godzilla-dom0 mac: [ID 846399 kern.info] NOTICE: bge5/0
unregistered
Feb 26 21:29:40 godzilla-dom0 genunix: [ID 408114 kern.info]
/pci@10,600000/pci@0,1/network@1,1 (bge5) offline
...
Feb 26 21:29:50 godzilla-dom0 dr: [ID 427603 kern.notice] OS unconfigure
dr@0:SB1::cpu3
...
Feb 26 21:29:56 godzilla-dom0 dr: [ID 427603 kern.notice] OS unconfigure
dr@0:SB1::memory
...
To verify if an XSB has been reserved for detachment, use the

showboards command with the verbose option.
XSCF> deleteboard -c reserve 1-0
XSB#01-0 will be unassigned from domain after the domain restarts.
Continue?[y|n] :y
XSCF> showboards -av

XSB R DID(LSB) Assignment Pwr Conn Conf Test Fault COD
---- - -------- ----------- ---- ---- ---- ------- -------- ----
00-0 00(00) Assigned y y y Passed Normal n
00-2 SP Unavailable y n n Unmount Normal n
01-0 * 00(02) Assigned y y y Passed Normal n

The moveboard Command

The moveboard command moves a specified XSB between domains
without halting operations on either domain. This command can be used
on both static and dynamic domains.
Remember that running the following command:

moveboard -d domain -c function XSB
is identical to running the following two commands in sequence:

deleteboard -c unassign XSB
addboard -d domain -c function XSB
It is a good idea to run the showboards command prior to a moveboard

command to verify where XSBs are allocated.
The following example illustrates moving XSB 01-0 dynamically from

domain 0 and assigning the XSB to domain 1. Both XSB 00-0 and 01-0 are
assigned, connected, and configured into domain ID 0 (DID 00).
XSCF> showboards -a
---- -------- ----------- ---- ---- ---- ------- --------
To move an XSB between domains, the XSB needs to be part of the DCL
for both the source and destination domains. Below, the XSB is being
added to the DCL for domain 1. Notice that domain 1 (DID 01) is
currently powered off.
XSCF> showdcl -a
DID LSB XSB Status
00 Running
00 00-0
01 01-0
---------------------------
01 Powered Off
00 01-0

Next, the XSB is moved out of its current domain (DID 00) and is assigned
to domain 1.
XSCF> moveboard -d 1 -c assign 01-0
XSB#01-0 will be assigned to DomainID 1 immediately. Continue?[y|n] :y
Start unconfiguring XSB from domain.
Unconfigured XSB from domain.
XSB power off sequence started. [1200sec]
0.end
Operation has completed.
You can see in the showboards output that XSB 01-0 is now assigned to
domain 1 (DID 01) but it is not yet connected or configured.
XSCF> showboards -a
---- -------- ----------- ---- ---- ---- ------- --------
01-0 01(00) Assigned y n n Passed Normal

Exercise: Performing DR Operations

In this lab, you perform DR operations to add resources into your
domain, remove resources from your domain, and move resources
between domains. You will need to have at least one PSB set in quad-
mode to perform this exercise.
Preparation
You will need to know the current system configuration. If your domain
is built with a uni-mode XSB, halt the domain, power off the domain, and
remove the XSB from the domain. Remove all LSB entries that exist.
Task 1 - Performing Dynamic Reconfiguration

Command:___________________________________________________
Command:___________________________________________________
3. Add an LSB# of 0 to XSB 00-0 and an LSB# of 1 to XSB 00-1 for
domain 0. Record the command used:
Command:___________________________________________________
used:
Command:___________________________________________________
5. Assign XSB 00-0 and XSB 00-1 to domain 0. Record the command
used:
Command:___________________________________________________
Command:___________________________________________________
command used:
Command:___________________________________________________


Command:___________________________________________________
used:
Command:___________________________________________________
10. Verify domain 0 is running Solaris. Record the command used:
Command:___________________________________________________
11. Reserve XSB 00-1 for detachment. Record the command used:
Command:___________________________________________________
12. Did the reserve of XSB 00-1 succeed? Record the command used to
verify the reservation:
Command:___________________________________________________
13. Remove XSB 00-1 from domain 0 and assign XSB 00-1 to domain 1
without halting Solaris. Record the command used:
Command:___________________________________________________
14. Verify XSB 00-0 and 00-1 are assigned to two different domains.
Command:___________________________________________________
15. Remove XSB 00-1 from domain 1 and configure XSB 00-1 into
Command:___________________________________________________
16. Verify XSB 00-0 and 00-1 are assigned to the same domain. Record
the command used:
Command:___________________________________________________

Exercise Summary
Exercise Summary

!
?
Experiences
Interpretations
Conclusions
Applications

Exercise Solutions
Exercise Solutions
This section contains solutions for the exercise.
Task 1 - Performing Dynamic Reconfiguration

3. Add an LSB# of 0 to XSB 00-0 and an LSB# of 1 to XSB 00-1 for
Command: setdcl -d 0 -a 0=00-0 1=00-1
used:
5. Assign XSB 00-0 and XSB 00-1 to domain 0. Record the command
used:
Command: addboard -d 0 -c assign 00-0 00-1
command used:
Command: boot
used:
Command: #.
10. Verify domain 0 is running Solaris. Record the command used:
Command: showdomainstatus -a, showdevices -d 0, showboards -a

Exercise Solutions
11. Reserve XSB 00-1 for detachment. Record the command used:
Command: deleteboard -c reserve 00-1
12. Did the reserve of XSB 00-1 succeed? Record the command used to
verify the reservation:
Command: showboards -av
13. Remove XSB 00-1 from domain 0 and assign XSB 00-1 to domain 1
without halting Solaris. Record the command used:
and
or
Command: moveboard -d 1 -c assign 00-1
14. Verify XSB 00-0 and 00-1 are assigned to two different domains.
15. Remove XSB 00-1 from domain 1 and configure XSB 00-1 into
and
Command: addboard -d 0 -c configure 00-1
or
Command: moveboard -d 0 -c configure 00-1
16. Verify XSB 00-0 and 00-1 are assigned to the same domain. Record
the command used:

Exercise Solutions

Objectives
Module 7
Data Collection and Fault Analysis
Objectives
Configure log archiving for the service processor
Collect log data for the service processor
Configure auditing for the service processor
Collect audit data for the service processor
Collect log and audit data using the snapshot command
View logs on the service processor
Collect fault data from the service processor
List current FRU replacement guidelines
Use Sun Explorer scripts to gather domain information
Data Collection and Fault Analysis 7-1

Objectives
Relevance

data collection and fault analysis are all about:
!
?
How can service processor logs be saved to a remote server?
What is the audit process?
How can audit logs be viewed?
How do you collect log and audit data?
Which logs are available on the MX000 servers?
Which commands are available to gather fault data on the service
processor?
How do the MX000 servers implement fault management?


5872-xx.
number 819-3601-xx.


http://docs.sun.com

Log Archiving Functionality

The persistent storage space on the service processor is limited. A portion
of this space is set aside for logs, such as audit logs and error logs. Due to
the limited space, some logs can grow to the point where old log entries
must be overwritten or deleted to make space for new logs.
Basic Features
Log archiving provides the following features:
Provides a remote archive host to be used as a backing store for
service processor logs
When enabled, copies existing log data to the archive host
Continuously archives new log data
Encrypts all connections established between the service processor
and archive host
Archived Data Types

Log archiving provides logging for the following data:
Audit trails
Fault manager fault and error logs
XSCF error log and event logs
Power logs and thermal history
Domain console logs
Hardware state dumps

Log Archiving Functional Overview

By default, log archiving is disabled. To use log archiving, you must
configure an archive host, and then enable log archiving on the service
processor.
When enabled, log archiving periodically uses the secure copy program
(scp) to transfer new log data to the archive host. Log archiving also uses
secure shell (ssh) to monitor the disk space consumed by archives. It
deletes older archives when necessary, so that the space consumed by the
archives never exceeds the user-configurable archive space limits.
Note For security reasons, log archiving does not automatically delete
audit log archives. You can, however, still manually delete audit log
archives that are no longer needed.
Encryption
All connections established through log archiving are encrypted. The log
archiving feature provides the ability to use an RSA public key to
authenticate the archive host. The public key is configured and managed

Configuring Log Archiving

The following two commands are used to perform the log archiving task:
setarchiving
showarchiving
The setarchiving Command

The setarchiving command configures the log archiving functionality of
the MX000 servers. This command requires platadm privileges to
execute.
The syntax for the setarchiving command is:

setarchiving [-h]
setarchiving enable | disable
setarchiving [-k host-key] [-l audit-limit,non-audit-
limit] [-p password|-r] [-t user@host:directory] [-v]
[-y|-n]
The options and parameters for the setarchiving command are:

enable | Enables or disables log archiving
disable
-k host-key Sets the public key that XSCF uses to verify the
identity of the host. Possible values are:
none Do not use a public key
download Use ssh to download the key
public-key Uses the entered ssh public key

-l Sets the space limits for log archives in megabytes.

audit-limit, The argument must consist of two values separated
non-audit- by a comma. Valid values are zero (the default) for
limit unlimited size or any integer between 500 and
50000.
audit-limit specifies the size for audit logs.
non-audit-limit specifies the size for other logs.
-p password Sets the password used for ssh login. This option is
provided to facilitate scripting. To change the
password interactively, use the -r option.
-r Reads the password used for ssh login. The
setarchiving command displays a prompt and
reads the new password without echoing it to the
screen.
-t Sets the archive target. The user field specifies the
user@host:di user name for the ssh login to the archive host. The
rectory host field specifies the host name or IP address of
the archive host. The directory field specifies the
archive directory on the archive host where the
archives should be stored.
-y | -n Automatically answers yes or no to all prompts.
The following example sets the archiving target system, requests a

password for the user sam, and requests an ssh key download.
XSCF> setarchiving -t sam@10.6.15.50:/export/home/sam/logs -r -k download
Downloading public host key from 10.6.15.50...
Fingerprint: e9:31:41:b8:6e:d6:d1:a2:da:89:bb:79:9c:79:24:e5
Accept this public key (yes/no)? yes
Enter ssh password for sam@10.6.15.50: cangetin
The following example enables log archiving.

XSCF> setarchiving enable
The following example disables log archiving.

XSCF> setarchiving disable

The showarchiving Command

The showarchiving command displays the log archiving configuration
and status. This command requires platadm, platop, or fieldeng
The syntax for the showarchiving command is:

showarchiving
showarchiving [-e] [-v]
setarchiving [-h]
The options and parameters for the showarchiving command are:

-e Displays information regarding the last 10 errors
-v Displays verbose output
The following example displays the current archiving configuration.

XSCF> showarchiving
*** Archiving Configuration ***
Archiving state ---------- Disabled
Archive host ------------- 10.6.15.50
Archive directory -------- /export/home/sam/logs
User name for ssh login -- sam
Archive host fingerprint -
e9:31:41:b8:6e:d6:d1:a2:da:89:bb:79:9c:79:24:e5
*** Connection to Archive Host ***

Latest communication ----- None
Connection status -------- None
AUDIT LOGS OTHER LOGS
---------- ----------
Archive space limit Unlimited 2000 MB
Archive space used Not monitored Not monitored
Total archiving failures 0 0
Unresolved failures 0 0

Log Archiving Task Summary

This section provides a summary of the tasks required to manage the log
archiving functionality of the MX000 servers, including:
Configuring the log host
Enabling log archiving
Disable log archiving
Displaying log archiving configuration and status
Displaying log archiving error details
Configure the Log Archive Host

To configure the log archive host, complete the following steps:
1. Select a user account on a server that will be used as the archive host
that the service processor will use to log to.
2. Log in to the archive host and create an archive directory.
3. Set the permissions of the archive directory as desired. The service
processor login account must have read, write, and execute (rwx)
permissions.
Configuring the Log Archive host
The following screen output shows the configuration of a Log Archive

Host.
# ifconfig -a (10.6.15.50)
# mkdir -p /export/home
# useradd -u 5001 -g 10 -d /export/home/sam -m -s /bin/ksh sam
# passwd sam (cangetin)
# mkdir /export/home/sam/logs
# chmod 777 /export/home/sam/logs
# chown sam:staff /export/home/sam/logs

Enabling Service Processor Log Archiving
To enable log archiving, complete the following steps:

1. Log in to the service processor with a user account that has platadm
privileges.
2. Execute the setarchiving command:
XSCF> setarchiving -t sam@10.6.15.50:/export/home/sam/logs -r -k download
Downloading public host key from 10.6.15.50...
Fingerprint: e9:31:41:b8:6e:d6:d1:a2:da:89:bb:79:9c:79:24:e5
Accept this public key (yes/no)? yes
Enter ssh password for sam@10.6.15.50: cangetin
3. Enable archiving using the following command:
XSCF> setarchiving enable
Note After tests indicate that the archive host is set up correctly, log
archiving is enabled effective immediately. If the tests fail, you receive an
error message that log archiving was not enabled.
Disabling Log Archiving
To disable log archiving, complete the following steps:

1. Disable archiving using the following command:
XSCF> setarchiving disable
Displaying Log Archiving Configuration and Status
To display log archiving configuration status, complete the following

steps:
1. View the configuration using the following command:
XSCF> showarchiving
Displaying Log Archiving Error Details
To display log archiving errors, complete the following steps:

1. List the archiving errors using the following command:
XSCF> showarchiving -e

Auditing
Auditing
An MX000 server logs all service processor events that could be relevant
to security, such as system startup and shutdown, user login and logout,
and privilege changes. These events are tracked and implemented
through:
Audit records
Audit trails
Audit events
Audit classes
Audit policy
Audit Records
Audit files are stored in binary format, although you can export them to
XML. The audit file system switches storage between two partitions.
Audit records are stored in one partition until it becomes full, then new
records are stored in the other partition. Records in a full partition can be
moved to a remote location, depending on the audit policy.
If audit policy or network problems impede remote storage, the system

generates an alarm. You can clear space by manually transferring the files
to remote storage or by deleting them. Until you clear space, new records
are dropped.
Audit Trails
A collection of audit records that are linked is called an audit trail. An
audit trail can reveal suspicious or abnormal patterns of system behavior,
in addition to identifying which user was responsible for a particular
event.

Auditing
Audit Events
Audit events can be any of the following types:
Changes to the service processor configuration, such as the IP
address
Requests to perform an operation on an object protected by the
access control policy
Tests of password strength
Modifications to the access control attributes associated with an
object for example, which domain a board is associated with
Changes made to user security attributes for example, password or
privileges
Reading information from the audit records (including unsuccessful
attempts)
Modifications to the audit policy
Actions taken caused by exceeding the audit trail size threshold
Actions taken due to audit storage failure
Modifications made by administrators to the audit trail
Changes to the system time
Recorded Data
The data recorded for each event includes:

Date and time of the event
Type of event
Who caused the event
Outcome of the event (success or failure)

Auditing
Audit Classes
Audit classes are categories for grouping and sorting audit events. The
MX000 servers provide a predefined set of audit classes for example,
login events and service-related events. You cannot define additional
audit classes or change the events in a class.
Note Refer to the setaudit man page for a list of audit classes.
Audit Policy
The audit policy determines how the auditing feature is implemented by
configuring the follows variables:
Whether auditing is enabled or disabled
The types of events that are audited
Which users have their events audited
Which remote directories are used for storing audit records
The threshold of local capacity at which a warning is issued
What action to take when both audit partitions are full
Default Audit Policy
The default audit policy that is configured on the service processor is:
Auditing is enabled.
Records are dropped and counted when the audit trail is full.
All events are enabled for auditing.
The global user audit policy is enabled.
Per-user audit policy for all users is enabled.
Audit warning thresholds are set at 80 percent and 100 percent full.
Email warnings are disabled.

Performing Audit Tasks

The audit functionality of the service processor is configured and
managed using the following commands:
setaudit
showaudit
viewaudit
The setaudit Command

The setaudit command manages the collection of security-related data
regarding the use of system resources. This data can be used to assign
responsibility for actions that have taken place on the system. This
command requires auditadm privileges to execute.
The syntax for the setaudit command is:

setaudit enable|disable|archive|delete
setaudit [-a users=enable|disable|default]
setaudit [-c classes= {enable|disable}]
setaudit [-e events=enable|disable]
setaudit [-g {enable|disable}] [-t thresholds]
setaudit [-p count|suspend] [-m mail-address]
setaudit -h
The options and parameters for the setaudit command are:
enable|disable Turns on or off the recording of audit records.

archive Archives the current audit trail.
delete Deletes the portion of the audit trail located in the
secondary partition, typically to save space.
default When set to default, the policy for the user is set to
follow the global policy.
-a user Sets the audit record generation policy for the
specified users, where user is a valid username.

-c classes Changes the audit record generation policy for the

specified audit classes. classes is a comma-
separated list of audit classes. The valid classes are:
ACS_LOGIN, ACS_AUDIT, ACS_DOMAIN, ACS_USER,

ACS_SYSTEM,ACS_WRITE,ACS_READ,ACS_MODES
, ACS_PLATFORM
all Specifies all classes.
-e events Changes the audit record generation policy for the
specified audit events. events is a comma-
separated list of audit events.
See showaudit -e all for a list of valid events.

-g Sets the global user audit record generation policy.
These settings can be overridden on an individual
user basis using the -a option.
-m mail- Specifies the address where email is sent when the
address local audit storage space usage reaches a threshold.
Specifying none for mail-address turns off email
notification.
-p suspend Sets the policy so all processes that try to write to
audit records are suspended until either space
becomes available and records can be written, or the
policy is changed to count.
-p count Sets the policy so new audit records are dropped

and a count is kept of how many records are
dropped.
-t thresholds Sets the thresholds for issuing a warning about local
audit storage usage. percents is a comma-
separated list of percentages of available space
used. At most, two values may be set. For example,
a value of 50, 75 would cause warnings to be
issued when 50 percent and 75 percent of the
available storage for audit records is consumed. The
default value is 80 percent.

The following example enables auditing:

XSCF> setaudit enable
Turns on writing of the audit records for the audit
trail.
The following example enables and disables events:

XSCF> setaudit -e ENTER,EXIT=disable -e LOGOUT=enable
Auditing for Enter and EXIT events has been disabled.
Auditing for LOGOUT is enabled.
The following example changes the audit recording for various classes:
XSCF> setaudit -c LOGIN,AUDIT=disable
Auditing for LOGIN and AUDIT classes has been disabled.
The following example sets the warning thresholds:

XSCF> setaudit -t 50,75
Warnings will be sent at 50% capacity and 75% capacity.

The showaudit Command

The showaudit command displays the log archiving configuration and
status. This command requires auditadm, auditop, or escalation
The syntax for the showaudit command is:

showaudit
showaudit [all]
showaudit [-a users] [-c classes] [-e events] [-g] [-m]
showaudit [-p] [-s] [-t]
showaudit -h
The options and parameters for the showaudit command are:
all Displays all current audit information.

-a user Displays the audit record generation policy for the
specified users.
-c classes Displays the audit record generation policy for the
specified audit classes. classes is a comma-
separated list of audit classes. The valid classes are:
LOGIN, CONFIG, AUDIT, DOMAIN, USER, STATUS,

PLATFORM, SERVICE
all Specifies all classes.
-e events Displays the audit record-generation policy for the
specified audit events. events is a comma-
separated list of audit events.
-g Displays the global audit record generation policy.
-m Specifies the address where email is sent when a
storage threshold is reached.
-p Displays the policy to follow when the audit trail
reaches full capacity.

-s Displays the following auditing information:

Space consumed by local audit records.
Free space remaining for local audit records.
Number of audit records dropped (since the last
boot) since the audit trail reached full capacity.
-t Displays the thresholds at which to issue warning(s)
about local storage usage.
The following example displays the current audit status:

XSCF> showaudit
Auditing: enabled
The following example displays class information for login auditing:

XSCF> showaudit -c LOGIN
Events:
AEV_LOGIN_BUI enabled
AEV_LOGIN_CONSOLE enabled
AEV_LOGIN_SSH enabled
AEV_LOGIN_TELNET enabled
AEV_LOGOUT enabled
AEV_AUTHENTICATE enabled
AEV_PASSWORD_CHANGE enabled
The following example displays the status for all events:

XSCF> showaudit -e all
Events:
AEV_AUDIT_START enabled
AEV_AUDIT_STOP enabled
AEV_ENTER_MODE enabled
AEV_EXIT_MODE enabled
AEV_LOGIN_BUI enabled
AEV_LOGIN_CONSOLE enabled
AEV_LOGIN_SSH enabled
...

The viewaudit Command

The viewaudit command displays audit records. When invoked without
options, viewaudit displays all current local audit records. When
invoked with options, viewaudit displays only the selected records. By
default, records are displayed in text format, one token per line, with a
comma as the field separator. This command requires auditadm or
auditop privileges to execute.
The syntax for the viewaudit command is:

viewaudit
viewaudit [-A date-time] [-B date-time] [-C]
viewaudit [-c classes][-D date-time] [-E end-record]
viewaudit [-e events] [-i audit-ids]
viewaudit [-l] [-m del] [-n] [-p privilege-results]
viewaudit [-r return-values] [-u users] [-x]
viewaudit -h
The options and parameters for the viewaudit command are:
-A date-time Displays records that occurred at or after date-

time.
Values are in absolute format:
yyyymmdd[hh[mm[ss]]]
where:
yyyy = year (1970 is the earliest valid value)
mm = month (0112)
dd = day (0131)
hh = hour (0023)
mm = minutes (0059)
ss = seconds (0059)
The default is 00 for hh, mm, and ss.
-C Appends the number of records that matched the
selection criteria to the end of the output.

-c classes Displays the audit record-generation policy for the

specified audit classes.
-D date-time Displays records that occurred on a specific day
(a 24-hour period beginning at 00:00:00 and ending
at 23:59:59).
-B date-time Displays records that occurred before date-time.
The -A and -B options can be used together to form
a range. Valid values: +n d|h|m|s
where:
n = number of units
d = days
h = hours
m = minutes
s = seconds
Offset is only available with the -B option and only
when used with -A because the offset is based on
the absolute value from -A.
-E end-record Selects the last record matching the selection criteria
to display.
-e events Displays records of the indicated events.
-l Prints one line per record.
-n Specifies that UIDs and IP addresses should not be
converted to user names or host names.
-p priv-result Displays records according to the indicated
privilege results. Valid values: granted, denied, or
error.
-r return- Displays records according to the indicated return
value values. Valid values: success, or failure.
-u users Displays records attributed to indicated users.
-x Prints in XML format.

The following example displays audit records for February 19, 2009:
XSCF> viewaudit -D 20090219
file,1,2009-02-19 11:12:24.528 -04:00,20090219151224.0000000000.kong-sp0
The following example displays user audit records for a user named sam:
XSCF> viewaudit -u sam
file,1,2009-02-19 11:12:24.528 -05:00,20090219151224.0000000000.kong-sp0
header,37,1,login - telnet,kong-sp0,2009-02-19 11:31:09.659 -05:00
subject,1,sam,normal,ssh 45880 kong-sp0
command,showuser
platform access,granted
return,0
The following example displays audit records for granted privileges:

XSCF> viewaudit -p granted
file,1,2009-02-19 11:12:24.528 -05:00,20090219151224.0000000000.kong-sp0
header,37,1,login - telnet,kong-sp0,2009-02-19 11:31:09.659 -05:00
command,showuser
return,0
The following example displays audit records between the dates of

January 12, 2009 and January 14, 2009:
XSCF> viewaudit -A 20090112 -B +2d
file,1,2009-01-12 16:11:52.785 -05:00,20090112155230.0000000000.kong-sp0
header,56,1,command - showldap,kong-sp0,2009-01-13 21:15:12.416 -05:00
subject,4,sam,normal,telnet 51409 sun.com
command,showldap
return,0

Audit Task Summary

This section provides a summary of the tasks required to manage the
audit functionality of the MX000 servers, including
Enabling or disabling writing of audit records to the audit trail
Configuring an auditing policy
Displaying whether auditing is enabled or disabled
Displaying current auditing policies, classes, or events
Enabling or Disabling the Writing of Audit Records
To enable or disable the writing of audit records:

1. Log in to the XSCF console with a user that has auditadm privileges.
2. Type the appropriate setaudit command:
XSCF> setaudit enable
XSCF> setaudit disable
Configuring an Auditing Policy
To configure an auditing policy:

1. Log in to the XSCF console with a user that has auditadm privileges.
2. Type the setaudit command supplying the required arguments and
options:
XSCF> setaudit -a sam=enable -c LOGIN=enable -g enable
3. Verify the operation with the showaudit all command:
XSCF> showaudit all
Displaying Whether Auditing Is Enabled or Disabled
To display whether auditing is enabled or disabled:

1. Log in to the XSCF console with auditadm privileges.
2. Type the showaudit command:
XSCF> showaudit
Auditing: enabled

Displaying the Current Auditing Policy
To display the current auditing policy:

1. Log in to the XSCF console with auditadm privileges.
2. Type the showaudit all command:
XSCF> showaudit all

The snapshot Command

The snapshot command provides a data-collection mechanism that
enables rapid, reliable, and flexible retrieval of the following diagnostic
information from the service processor:
Configuration information
Environmental status
Log files
Errors
FRUID information
The syntax for the snapshot command is:

snapshot -d usb-device [-r] [-e [-P encryption-
password]] [-L{F|I|R}] [-l] [-v] [ [-q] -{y|n}] [-S
time [-E time]]
snapshot -t user@host: directory [-e [-P encryption-

password]] [-k host-key] [-l] [-L{F|I|R}] [-p password]
[-v] [ [-q] -{y|n}] [-S time [-E time]]
snapshot -T [-D directory] [-e [-P encryption-

password]] [-k host-key] [-l] [-L{F|I|R}] [-v] [ [-q] -
{y|n}] [-S time [-E time]]
snapshot -h


The options and parameters for the snapshot command are:
-d device Specifies the external media device to use.

-D directory Used with the -T option, specifies a value for
directory instead of the value set using
setarchiving.
-e Encrypts the zip archive. Required when using -P
password.
-E Time Specifies the end time for which data is collected.
Used with the -S time option for the start time, this
option defines the period of time for which log
messages are collected.
-h Displays the command usage statement.
-k host-key Used with the -t or -T option, sets the public key
that the service processor uses to log in to the
network host. Valid values for host-key are:
none Specifies that a public key should

not be used to authenticate the network host.
download Specifies that snapshot will use ssh
to download a public host key for the network
host and download the key from the host
specified in the -t argument.
public Specifies using the supplied public key
for server authentication. The public key should
be enclosed in quotes to ensure that the shell
treats it as a single word.
-L {F|I|R} Specifies which set of logs will be collected:
F Full log set
I Initial log set
R Root cause log set
If no log set is specified, the Initial log set is
collected by default.

-l Specifies to collect only log files. Does not collect

command output.
-n Automatically answers no to all prompts.
-p password Used with the -e option, sets the encryption
password. Used with the -t option, specifies the
user password used to log in to the host using ssh.
prompts.
-s time Specifies the start time for which data is collected.
Used with the -E time option for the end time,
defines the period of time for which log messages
are collected by the snapshot command.
-t user@host: Sets the network host and remote directory
directory destination.
The host field specifies the host name or IP
address of the network host.
The user field specifies the user name for the
ssh login to the archive host.
The directory field specifies the archive
directory on the archive host where the output
file should be stored.
-T Executes in ssh target mode. Defaults to using the
user value set in setarchiving.
-v Verbose output. Displays all actions and commands
as they are executed.
-y Automatically answers yes to all prompts.

The snapshot command transfers collected data to a specified
destination. This is done by:
1. Opening an output file, the name of which is automatically
generated based on the service processor host name, service
processor IP address, and the UTC time (in hours, minutes, and
seconds) and date at the time the snapshot is invoked. For example:
kong-sp0_10.6.15.41_2009-01-31T01-08-36.zip
Note The snapshot command does not support user-specified file

names for the output file.
2. As files and command output are collected from the service

processor, snapshot compresses the output data and writes it in the
format of a .zip archive.
3. The collected data is then stored on a remote host or on an external
media device, based upon the use of the -t, -T, or -d options.
4. When storing data on a remote host, snapshot opens a network
connection using ssh to act as a data pipe to the remote file. It is
possible to restrict data collection on some larger log files to a
specific date range using the options -S and -E.
5. Optionally, the data is encrypted using network protocols, such as
ssh and ssl. The entire .zip archive itself can be encrypted using
the -e option.

Modes of Operation
The snapshot command can be operated in one of the following modes:
SSH target mode
USB device mode
SSH Target Mode
The first mode is SSH target mode. The data collector runs in this mode
when it is invoked with the -t or -T option. In this mode, the data
collector opens an SSH connection from the service processor to the
specified target (after appropriate authentication) and sends the zipped
data archive through the SSH connection to the target host. The
transmission encryption in this mode is provided by SSH.
USB Device Mode
The second mode is USB device mode. The data collector runs in this
mode when it is invoked with the -d flag. In this mode, the data
collectors output (which is the zip archive) is saved in a file on a USB
device. No transmission encryption occurs in this mode because the data
stays local to the service processor.


The following example downloads the snapshot using a public key
through SSH and specifies the remote host:
XSCF> snapshot -t sam@10.6.15.50:/export/home/sam/logs -r
Enter ssh password for user sam on host 10.6.15.50
Setting up ssh connection to remote host...
Collecting data into sam@10.6.15.50:/export/home/sam/logs/kong-
sp0_10.6.15.41_2009-01-31T01-08-36.zip
Data collection complete.
The following example downloads a snapshot using the remote host

values specified in the setarchiving command:
XSCF> snapshot -T
Collecting data into sam@10.6.15.50:/export/home/sam/logs/kong-
sp0_10.6.15.41_2009-01-31T01-08-36.zip
The following example logs files only, using no public key:

XSCF> snapshot -t gary@10.6.15.50:/export/home/gary/logs -k none -l
Enter ssh password for user gary on host 10.6.15.50
Log only mode. No commands will be collected.
Collecting data into gary@10.6.15.50:/export/home/gary/logs/kong-
sp0_10.6.15.41_2009-01-31T01-08-36.zip
The following example stores the snapshot on a USB device:

XSCF> snapshot -d usb0
Testing writability of USB device....SUCCESS
Collecting data into /media/usb_msd/kong-sp0_10.6.15.41_2009-01-31T01-
08-36.zip

Viewing Raw Snapshot Data

If need be, the various data files collected by the snapshot command can
be viewed by executing the strings command against the desired file.
The output displays the captured data and the commands used to gather
the data, but does not provide any timestamps and is not formatted.
The information that is stored in the snapshot is organized into the

following directory structure.
# ls kong-sp0_10.6.15.41_2009-01-31T01-08-36
CONFIG README spos_logs xscf_db
rci spos_info xscf_command xscf_logs
An example of executing the strings command against one of the files in

the xscf_command directory structure follows:
# cd /export/home/sam/logs/kong-sp0_10.6.15.41_2009-01-31T01-08-36
# strings xscf_command/*version_-c_xcp_-v.out
XSCF#0 (Active )
XSCF : 01.08.0004
XSCF : 01.08.0004
OpenBoot PROM BACKUP
#0: 02.08.0000
#1: 02.07.0000

Viewing and Monitoring Logs

This section provides information regarding commands that can be used
to gather additional platform information. These commands are:
showlogs
showmonitorlog
The showlogs Command

The showlogs command displays the contents of the specified log file.
The output is displayed using a timestamp, starting with the oldest date.
Table 7-1 lists the available log types and the privileges required to view
them:
Table 7-1 Privileges Required for the showlogs Command
Log Privileges Required

Log Data Displayed
Keyword (Only One Is Required)
error Error log platadm, platop,

fieldeng
event Event log platadm, platop,
fieldeng
monitor Monitor messages log platadm, platop,
fieldeng
power Power messages log platadm, platop,
fieldeng
env Temperature and humidity platadm, platop,
log fieldeng
console Console messages log platadm, platop,
fieldeng domainadm,
domainop, domainmgr
ipl IPL (Initialization Process platadm, platop,
Log) messages log fieldeng domainadm,
domainop, domainmgr
panic Panic messages log platadm, platop,
fieldeng domainadm,
domainop, domainmgr

The syntax for the showlogs command is:

showlogs [-t time [-T time] | -p timestamp] [-v|-V |-S] [-r] [-M] error
showlogs [-t time [-T time]|-p timestamp] [-v] [-r] [-M] event
showlogs [-t time [-T time]] [-r] [-M] {power | env}
showlogs [-r] [-M] monitor
showlogs -d domain_id [-t time [-T time]] [-r] [-M] {console|ipl|panic}
showlogs -h
The options and parameters for the showlogs command are:
-d domain-id Specifies the domain to be displayed.

-h Displays the command usage statement.
-M Displays output page by page. Similar to the more
command.
-p time-stamp Displays log data for the specified date and time.
-r Displays logs using reverse timestamp order,
showing the latest timestamp first.
-s Displays any scan logs associated with an error log.
-t time Specifies the start date and time of the display range
for log data.
-T time Specifies the end date and time of the display range
for log data.
-v Displays detailed log data for either error or event
logs, including fmadm and fmdump data.
-V Displays very detailed log data for error logs,
including OBP console log data. This option cannot
be combined with the -s or -v options.

The following example displays an error log:

XSCF> showlogs error
Date: Feb 22 06:41:07 EST 2009 Code: 40000000-c201faff-
011d001100000000
Status: Information Occurred: Feb 22 06:40:58.892 EST 2009
FRU: /XSCFU,/FIRMWARE
Msg: XSCF panic detected
Date: Feb 22 11:50:46 EST 2009 Code: 60000500-ffff0000-
0300000800030000
Status: Warning Occurred: Feb 22 11:50:45.621 EST 2009
FRU: /UNSPECIFIED
Msg: Externally initiated reset occurred
The following example displays an error log in detail for the times of the
specified timestamp (-v).
XSCF> showlogs error -p Feb2211:50:462009 -v
Date: Feb 22 11:50:46 EST 2009 Code: 60000500-ffff0000-
0300000800030000
Status: Warning Occurred: Feb 22 11:50:45.621 EST 2009
FRU: /UNSPECIFIED
Msg: Externally initiated reset occurred
Diagnostic Code:
ffffffff ffff0000 00000000
58495200 00000000 00000000 00000000
00000000 00000000 00000000 00000000
UUID: 2aa9e7b7-ed1c-44eb-ba93-9d7ba1f2c6fd MSG-ID: SCF-8000-P5
The following example displays a power log:

XSCF> showlogs power
Date Event Cause DID Switch
Feb 22 11:30:44 EST 2009 SCF Reset Power On -- Locked
Feb 22 11:40:11 EST 2009 System Power On Operator -- Locked
Feb 22 11:40:51 EST 2009 Domain Power On Operator 00 Locked
Feb 22 11:50:36 EST 2009 XIR Operator 00 Locked
Feb 22 11:50:59 EST 2009 Domain Reset SW Request 00 Locked

The following example displays a power log for the date range for
February 22, 2009 from 1:26 PM to 1:27 PM:
XSCF> showlogs power -t Feb2213:26:162009 -T Feb2213:27:102009

Date Event Cause DID Switch
Feb 22 13:26:16 EST 2009 Domain Power Off SW Request 00 Locked
Feb 22 13:27:10 EST 2009 System Power Off SW Request -- Locked
The following example displays a console message log for domain ID 0:

XSCF> showlogs console -d 00
DomainID:00
<output omitted>
Feb 22 13:26:06 EST 2009 kong-dom0 # poweroff
Feb 22 13:26:06 EST 2009 Feb 22 13:25:20 kong-dom0 poweroff:
poweroffed by root
Feb 22 13:26:06 EST 2009 Feb 22 13:25:20 kong-dom0 syslogd: going
down on signal 15
Feb 22 13:26:07 EST 2009 ip_create_dl: hw addr length = 0
Feb 22 13:26:12 EST 2009 syncing file systems... done
Feb 22 13:26:16 EST 2009

The showmonitorlog Command

The showmonitorlog command displays the contents of monitoring
messages in real time. When the showmonitorlog command is executed,
the XSCF shell is occupied for the display of monitoring messages. When
a monitoring message is registered, the contents of the message are
displayed to the screen.
Note To stop the real-time display, press the Ctrl + C key

combination.
You must have one of the following privileges to run this command:
platadm, platop, or fieldeng.
The syntax for the showmonitorlog command is:

showmonitorlog
showmonitorlog -h
The options and parameters for the showmonitorlog command are

limited to -h, which displays usage information.
The following example enables escalation mode:

XSCF> showmonitorlog
Apr 13 12:32:16 XXXXX Alarm: /CMU#1,/CMU#0/DDC#0:ANALYZE:SC-IOU I/F fatal
error 0x00000000;
:
: <Ctrl + C>
XSCF>

Fault Management Architecture

The MX000 servers feature the latest Fault Management Architecture
(FMA) technologies available within the Solaris 10 OS. As with previous
servers that use this technology, FMA diagnoses and predicts component
failures before they actually occur. This technology is incorporated into
both the hardware and software of the MX000 servers.
At the heart of Fault Manager is the diagnosis engine. The diagnosis

engine runs in the background, silently capturing telemetry until a
diagnosis can be completed or a fault can be predicted.
After processing sufficient telemetry to reach a conclusion, a diagnosis

engine produces another event, called a fault event, that is broadcast to
any agents deployed on the system that know how to respond. A
software component known as the Solaris Fault Manager, fmd, manages
the diagnosis engines and agents.
Service Processor Implementation

Sun has also ported the Solaris FMA to run on Linux for the service
processors. This port includes:
fmd The fault management daemon
eft The Eversholt Fault Tree diagnosis engine
fmadm, fmstat, fmdump, and fmtopo commands
etm The event transport module
prpicl, picld The Portable Instrumented Communications
Library (PICL) daemon (escalation mode only)
fruadm, prtfru The FRU utilities (escalation mode only)
Service Processor FMA Commands
The FMA implementation on the service processor includes the use of the
following commands to collect and view fault data:
fmadm Views and configures system parameters
fmdump Displays the list of faults detected by the FMA
fmstat Displays statistical information about faults

The fmd Daemon

The Solaris OS uses the Fault Manager daemon, fmd, which starts at boot
time and runs in the background to monitor the system. If a component
generates an error, the daemon handles the error by correlating it with
data from previous errors and other related information to diagnose the
problem.
Each problem diagnosed by Fault Manager is assigned a Universal

Unique Identifier (UUID). The UUID uniquely identifies the particular
problem across any set of systems. The fmdump utility can be used to view
the list of problems diagnosed by the fault manager, along with their
UUIDs and knowledge article message identifiers.
The fmadm utility can be used to view the resources on the system
believed to be faulty. The fmstat utility can be used to report statistics
kept by Fault Manager.
When possible, the Fault Manager daemon initiates steps to self-heal the
failed component and take the component offline. The daemon also logs
the fault to the syslog daemon and provides a fault notification with a
message ID (MSGID).
Note You can use the message ID to get additional information about
the problem from Sun's knowledge article database at:
http://www.sun.com/msg/

The fmadm Command

The fmadm command is used to view system configuration parameters
related to fault management, including:
Viewing the set of diagnosis engines and agents that are currently
participating in fault management
The syntax for the fmadm command is:

fmadm [-q] config
The options and parameters for the fmadm command are shown in
Table 7-2.
Table 7-2 fmadm options
config Displays Fault Manager configuration data,

including the module name, version, and
description of each component module. This is the
only option available in normal operating mode.
-q Sets quiet mode. Does not produce messages
indicating the result of successful operations to
standard output.
The following example displays the Fault Manager configuration:

XSCF> fmdadm config
MODULE VERSION STATUS DESCRIPTION
case-close 1.0 active Case-Close Agent
event-transport 2.0 active Event Transport Module
faultevent-post 1.0 active Gate Reaction Agent for errhandd
flush 1.10 active Resource Cache Flush Agent
fmd-self-diagnosis 1.0 active Fault Manager Self-Diagnosis
iox_agent 1.0 active IO Box Recovery Agent
reagent 1.19 active Reissue Agent
sde 1.16 active Simple Diagnosis Engine
snmp-trapgen 1.0 active SNMP Trap Generation Agent
sysevent-transport 1.0 active SysEvent Transport Agent
syslog-msgs 1.0 active Syslog Messaging Agent

The fmdump Command

The fmdump command displays the contents of any of the logs associated
with Fault Manager and maintains two sets of logs for use by
administrators and service personnel:
error log Records error telemetry, the symptoms of problems
detected by the system.
fault log Records fault diagnosis information, the problems
believed to explain these symptoms. By default, fmdump displays the
contents of the fault log, which records the result of each diagnosis
made by Fault Manager or one of its component modules.
Note You must have platop, platadm, or fieldeng privileges to

execute this command.
Each problem recorded in the fault log is identified by:

The time of its diagnosis
A Universal Unique Identifier (UUID) that can be used to uniquely
identify this particular problem across any set of systems
A message identifier (MSG-ID) that can be used to access a
corresponding knowledge article located at the specified web site
Note If a problem requires action by a human administrator or service

technician or affects system behavior, Fault Manager also issues a
message. This message provides a summary of the problem and a
reference to the knowledge article about the specified web site.
The syntax for the fmdump command is:

fmdump
fmdump [-e] [-f] [-M] [-v] [-V] [-c class] [-t time]
[-T time] [-u uuid]
fmdump -m [-M] [-t time] [-T time]
fmdump -h

The options and parameters for the fmdump command are:
-c class Selects events that match the specified class.

-e Displays events from the fault management error
log instead of the fault log.
-f Displays only lines that have been appended to the
dump file since the command was executed. Output
continues until interrupted by Ctrl-C.
-m Displays the Fault Manager syslog message
contents.
command.
-t time Selects events that occurred at or after the specified
time. If used with -T, specifies a range of times.
-T time Selects events that occurred at or before the
specified time. If used with -t, specifies a range of
times.
-u uuid Selects fault diagnosis events that exactly match the
specified uuid.
-v Displays verbose event detail. The event display is
enlarged to show additional common members of
the selected events.
-V Displays very verbose event detail. In addition to -v
output, for fault logs, the event display includes a
list of cross-references to the corresponding errors
that were associated with the diagnosis.

Maintenance Action Required Output
One of the keys to analyzing fmdump output is to look for the

maintenance-action-required (MAR) output. The maintenance-action-
required output is set to true when the diagnosis engine thinks the FRU is
actually faulty. This is also referred to as the certainly faulty flag (CFF) in
CMEM.
The maintenance-action-required (MAR) output is a good indicator of

whether to replace a FRU or not.
The following example displays the default command output:

XSCF> fmdump
TIME UUID MSG-ID
Feb 19 15:09:46.1524 13a2e58e-bb85-4d7c-ace2-976d8c5918b3 SCF-8005-NE
Feb 20 16:50:03.7707 b767065f-cd4f-4618-a8c3-dde8ed4368ad SCF-8006-YS
Feb 21 16:16:37.2591 f219212d-81dd-43be-b381-4e70954b3555 SCF-8006-YS
Feb 22 06:41:07.6650 1794e0ad-53b5-4412-8d6c-b7750092fad4 SCF-8006-YS
Feb 22 11:50:46.7130 2aa9e7b7-ed1c-44eb-ba93-9d7ba1f2c6fd SCF-8000-P5
From the fmdump output from above, consider the following:

How many errors have occurred in what time frame?
Are the error messages spread out over several weeks or months?
Are there several error messages in a short period of time?
How many different message ids are shown.
Investigate each message id to discover addition information about
the problem(s).
Are the error messages some how related?
Can you consider a course of action based on what additional
information you uncover?
Where else might you look for additional fault information?

showstatus
fmstat
fmdump -e
the domain or domains

Using the UUID to discover detailed fault information
The following example displays the fault report for the specified UUID.
Find the domain id number in the following output and notice the state of
the maintenance-action-required output:
XSCF> fmdump -V -u 2aa9e7b7-ed1c-44eb-ba93-9d7ba1f2c6fd
TIME UUID MSG-ID
Feb 22 11:50:46.7130 2aa9e7b7-ed1c-44eb-ba93-9d7ba1f2c6fd SCF-8000-P5
TIME CLASS ENA

Feb 22 11:50:46.5947 ereport.chassis.SPARC-Enterprise.cpu.SPARC64-
VI.fe-obp-err 0x152c1d2967200001
nvlist version: 0
version = 0x0
class = list.suspect
uuid = 2aa9e7b7-ed1c-44eb-ba93-9d7ba1f2c6fd
code = SCF-8000-P5
diag-time = 1203699046 712677
de = (embedded nvlist)
nvlist version: 0
version = 0x0
scheme = fmd
authority = (embedded nvlist)
nvlist version: 0
version = 0x0
product-id = SPARC Enterprise M5000
chassis-id = BCF0710015
server-id = kong-sp0
(end authority)
mod-name = sde
mod-version = 1.15
(end de)
fault-list-sz = 0x1
fault-list = (array of embedded nvlists)
(start fault-list[0])
nvlist version: 0
version = 0x0
class = upset.chassis.SPARC-Enterprise.cpu.SPARC64-VI.fe
certainty = 0x64
fru = (embedded nvlist)
nvlist version: 0
version = 0x0
scheme = hc
hc-root =

hc-list = (array of embedded nvlists)

(start hc-list[0])
nvlist version: 0
hc-name = component
hc-id = CHASSIS
(end hc-list[0])
hc-list-sz = 0x1
authority = (embedded nvlist)
nvlist version: 0
version = 0x0
product-id = SPARC Enterprise M5000
chassis-id = BCF0710015
server-id = kong-sp0
(end authority)
(end fru)
resource = (embedded nvlist)
nvlist version: 0
version = 0x0
scheme = hc
hc-root =
hc-list = (array of embedded nvlists)
(start hc-list[0])
nvlist version: 0
hc-name = chassis
hc-id = 0
(end hc-list[0])
(start hc-list[1])
nvlist version: 0
hc-name = domain
hc-id = 0
(end hc-list[1])
hc-list-sz = 0x2
(end resource)
scf_error_log = 0000000000000000
detected-by = OpenBoot PROM
maintenance-action-required = false
location = CHASSIS
(end fault-list[0])
fault-status = 0x0
__ttl = 0x1
__tod = 0x47befd66 0x2a7fa768

Viewing fmdump error messages when web access is not

available
The following example displays part of the contents of the MX000 Fault
Manager messages:
XSCF> fmdump -m -M
MSG-ID: SCF-8000-P5, TYPE: Upset, VER: 1, SEVERITY: Critical
EVENT-TIME: Fri Feb 22 11:50:46 EST 2009
PLATFORM: SPARC Enterprise M5000, CSN: BCF0710015, HOSTNAME: kong-sp0
SOURCE: sde, REV: 1.15
EVENT-ID: 2aa9e7b7-ed1c-44eb-ba93-9d7ba1f2c6fd
DESC: A hard-to-diagnose problem was detected by the CPU chip.
Refer to http://www.sun.com/msg/SCF-8000-P5 for more information.
AUTO-RESPONSE: Nothing is deconfigured.
IMPACT: The domain may drop to the OpenBoot PROM 'OK' prompt.
REC-ACTION: The platform administrator should check to see if any other
hardware failure has occurred on the platform.
If the problem occurs while running OpenBoot PROM, then the platform
administrator should check to make sure that
the OpenBoot PROM environment variables have not been set incorrectly. If
neither of these courses of action
provide a resolution, then the platform administrator should schedule a
service action.
Please consult the detail section of the knowledge article for additional
information.
The fmdump command with the -e (error) option is useful tool that will
show the error messages for problems that has occurred. The error
message itself might not be enough to determine the problem. The
timestamps from fmdump -e will match the timestamps from fmdump.
Use fmdump to discover the UUID and then run fmdump -v -u UUID
for detailed information.
XSCF> fmdump -e
TIME CLASS
Jan 30 18:32:46.2312 ereport.chassis.SPARC-Enterprise.xscfu.process-down
Jan 30 20:52:13.2032 ereport.chassis.SPARC-Enterprise.xscfu.process-down

The fmstat Command

The fmstat command reports statistics associated with Fault Manager
and its associated set of modules. If the -m option is present, fmstat
reports any statistics kept by the specified fault management module. The
module list can be obtained using fmadm config.
If the -m option is not present, fmstat reports the following statistics for
each of its client modules:
module The name of the fault management module as

reported by fmadm config.
ev_recv The number of telemetry events received.
ev_acpt The number of events accepted by the module as
relevant to a diagnosis.
wait The average number of telemetry events waiting to
be examined by the module.
svc_t The average service time for telemetry events
received by the module, in milliseconds.
%w The percentage of time that there were telemetry
events waiting to be examined by the module.
%b The percentage of time that the module was busy
processing telemetry events.
open The number of active cases (open problem
investigations) owned by the module.
solve The total number of cases solved by this module
since it was loaded.
memsz The amount of dynamic memory currently
allocated by this module.
bufsz The amount of persistent buffer space currently
allocated by this module.
Note You must have platop, platadm, or fieldeng privileges to

execute this command.

The syntax for the fmstat command is:

fmstat
fmstat [-a] [[-s] [-z] [-m module]] [interval [count]]
fmstat -h
The options and parameters for the fmstat command are:
-a Prints the default global statistics for Fault Manager

or a module.
-m module Prints a report about the statistics associated with
the specified fault management module, instead of
the default statistics report.
If used with the -a option, displays statistics kept

by the module and the global statistics associated
with the module.
-s Prints a report on Soft Error Rate Discrimination
(SERD) engines associated with the module instead
of the default module statistics report. A SERD
engine is a construct used by fault management
software to determine if a statistical threshold
measured as count events in some time interval
(counted in seconds) has been exceeded.
The -s option can only be used in combination with

the -m option.
-z Omits statistics with a zero value from the report
associated with the specified fault management
module.
The -z option can only be used in combination

with the -m option.
count Prints only count number of reports, and then exit.
interval Prints a new report every interval seconds.

The following example displays the default command output:

XSCF> fmstat
module ev_recv ev_acpt wait svc_t %w %b open solve memsz bufsz
case-close 0 0 0.0 0.0 0 0 0 0 0 0
emailprv 0 0 0.0 0.0 0 0 0 0 0 0
event-transport 0 0 0.0 0.0 0 0 0 0 5.8K 0
faultevent-post 0 0 0.0 0.0 0 0 0 0 0 0
flush 0 0 0.0 0.0 0 0 0 0 0 0
fmd-self-diagnosis 1 1 0.0 0.0 0 0 0 0 0 0
iox_agent 0 0 0.0 0.0 0 0 0 0 0 0
reagent 0 0 0.0 0.0 0 0 0 0 0 0
sde 0 0 0.0 0.0 0 0 0 0 162K 0
snmp-trapgen 0 0 0.0 0.0 0 0 0 0 0 0
sysevent-transport 0 0 0.0 2382.3 1 0 0 0 0 0
syslog-msgs 0 0 0.0 0.0 0 0 0 0 97b 0
The following example displays statistics for the self-diagnosis module.

The -z option omits any (ev_acpt) values that are set to zero for a self-
diagnosis module:
XSCF> fmstat -z -m fmd-self-diagnosis
NAME VALUE DESCRIPTION
module 1 error events received from fmd modules
Collecting Fault Data

When a fault occurs, use the following procedure to gather the
appropriate fault data:
1. Collect the fault message using fmdump -m.
2. Collect output from fmdump -v -u event-id.
3. Provide the data to an authorized service provider.

FRU Replacement Guidelines

The following guidelines are provided to aid a service engineer in
deciding the best choice of component (FRU) to be replaced based on
previously collected fault data.
Caution Always consult the latest product documentation and best

practices for updates to these guidelines.
One Suspected FRU
If there seems to be one suspected FRU based on the fault data collected:
If this is the first occurrence of the fault within a 30-day period, then
replace the first suspected FRU on the list.
If this is the second occurrence of the same fault within a 30-day
period, then check for additional information because there is a
slight probability of another faulty component contributing to this
fault.
If this is the second occurrence of the same fault after a 30-day
period, then replace the first suspect on the list.
Two or More Suspected FRUs
If there seems to be more than one suspected FRU based on the fault data
collected:
If this is the first occurrence of the fault within a 30-day period, then
replace the first suspect on the list.
If this is the second occurrence of the same fault within a 30-day
period, then replace the second suspect on the list.
If this is the third occurrence of the same fault within a 30-day
period, then replace the third suspect on the list if one exists, or
check for additional information because there is a slight probability
of another faulty component contributing to this fault.
If this is the second occurrence of the same fault after a 30-day
period, then replace the first suspect on the list.

Backing up service processor information

It is possible to create a backup of your service processor configuration
and store that information on a remote server. This information could be
used to restore an older configuration or to replicate many servers that
will have the same basic configuration.
The dumpconfig command
The dumpconfig command provides the ability to offline service

processor configuration data. Halt all domain activity prior to a
dumpconfig. An ftp server or http server can be used to hold the service
processor configuration information.
Note The dumpconfig command will not save service processor log
information.
The operation below uses an Anonymous ftp server at 10.6.15.50 to hold

the service processor configuration for kong-sp0. The backup file created
in the pub directory is called kong-sp0.backup. The Anonymous ftp
server at 10.6.15.50 has had its /etc/ftpd/ftpaccess file modified to
allow uploads into the pub directory.
XSCF> dumpconfig -V ftp://10.6.15.50/pub/kong-sp0.backup
transfer from '/tmp/dumpconfig.X57kvH' to 'ftp://10.6.15.50/pub/kong-
sp0.backup'
* About to connect() to 10.6.15.50 port 21
* Trying 10.6.15.50... * connected
* Connected to 10.6.15.50 (10.6.15.50) port 21
< 220 ssp0 FTP server ready.
> USER anonymous
< 331 Guest login ok, send your complete e-mail address as password.
> PASS curl_by_daniel@haxx.se
< 230 Guest login ok, access restrictions apply.
* We have successfully logged in
> PWD
< 257 "/" is current directory.
* Entry path is '/'
> CWD pub
< 250 CWD command successful.
> EPSV
< 229 Entering Extended Passive Mode (|||29036|)
* Connecting to 10.6.15.50 (10.6.15.50) port 29036

* Connected the data stream with PASV!

> TYPE I
< 200 Type set to I.
> STOR kong-sp0.backup
< 150 Opening BINARY mode data connection for kong-sp0.backup.
< 226 Transfer complete.
* Connection #0 to host 10.6.15.50 left intact
> QUIT
< 221-You have transferred 22240 bytes in 1 files.
< 221-Total traffic for this session was 22729 bytes in 1 transfers.
< 221-Thank you for using the FTP service on ssp0.
< 221 Goodbye.
* Closing connection #0
operation completed

Restoring service processor configuration information

Once a service processors configuration has been created with the
dumpconfig command, the saved configuration can be re-loaded on the
service processor with the restoreconfig command.
The restoreconfig command
The restoreconfig command provides the ability to restore service

processor configuration data using a saved configuration file. Halt all
domain activity prior to a restoreconfig.
Caution The following commands should not be done when local access
to the service processor is not possible.
Caution The instructor does not have remote power control to resolve
power issues.
Caution Running the following commands will END your lab for the
rest of the class.
The operation below retrieves a configuration backup file from the

Anonymous ftp server at 10.6.15.50. The configuration backup file created
with the dumpconfig command must have permissions of 777. The file
name is kong-sp0.backup and is found in the pub directory of the
Anonymous ftp server.
XSCF> restoreconfig -V ftp://10.6.15.50/pub/kong-sp0.backup
transfer from '/scf/firmtmp/hcp/config/config_file.bin' to
'ftp://10.6.15.50/pub/kong-sp0.backup'
* About to connect() to 10.6.15.50 port 21
* Connected to 10.6.15.50 (10.6.15.50) port 21
< 220 ssp0 FTP server ready.
> USER anonymous
< 331 Guest login ok, send your complete e-mail address as password.
> PASS curl_by_daniel@haxx.se
< 230 Guest login ok, access restrictions apply.
* We have successfully logged in
> PWD
< 257 "/" is current directory.
* Entry path is '/'

> CWD pub

< 250 CWD command successful.
> EPSV
< 229 Entering Extended Passive Mode (|||12525|)
* Connecting to 10.6.15.50 (10.6.15.50) port 12525
* Connected the data stream with PASV!
> TYPE I
< 200 Type set to I.
> SIZE kong-sp0.backup
< 213 22240
> RETR kong-sp0.backup
< 150 Opening BINARY mode data connection for kong-sp0.backup (22240
bytes).
* Getting file with size: 22240
< 226 Transfer complete.
* Connection #0 to host 10.6.15.50 left intact
> QUIT
< 221-You have transferred 22240 bytes in 1 files.
< 221-Total traffic for this session was 22774 bytes in 1 transfers.
< 221-Thank you for using the FTP service on ssp0.
< 221 Goodbye.
* Closing connection #0
Configuration backup created on Fri Jan 30 13:38:28 2009
from system 'M5000' with serial number 'BCF0710015', version
'10800000'
*** You will need to power-cycle the entire system after this operation
is completed
*** Do you want to restore this configuration to your system? [y|n]: n

Removing service processor information

At some point, you may want to clear all service processor log
information. Perhaps the server is being moved to another location and
you dont want any of the service processor logs to be viewed by a
different organization within your company. Maybe the server is being
decommissioned. In any case, it is possible to clear your old data.
Caution The following commands should not be done when local access
to the service processor is not possible.
Caution The instructor does not have remote power control to resolve
power issues.
Caution Running the following commands will END your lab for the
rest of the class.
The restoredefaults command
The restoredefaults command has two modes of operation.
The first mode, xscfu, allows for log, audit, and fault information to be
removed.
The second mode of operation, factory, returns the service processor to its
original unconfigured state. Log, audit, and fault information is removed
as well as any configuration for the service processor; this includes
network and domain information.
Caution Local access to power is required to recover from the

restoredefaults command. You dont have local access to power!
XSCF> restoredefaults -c xscfu

WARNING:
If this system does not have OPNL, this command will set all the user
settable XSCF configuration parameters to their default value as they
were set when the system was shipped out.
Furthermore, this command will delete all logs on both XSCFUs.
Check the man page of this command before you run it.
Continue?[yes/no](default no):no

You must check the following points.
1. Have the ability to power cycle the system.

2. Have access to the serial console and hold the serial console of the
XSCFU to confirm the completion of the command.
If you answer "yes" this command will HALT the XSCFU when it completes.
You will need to power cycle the system after the XSCF BOOT STOP.
Do you really want to continue?
The initialization of XSCF will be started.
XSCFU : all data clear
OPNL : not clear
XSCF will be automatically rebooted. Afterwards, XSCF will be
initialized.
XSCF> restoredefaults -c factory

WARNING:
If this system does not have OPNL, this command will set all the user
settable XSCF configuration parameters to their default value as they
were set when the system was shipped out.
Furthermore, this command will delete all logs on both XSCFUs.
Check the man page of this command before you run it.
You must check the following points.
1. Have the ability to power cycle the system.

2. Have access to the serial console and hold the serial console of the
XSCFU to confirm the completion of the command.
If you answer "yes" this command will HALT the XSCFU when it completes.
You will need to power cycle the system after the XSCF BOOT STOP.
Do you really want to continue?
The initialization of XSCF will be started.
XSCFU : all data clear
OPNL : all data clear (exclude SYSTEM ID data)
XSCF will be automatically rebooted. Afterwards, XSCF will be
initialized.

Collecting Data With Sun Explorer Software

Sun Explorer software is a collection of scripts that gather domain
information and then bundle it into a compressed file. The compressed
file is sent to Sun with customer approval, or the collected data can be
examined immediately. Using Sun Explorer software, you can determine
the configuration of a domain at a glance. Also, sending the Sun Explorer
outputs to Sun on a regular basis can aid problem solving, as Sun
personnel can determine what has changed.
Sun Explorer software provides the following capabilities:

Gathers extensive domain information
Generates tar.Z and email messages to the Sun database
Uses a lightweight shell script for less execution overhead
You can get Sun Explorer software through the SunSolveSM Online
service.

Installing and Running the Sun Explorer Utility

After downloading the compressed software package to your domain or
another server, use the following steps to install and run the Sun Explorer
utility:
1. Copy the Explorer_5.13.tar.gz file to the appropriate domain.
2. Log in to the domain as the superuser.
3. Uncompress the Sun Explorer software package, and extract the files.
# gzcat SunExplorer.tar.gz | tar xvf -
4. Add the Sun Explorer packages to the system.
# pkgadd -d . SUNWexplo SUNWexplu
Note One of the most important aspects of Sun Explorer software is the
proper entry of information during installation. Sun Explorer software
asks a series of questions about the system serial number, contract ID, and
company name. The answers to these questions should be entered
properly to avoid confusion.
5. Use the following command when running the Sun Explorer utility
for the first time in a domain:
# /opt/SUNWexplo/bin/explorer -g
6. Use the following command to run the Sun Explorer utility:
# /opt/SUNWexplo/bin/explorer -w default,xscfextended
Note This process places the snapshot in the /tmp directory of the
archive host.
Note The xscfextended option to Sun Explorer assumes that archiving

is set up and works.

Viewing a Sun Explorer Capture

The information gathered by Sun Explorer software is stored locally in the
/opt/SUNWexplo/output/ directory.
# ls -al /opt/SUNWexplo/output/explorer.843a9ae1.kong-dom0-
2009.02.23.06.17
total 28
-rw-r--r-- 1 root root 1725 Feb 23 01:21 README
-rw-r--r-- 1 root root 2034 Feb 23 01:21 defaults
drwxr-xr-x 2 root root 512 Feb 23 01:21 patch+pkg
-rw-r--r-- 1 root root 5 Feb 23 01:21 rev
-rw-r--r-- 1 root root 1423 Feb 23 01:17 service_tags.xml
drwxr-xr-x 4 root root 512 Feb 23 01:21 sysconfig
drwxr-xr-x 3 root root 512 Feb 23 01:17 xscf
The following example shows the contents of the README file found in the
Sun Explorer directory.
# cat README
=========== SUN(TM) EXPLORER DATA COLLECTOR (Version 5.13) ===========
=========== Patch level:
This directory contains system configuration information.

Information was gathered on Mon Feb 23 01:21:39 EST 2009.
Synopsis
========
Customer Name: Sun
Contract ID: Gary
Email results to: gary.r@sun.com
Subject: explorer.843a9ae1.kong-dom0-2009.02.23.06.17
Modules selected: default,xscfextended
Command Line: /opt/SUNWexplo/bin/explorer -w default,xscfextended
License Agreement: Sun Feb 22 20:08:11 GMT 2009
User Name: Gary

User e-mail: gary.r@sun.com
User Phone #:
System Serial number: BCF0710015

Address line 1: 1 Network Drive
Address line 2: Burlignton MA 01854
City: Burlington
State: MA
Country: United States
Zip Code: 01803
Country Code: US

The following info was collected using UNIX tools (hostname, arch, etc)
----------------------------------------------------------------------
Date: 2009.02.23.06.17
Finished: 2009.02.23.06.21
Hostname: kong-dom0
Hostid: 843a9ae1
Release: 5.10
Kernel architecture: sun4u
Application architecture: sparc
Domain:
Kernel version: SunOS 5.10 Generic 137137-09
System Type: SUNW,SPARC-Enterprise
Uptime: 1:17am up 9:28, 1 user, load average: 0.29, 0.06, 0.02
Swap-s:
total: 193656k bytes allocated + 30592k reserved = 224248k used, 31011808k
available
Swap-l:
swapfile dev swaplo blocks free
/dev/dsk/c0t0d0s1 32,1 16 34801904 34801904
Vmstat:
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr s0 s1 s3 s4 in sy cs us sy id
0 0 0 30689144 15284992 8 28 5 0 0 0 12 1 -0 1 0 337 174 129 0 0 100
#
Note For more detailed information regarding the use of Sun Explorer,
see the Sun Explorer Frequently Asked Questions located at:
http://docs.sun.com/app/docs/doc/819-6614

Gathering Escalation Information
Gathering Escalation Information

This section describes the technical information required to escalate a
problem.
Providing General Information

Review hardware and software system configuration information, and
keep the following outputs accessible for each domain:
The prtdiag output
The sysdef output
The patchadd -p output
Sun Explorer software output
Providing Detailed Information

Most, if not all of this information should be provided as part of the Sun
Explorer output:
Indicate the type of problem such as panic, watchdog, hard-hang,
disk error, and so on (if you can)
Indicate the severity of the problem, such as whether the system is
down or partially deconfigured
List all recent system changes, such as hardware, software, patches,
and new applications
Include all available domain logs
Include all available service processor logs (from showlogs)
Provide a copy of the domain /etc/system file
Provide any relevant error messages or core files

Exercise: Collecting Data and Viewing Logs

Configure log archiving
Configure auditing
Create a snapshot archive
View logs
Execute Sun Explorer scripts
Note This exercise has been written with the assumption that you have
remote access to an MX000 server.
Preparation
To complete this exercise, you need your assigned non-global zones
hostname and the network configuration.

Task 1 Configuring Log Archiving

In this task, you configure and manage log archiving. Complete the
following steps:
1. Log in to your assigned service processor with the userid user1.
2. View the current archiving status, and record the command used:
Command: __________________________________________
Archiving state: _______________________
Archive host: _________________________
Archive directory: _____________________
Username for ssh login: ________________
Connection status: _____________________
Archive space limit: ____________________
Archive space used: ____________________
4. Configure a non-global zone in your remote lab environment to act
as the archive host.
a. Log in to your non-global zone as the user root.
b. Verify the IP Address of the Non-Global zone. Record the
output and command used:
Non-Global zone IP Address:_____________________
Command:______________________________________
c. Create the /export/home directory if it doesnt exist. Record
the commands used:
Command:_______________________________________
d. Create a new user account on the archive host to use for logins
and assign the user a password. Record the commands used:
Command:_______________________________________
e. Create a new directory in the users home directory to contain
the service processor logs. Record the command used:
Command: _______________________________________
f. Set permissions on the newly created directory to allow full
access (777). Record the command used:
Command: _______________________________________

g. Change the ownership and group of the new directory to match

the ownership and group of the users home directory. Record
the command used:
Command: _______________________________________
5. Configure the archiving parameters on the service processor.

a. Log in to the service processor with the userid user1.
b. Disable log archiving. Record the command used:
Command: _______________________________________
c. Set the archive target, using your Non-Global zones IP
Address, the user created, and the directory created in Step 4:
Command: _______________________________________
6. View the updated archiving status, and record the command used:
Command: __________________________________________
Archiving state: _______________________
Archive host: _________________________
Archive directory: _____________________
Username for ssh login: ________________
Connection status: _____________________
Archive space limit: ____________________
Archive space used: ____________________
8. Enable log archiving. Record the command used:
Command: _______________________________________
9. Log back in to your Non-Global zone and verify if any files have
been created in the archive directory.

Task 2 Configuring Auditing

In this task, you configure and manage auditing on the service processor.
Complete the following steps:
2. Set the privileges for the user1 account to be platadm, fieldeng, and
useradm. Record the command used:
Command: ________________________________________
3. Display the current auditing policy. Record the command used:
Status: ______________ Command: _____________
4. If auditing is disabled, then enable it. If auditing is already enabled,
disable it, then re-enable it. Record the command(s) used:
Command: __________________________________________
Command: __________________________________________
5. Were you successful in executing the required commands to enable
auditing? Why or why not?
Answer: __________________________________________
6. If you were not successful in the previous step, this means that you
need a user that has the proper privileges. Create a user called
auditer with appropriate privileges. Record the command(s) used:
Command: __________________________________________
Command: __________________________________________
Command: __________________________________________
7. Log out of the service processor and log in as auditer.
Command: __________________________________________
Command: __________________________________________
Answer: __________________________________________
10. View the audit information for the user user1. Record the command
used:
Command: __________________________________________

Task 3 Creating a snapshot Archive

In this task, you create and manage snapshots. Complete the following
steps:
2. Create a snapshot to the archive host using the following parameters:
Host key: no
Host: Non-Global zone
User: archive user on the Non-Global zone
Directory: archive directory on the Non-Global zone
Command: __________________________________________
3. After the command completes, log in to the Non-Global zone and
verify that the snapshot was successful.

Task 4 Viewing Logs

In this task, you view the various log files available on the service
processor. Complete the followings steps.
2. Display all error logs currently available. Record the command used:
Command: __________________________________________
3. Display all power logs currently available. Record the command
used:
Command: __________________________________________
4. What was the last power event that occurred on your server?
Status: __________________________________________
5. Display all environmental logs for your server. Record the command
used:
Command: __________________________________________
6. Display all console messages for your assigned domain. Record the
command used:
Command: __________________________________________

Task 5 Executing Sun Explorer

1. Create a domain and boot Solaris.
2. Log in to your domain as the superuser.
3. Change your directory to /explo.
Command: __________________________________________
Command: __________________________________________
6. Execute the Sun Explorer utility with the -g option:
Command: __________________________________________
7. Execute the Sun Explorer utility:
Command: __________________________________________
8. List the contents of the Sun Explorer directory that has been created:
Command: __________________________________________
Hostname: ___________________________
Hostid: ______________________________
OS Release: __________________________
Kernel Architecture: _____________________

Exercise Summary
Exercise Summary

!
?
Experiences
Interpretations
Conclusions
Applications

Exercise Solutions
Exercise Solutions
This section provides answers to the exercises.
Task 1 Configuring Log Archiving

In this task, you configure and manage log archiving. Complete the
following steps:
2. View the current archiving status, and record the command used:
Command: showarchiving
Archiving state: varies, likely disabled
Archive host: varies
Archive directory: varies
Username for ssh login: varies
Connection status: varies
Archive space limit: varies
Archive space used: varies
4. Configure a non-global zone in your remote lab environment to act
as the archive host.
a. Log in to your Non-Global zone as the user root.
b. Verify the IP Address of the non-global zone. Record the output
and command used:
Non-Global zone IP Address: the anwser varies
(example 10.6.15.50)
Command: ifconfig -a
c. Create the /export/home directory if it doesnt exist. Record
the command used:
Command: mkdir -p /export/home
d. Create a new user account on the archive host to use for logins
and assign the user a password. Record the commands used:
Command: useradd -u 5001 -d /export/home/john -m -s /bin/ksh john

Exercise Solutions
Command: passwd john (cangetin)

e. Create a new directory in the users home directory to contain
the service processor logs. Record the command used:
Command: mkdir /export/home/john/logs
f. Set permissions on the newly created directory to allow full
access (777). Record the command used:
Command: chmod 777 /export/home/john/logs
g. Change the ownership and group of the new directory to match
the ownership and group of the users home directory. Record
the command used:
Command: chown john:staff /export/home/john/logs
5. Configure the archiving parameters on the service processor.
a. Log in to the service processor as the userid user1.
b. Disable log archiving. Record the command used:
Command: setarchiving disable
c. Set the archive target, using your Non-Global zones IP
Address, the user created, and the directory created in Step 4:
Command: setarchiving -t john@10.6.15.50:/export/home/john/log -r
-k download
6. View the updated archiving status, and record the command used:
Command: showarchiving
Archiving state: enabled
Archive host: 10.6.15.50
Archive directory: /export/home/john/logs
Username for ssh login: john
Connection status: varies
Archive space limit: varies
Archive space used: varies
8. Enable log archiving. Record the command used:
Command: setarchiving enable
9. Log back in to your Non-Global zone and verify if any files have
been created in the archive directory.

Exercise Solutions
Task 2 Configuring Auditing

In this task, you configure and manage auditing on the service processor.
Complete the following steps:
2. Set the privileges for the user1 account to be platadm, fieldeng, and
useradm. Record the command used:
Command: setprivileges user1 platadm fieldeng useradm
3. Display the current auditing policy. Record the command used:
Status: disabled Command: showaudit
Command: setaudit enable
Answer: No. The user account user1 does not have auditadm privileges.
6. If you were not successful in the previous step, this means that you
need a user that has the proper privileges. Create a user called
auditer with appropriate privileges. Record the command(s) used:
Command: adduser auditer
Command: password auditer
Command: setprivileges auditer auditadm
7. Log out of the service processor and log in as auditer.
Command: setaudit enable
Command: setaudit disable, setaudit enable
Answer: Yes. The auditer account has auditadm privileges.
10. View the audit information for the user user1. Record the command
used:
Command: viewaudit -u user1

Exercise Solutions
Task 3 Creating a snapshot Archive

In this task, you create and manage snapshots. Complete the following
steps:
2. Create a snapshot to the archive host using the following parameters:
Host key: no
Host: Non-Global zone
User: archive user on the Non-Global zone
Directory: archive directory on the Non-Global zone
Command: snapshot -T
3. After the command completes, log in to the Non-Global zone and
verify that the snapshot was successful.

Exercise Solutions
Task 4 Viewing Logs

In this task, you view the various log files available on the service
processor. Complete the followings steps.
2. Display all error logs currently available. Record the command used:
Command: showlogs error
3. Display all power logs currently available. Record the command
used:
Command: showlogs power
4. What was the last power event that occurred on your server?
Status: varies
5. Display all environmental logs for your server. Record the command
used:
Command: showlogs env
6. Display all console messages for your assigned domain. Record the
command used:
Command: showlogs console -d 00

Exercise Solutions
Task 5 Executing Sun Explorer

1. Create a domain and boot Solaris.
2. Log in to your domain as the superuser.
3. Change your directory to /explo.
Command: gzcat Explorer_5.13.tar.gz | tar xvf -
Command: pkgadd -d . SUNWexplo SUNWexplu
6. Execute the Sun Explorer utility with the -g option:
Command: /opt/SUNWexplo/bin/explorer -g
7. Execute the Sun Explorer utility:
Command: /opt/SUNWexplo/bin/explorer-w default,xscfextended
8. List the contents of the Sun Explorer directory that has been created:
Command: ls -al /opt/SUNWexplo/output/explorer.xxxxxxxxxx
Hostname: varies
Hostid: varies
OS Release: varies
Kernel Architecture: varies


Sun SPARC® Enterprise MX000 Server Administration ES-411 M9000

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sun SPARC® Enterprise MX000 Server Administration ES-411 M9000

Uploaded by

Copyright:

Available Formats

Sun SPARC Enterprise MX000

Sun Microsystems, Inc.

ORACLE is a registered trademark of Oracle Corporation.

Adobe is a registered trademark of Adobe Systems, Incorporated.

DOCUMENTATION IS PROVIDED AS IS AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS, AND

Export Control Classification Number (ECCN) assigned: 14 August 2006

ORACLE est une marque dpose registre de Oracle Corporation.

Adobe est une marque enregistree de Adobe Systems, Incorporated.

LA DOCUMENTATION EST FOURNIE EN LETAT ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET GARANTIES

Introduction to the Sun SPARC Enterprise MX000 Servers .......1-1

vi Sun SPARC Enterprise MX000 Server Administration

viii Sun SPARC Enterprise MX000 Server Administration

x Sun SPARC Enterprise MX000 Server Administration

xii Sun SPARC Enterprise MX000 Server Administration

Introduction to the Sun SPARC Enterprise

Discussion The information in this module is relevant to your job

1-2 Sun SPARC Enterprise MX000 Server Administration

Additional resources The following references provide additional

Introduction to the Sun SPARC Enterprise MX000 Servers 1-3

Sun Microsystems, Inc., Sun SPARC Enterprise M4000/M5000 Servers

1-4 Sun SPARC Enterprise MX000 Server Administration

Introducing the Sun SPARC Enterprise MX000 Servers

The MX000 servers incorporate mainframe features such as dynamic

Sun SPARC Enterprise MX000 Server Models

The MX000 servers feature a robust fault isolation mechanism. If an error

Introduction to the Sun SPARC Enterprise MX000 Servers 1-5

Joint Product Development

This alliance entails shared investment of MX000 servers product

1-6 Sun SPARC Enterprise MX000 Server Administration

High-End Servers Overview

M8000 and M9000 Server Capabilities

Table 1-1 Sun SPARC Enterprise MX000 High-End Server Capabilities

Application acceleration Dual-core SPARC64 VI microprocessors

RAS capabilities Redundancy for:

World-class OS support Solaris 10 OS

Introduction to the Sun SPARC Enterprise MX000 Servers 1-7

1-8 Sun SPARC Enterprise MX000 Server Administration

The M8000 and M9000 Server Components

Table 1-2 summarizes the features of the high-end servers.

Centerplane Active Passive Passive

IO units (IOUs) Four Eight Sixteen

Introduction to the Sun SPARC Enterprise MX000 Servers 1-9

Redundant 12 Fan Units:

Internal drives One DVD One DVD Two DVD

Power 10,500 Watts 21,300 Watts 42,600 Watts

1-10 Sun SPARC Enterprise MX000 Server Administration

Weight 1540 lb 2072 lb 4145 lb

Clearance and 31.5 inches 31.5 inches 31.5 inches

Introduction to the Sun SPARC Enterprise MX000 Servers 1-11

Overview of Common Features and Components

System Architecture Terminology

Table 1-3 Architecture Terms

CPUM board Mid-range server board containing 2 processors.

1-12 Sun SPARC Enterprise MX000 Server Administration

Table 1-3 Architecture Terms (Continued)

Extended System Board A Uni-mode XSB consists of up to two CPUMs, four

Introduction to the Sun SPARC Enterprise MX000 Servers 1-13

Physical System Board Sets

CPU and Memory

1-14 Sun SPARC Enterprise MX000 Server Administration

Note Mixing of CPUs running at different clock frequencies is

The CPUs implement a combination of:

Introduction to the Sun SPARC Enterprise MX000 Servers 1-15