Fujitsu SPARC Enterprise M4000, SPARC Enterprise M5000, SPARC Enterprise M8000, SPARC Enterprise M9000 Features Manual

Download

Page 1

SPARC Enterprise M4000/M5000/M8000/M9000 Servers

Dynamic Reconfiguration (DR) User's Guide

Part No.: E27809-01, Manual Code: C120-E335-09EN January 2012

Page 2

Copyright © 2007, 2012, Fujitsu Limited. All rights reserved. Oracle and/or its affiliates provided technical input and review on portions of this material. Oracle and/or its affiliates and Fujitsu Limited each own or control intellectual property rights relating to products and technolog y described in this

document, and such products, technology and this document are protected by copyright laws, patents, and other intellectual property laws and international treaties.

This document and the product and technology to which it pertains are distributed under licenses restricting their use, copying, distribution, and decompilation. No part of such product or technology, or of this document, may be reproduced in any form by any means without prior written authorization of Oracle and/or its affiliates and Fujitsu Limited, and their applicable licensors, if any. The furnishings of this document to you does not give you any rights or licenses, express or implied, with respect to the product or technology to which it pertains, and this document does not contain or represent any commitment of any kind on the part of Oracle or Fujitsu Limited, or any affiliate of either of them.

This document and the product and technology described in this document may incorporate third-party intellectual property copyrighted by and/or licensed from the suppliers to Oracle and/or its affiliates and Fujitsu Limited, including software and font technology.

Per the terms of the GPL or LGPL, a copy of the source code governed by the GPL or LGPL, as applicab le, is ava ilable upon request by the End User. Please contact Oracle and/or its affiliates or Fujitsu Limited.

This distribution may include materials developed by third parties. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and

in other countries, exclusively licensed through X/Open Company, Ltd. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Fujitsu and the Fujitsu logo are registered trademarks of Fujitsu Limited. All SPARC trademarks are used under license and are registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing

SPARC trademarks are based upon architectures developed by Oracle and/or its affiliates. SPARC64 is a trademark of SPARC International, Inc., used under license by Fujitsu Microelectronics, Inc. and Fujitsu Limited. Other names may be trademarks of their respective owners.

United States Government Rights - Commercial use. U.S. Government users are subject to the standard government user license agreements of Oracle and/or its affiliates and Fujitsu Limited and the applicable provisions of the FAR and its supplements.

Disclaimer: The only warranties granted by Oracle and Fujitsu Limited, and/or any affiliate of either of them in connection with this document or any product or technology described herein are those expressly set forth in the license agreement pursuant to which the product or technology is provided. EXCEPT AS EXPRESSLY SET FORTH IN SUCH AGREEMENT, ORACLE OR FUJITSU LIMITED, AND/OR THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES OF ANY KIND (EXPRESS OR IMPLIED) REGARDING SUCH PRODUCT OR TECHNOLOGY OR THIS DOCUMENT, WHICH ARE ALL PROVIDED AS IS, AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. Unless otherwise expressly set forth in such agreement, to the extent allowed by applicable law, in no event shall Oracle or Fujitsu Limited, and/or any of their affiliates have any liability to any third party under any legal theory for any loss of revenues or profits, loss of use or data, or business interruptions, or for any indirect, special, incidental or consequential damages, even if advised of the possibility of such damages.

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.

Please

Recycle

Page 3

Copyright © 2007, 2012, Fujitsu Limited. Tous droits réservés. Oracle et/ou ses sociétés affiliées ont fourni et vérifié des donn ées techniq ues de certaines parties de ce composant. Oracle et/ou ses sociétés affiliées et Fujitsu Limited détiennent et contrôlent chacune des droits de propriété intellectuelle relatifs aux produits et

technologies décrits dans ce document. De même, ces produits, technologies et ce document sont protégés par des lois sur le copyright, des brevets, d’autres lois sur la propriété intellectuelle et des traités internationaux.

Ce document, le produit et les technologies afférents sont exclusivement distribués avec des licences qui en restreignent l’utilisation, la copie, la distribution et la décompilation. Aucune partie de ce produit, de ces technologies ou de ce document ne peut être reproduite sous quelque forme que ce soit, par quelque moyen que ce soit, sans l’autorisation écrite préalable d’Oracle et/ou ses sociétés affiliées et de Fujitsu Limited, et de leurs éventuels bailleurs de licence. Ce document, bien qu’il vous ait été fourni, ne vous confère aucun droit et aucune licence, expresses ou tacites, concernant le produit ou la technologie auxquels il se rapporte. Par ailleurs, il ne contient ni ne représente aucun engagement, de quelque type que ce soit, de la part d’Oracle ou de Fujitsu Limited, ou des sociétés affiliées de l’une ou l’autre entité.

Ce document, ainsi que les produits et technologies qu’il décrit, peuvent inclure des droits de propriété intellectuelle de parties tierces protégés par copyright et/ou cédés sous licence par des fournisseurs à Oracle et/ou ses sociétés affiliées et Fujitsu Limited, y compris des logiciels et des technologies relatives aux polices de caractères.

Conformément aux conditions de la licence GPL ou LGPL, une copie du code source régi par la licence GPL ou LGPL, selon le cas, est disponible sur demande par l’Utilisateur final. Veuillez contacter Oracle et/ou ses sociétés affiliées ou Fujitsu Limited.

Cette distribution peut comprendre des composants développés par des parties tierces. Des parties de ce produit peuvent être dérivées des systèmes Berkeley BSD, distribués sous licence par l’Université de Californie. UNIX est une marque

déposée aux États-Unis et dans d’autres pays, distribuée exclusivement sous licence par X/Open Company, Ltd. Oracle et Java sont des marques déposées d’Oracle Corporation et/ou de ses sociétés affiliées. Fujitsu et le logo Fujitsu sont des marques déposées de

Fujitsu Limited. Toutes les marques SPARC sont utilisées sous licence et sont des marques déposées de SPARC International, Inc., aux États-Unis et dans d’autres pays. Les

produits portant la marque SPARC reposent sur des architectures développées par Oracle et/ou ses sociétés affiliées. SPARC64 est une marque de SPARC International, Inc., utilisée sous licence par Fujitsu Microelectronics, Inc. et Fujitsu Limited. Tout autre nom mentionné peut corresp ondre à des marq ues appartenant à d’autres propriétaires.

Avis de non-responsabilité : les seules garanties octroyées par Oracle et Fujitsu Limited et/ou toute société affiliée de l’une ou l’autre entité en rapport avec ce document ou tout produit ou toute technologie décrits dans les présentes correspondent aux garanties expressément stipulées dans le contrat de licence régissant le produit ou la technologie fournis. SAUF MENTION CONTRAIRE EXPRESSÉMENT STIPULÉE DANS CE CONTRAT, ORACLE OU FUJITSU LIMITED ET LES SOCIÉTÉS AFFILIÉES À L’UNE OU L’AUTRE ENTITÉ REJETTENT TOUTE REPRÉSENTATION OU TOUTE GARANTIE, QUELLE QU’EN SOIT LA NATURE (EXPRESSE OU IMPLICITE) CONCERNANT CE PRODUIT, CETTE TECHNOLOGIE OU CE DOCUMENT, LESQUELS SONT FOURNIS EN L’ÉTAT. EN OUTRE, TOUTE S LES CONDITIONS, REPRÉSENTATIONS ET GARANTIES EXPRESSES OU TACITES, Y COMPRIS NOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE À LA QUALITÉ MARCHANDE, À L’APTITUDE À UNE UT ILISATION PARTICULIÈRE OU À L’ABSENCE DE CONTREFAÇON, SONT EXCLUES, DANS LA MESU RE AUTORISÉE PAR LA LOI APPLICABLE. Sauf mention contraire expressément stipulée dans ce contrat, dans la mesure autorisée par la loi applicable, en aucun cas Oracle ou Fujitsu Limited et/ou l’une ou l’autre de leurs sociétés affiliées ne sauraient être tenues responsables envers une quelconque partie tierce, sous quelque théorie juridique que ce soit, de tout manque à gagner ou de perte de profit, de problèmes d’utilisation ou de perte de données, ou d’interruptions d’activités, ou de tout dommage indirect, spécial, secondaire ou consécutif, même si ces entités ont été préalablement informées d’une telle éventualité.

LA DOCUMENTATION EST FOURNIE « EN L’ÉTAT » ET TOUTE AUTRE CONDITION, DÉCLARATION ET GARANTIE, EXPRESSE OU TACITE, EST FORMELLEMENT EXCLUE, DANS LA MESURE AUTORISÉE PAR LA LOI EN VIGUEUR, Y COMPRIS NOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE À LA QUALITÉ MARCHANDE, À L’APTITUDE À UNE UTILISATION PARTICULIÈRE OU À L’ABSENCE DE CONTREFAÇON.

Page 4

Page 5

Preface ix

1. Overview of Dynamic Reconfiguration 1–1

1.1 DR 1–1

1.2 Basic DR Functions 1–5

1.2.1 Adding a System Board 1–6

1.2.2 Deleting a System Board 1–6

1.2.3 Moving a System Board 1–6

1.2.4 Replacing a System Board 1–7

1.3 Security 1–7

1.4 Overview of DR User Interfaces 1–7

2. What You Must Know Before Using DR 2–1

2.1 System Configuration 2–1

2.1.1 System Board Components 2–1

2.1.1.1 CPU 2–4

2.1.1.2 Memory 2–5

2.1.1.3 I/O Device 2–9

2.1.2 System Board Configuration Requirements 2–10

2.1.3 System Board Pool Function 2–10

Page 6

2.1.4 Checklists for System Configuration 2–11

2.1.5 Reservation of Domain Configuration Changes 2–12

2.2 Conditions and Settings Using XSCF 2–13

2.2.1 Conditions Using XSCF 2–13

2.2.2 Settings Using XSCF 2–13

2.2.2.1 Configuration Policy Option 2–14

2.2.2.2 Floating Board Option 2–14

2.2.2.3 Omit-memory Option 2–15

2.2.2.4 Omit-I/O Option 2–16

2.3 Conditions and Settings Using Oracle Solaris OS 2–16

2.3.1 I/O and Software Requirements 2–16

2.3.2 Settings of Kernel Cage Memory 2–17

2.3.3 Setting of Oracle Solaris Service Management Facility (SMF) 2–18

2.4 Status Management 2–18

2.4.1 Domain Status 2–18

2.4.2 System Board Status 2–19

2.4.3 Flow of DR Processing 2–21

2.4.3.1 Flowchart: Adding a System Board 2–21

2.4.3.2 Flowchart: Deleting a System Board 2–22

2.4.3.3 Flowchart: Moving a System Board 2–23

2.4.3.4 Flowchart: Replacing System Board 2–25

2.5 Operation Management 2–27

2.5.1 I/O Device Management 2–27

2.5.2 Swap Area 2–27

2.5.2.1 Swap Area at System Board Addition 2–27

2.5.2.2 Swap Area at System Board Deletion 2–27

2.5.3 Real-time Processes 2–28

2.5.4 Memory Mirror Mode 2–28

vi SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 7

2.5.5 Capacity on Demand (COD) 2–29

2.5.6 XSCF Failover 2–29

2.5.7 Kernel Memory Board Deletion 2–29

2.5.8 Deletion of Board with CD-RW/DVD-RW Drive 2–30

2.5.9 SPARC64 VII+, SPARC64 VII, and SPARC64 VI Processors and CPU Operational Modes 2–30

2.5.9.1 CPU Operational Modes 2–31

3. DR User Interface 3–1

3.1 How To Use the DR User Interface 3–1

3.1.1 Displaying Domain Information 3–2

3.1.2 Displaying Domain Status 3–5

3.1.3 Displaying System Board Information 3–7

3.1.4 Displaying Device Information 3–10

3.1.5 Displaying System Board Configuration Information 3–13

3.1.6 Adding a System Board 3–15

3.1.7 Deleting a System Board 3–17

3.1.8 Moving a System Board 3–19

3.1.9 Replacing a System Board 3–22

3.1.10 Reserving a Domain Configuration Change 3–25

3.2 Command Reference 3–26

3.3 XSCF Web 3–27

3.4 RCM Script 3–27

4. Practical Examples of DR 4–1

4.1 Flow of DR Operation 4–2

4.1.1 Flow: Adding a System Board 4–3

4.1.2 Flow: Deleting a System Board 4–4

4.1.3 Flow: Moving a System Board 4–5

4.1.4 Flow: Replacing a System Board 4–6

Contents vii

Page 8

4.2 Example: Adding a System Board 4–7

4.3 Example: Deleting a System Board 4–9

4.4 Example: Moving a System Board 4–11

4.5 Examples: Replacing a System Board 4–13

4.5.1 Example: Replacing a Uni-XSB System Board 4–13

4.5.2 Example: Replacing a Quad-XSB System Board 4–16

4.6 Examples: Reserving Domain Configuration Changes 4–20

4.6.1 Example: Reserving a System Board Add 4–20

4.6.2 Example: Reserving a System Board Delete 4–22

4.6.3 Example: Reserving a System Board Move 4–23

A. Message Meaning and Handling A–1

A.1 Oracle Solaris OS Messages A–1

A.1.1 Transition Messages A–1

A.1.2 PANIC Messages A–3

A.1.3 Warning Messages A–4

A.2 Command Messages A–24

A.2.1 addboard A–24

A.2.2 deleteboard A–27

A.2.3 moveboard A–29

A.2.4 setdcl A–33

A.2.5 setupfru A–34

A.2.6 showdevices A–35

B. Example: Confirm Swap Space Size B–1

Index Index–1

viii SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 9

Preface

This guide describes the Dynamic Reconfiguration (DR) feature of SPARC Enterprise M4000/M5000/M8000/M9000 servers from Oracle and Fujitsu. DR enables users to add, remove or exchange system boards in the M4000/M5000 (midrange) and M8000/M9000 (high-end) servers while the domains that contain these boards remain up and running. The M3000 server does not support DR.

Some references to server names and document names are abbreviated for readability. For example, if you see a reference to the M9000 server, note that the full product name is the SPARC Enterprise M9000 server. And if you see a reference to the XSCF Reference Manual, note that the full document name is the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF Reference Manual.

Before reading this document, you should read the overview guide for your server, the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers Administration

Guide, and the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.

At publication of this document, servers described herein were shipping with XCP 1110 firmware supported or installed. That might no longer be the latest available version, or the version now installed. Always see the Product Notes that apply to the firmware on your server, and those that apply to the latest firmware release.

This chapter includes the following sections:

■ “Audience” on page x

■ “Related Documentation” on page x

■ “Text Conventions” on page xii

■ “Syntax of the Command-Line Interface (CLI)” on page xii

■ “Documentation Feedback” on page xiii

Page 10

Audience

This guide is written for experienced system administrators with working knowledge of computer networks and advanced knowledge of the Oracle Solaris Operating System (Oracle Solaris OS).

Text Conventions

This manual uses the following fonts and symbols to express specific types of information.

Font/Symbol Meaning Example

AaBbCc123

AaBbCc123 The names of commands, files, and

Italic Indicates the name of a reference

" " Indicates names of chapters,

What you type, when contrasted with on-screen computer output.

This font represents the example of command input in the frame.

directories; on-screen computer output.

This font represents the example of command output in the frame.

manual, a variable, or userreplaceable text.

sections, items, buttons, or menus.

XSCF> adduser jsmith

XSCF> showuser -P User Name: jsmith Privileges: useradm

auditadm

See the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.

See Chapter 2, "System Features."

Syntax of the Command-Line Interface (CLI)

The command syntax is as follows:

■ A variable that requires input of a value must be put in Italics.

■ An optional element must be enclosed in [].

■ A group of options for an optional keyword must be enclosed in [] and delimited

by |.

xii SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 13

Documentation Feedback

If you have any comments or requests regarding this document, go to the following websites:

■ For Oracle users:

http://www.oracle.com/goto/docfeedback

Include the title and part number of your document with your feedback:

SPARC Enterprise M4000/M5000/M8000/M9000 Servers Dynamic Reconfiguration (DR) User’s Guide, part number E27809-01

■ For Fujitsu users:

http://www.fujitsu.com/global/contact/computing/sparce_index.html

Preface xiii

Page 14

xiv SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 15

CHAPTER

Overview of Dynamic Reconfiguration

This chapter provides an overview of Dynamic Reconfiguration, which is controlled by the eXtended System Control Facility (XSCF).

This chapter includes these sections:

■ Section 1.1, “DR” on page 1-1

■ Section 1.2, “Basic DR Functions” on page 1-5

■ Section 1.3, “Security” on page 1-7

■ Section 1.4, “Overview of DR User Interfaces” on page 1-7

1.1 DR

Dynamic Reconfiguration (referred to as DR, in this document) enables hardware resources such as processors, memory, and I/O to be added and deleted even while the Oracle Solaris Operating System (referred to as Oracle Solaris OS in this document) is running.

DR has three basic functions; i.e., addition, deletion and move, which can be used for the following purposes.

■ Add system boards without stopping the Oracle Solaris OS of the domain, to

improve business operations or handle higher system loads.

■ Temporarily remove a faulty system board for parts replacement without

stopping the Oracle Solaris OS of the domain, in the event of an error that causes the system board to become degraded.

1-1

Page 16

■ Move a resource from one domain to another while continuously operating the

System boards

Uni-XSB

MBU

XSB

Quad-XSB

MBU

XSB XSB XSB XSB XSB XSB XSB XSB

CMU

IOU

CMU

IOU

domains without physically removing or inserting a system board. Resources can be moved to balance the loads on multiple domains, or to share common I/O resources between domains.

SPARC Enterprise M4000/M5000/M8000/M9000 servers have a unique partitioning feature that can divide one physical system board (PSB) into one logical board (undivided status) or four logical boards. A PSB that is logically divided into one board (undivided status) is called a Uni-XSB, whereas a PSB that is logically divided into four boards is called a Quad-XSB. Each composition of physical unit of the divided PSB is called an eXtended System Board (XSB). These XSBs can be combined freely to create domains.

DR functions on these servers are performed on an XSB. This manual uses the term system board unless physical units of PSB and XSB are described. For an explanation of each term, see

TABLE 1-2.

Note – This document explains DR functions on system boards. Use the Oracle

Solaris command cfgadm(1M) to execute DR on I/O devices, including PCI cards. For more information, please see the Service Manual for your server, and the cfgadm(1M) and cfgadm_pci(1M) man pages.

FIGURE 1-1 Uni-XSB and Quad-XSB (Midrange Servers)

1-2 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 17

FIGURE 1-2 Uni-XSB and Quad-XSB (High-end Servers)

Uni-XSB

XSB

Quad-XSB

XSB XSB XSB XSB

System boards

CMU

IOU

CMU

IOU

TABLE 1-1 and TABL E 1 -2 list DR-related terms.

TABLE 1-1 Basic DR Terms

Term Definition

Add To connect a system board to a domain and configure it into the

Oracle Solaris OS of the domain.

Delete To unconfigure a system board from the Oracle Solaris OS of a

Move To disconnect a system board from a domain and then connect the

Release To delete a registered system board from the DCL.

Assign To assign a system board to a domain.

Unassign To release a system board from a domain.

Connect To connect a system board to a domain.

Disconnect To disconnect a system board from a domain.

Configure To configure a system board in the Oracle Solaris OS.

domain and disconnect it from the domain.

system board to another domain.

called DCL).

Chapter 1 Overview of Dynamic Reconfiguration 1-3

Page 18

TABLE 1-1 Basic DR Terms (Continued)

Term Definition

Unconfigure To unconfigure a system board in the Oracle Solaris OS.

Reserve To reserve a system board such that it is assigned to or unassigned

from a domain on the next reboot or power-cycle.

Install To insert a system board into a system.

Remove To remove a system board from a system.

Replace To remove a system board and then mount it or a new system board,

for system maintenance and inspection.

TABLE 1-2 Terms Related to Hardware Configurations

Term Definition

CPU/Memory board unit (CMU)

Motherboard Unit (MBU)

Unit equipped with a CPU module, and memory. High-end servers only.

Unit for midrange servers. A CMU is mounted on this board. Midrange servers only.

I/O unit (IOU) Unit equipped with a PCI card and a disk drive unit.

Physical System Board (PSB)

The PSB is made up of physical parts, and can include 1 CMU and 1 IOU or just 1 CMU. In midrange servers, the CMU is mounted on a MBU. A PSB also can be used to describe a physical unit for addition/deletion/exchange of hardware. The PSB can be used in one of two methods, one complete unit (undivided status) or divided into four subunits.

eXtended System Board (XSB)

The XSB is made of physical parts. In the XSB, the PSB can be either one complete unit (undivided status) or divided into four subunits. The XSB is a unit used for domain construction and identification, and also can be used as a logical unit.

Logical System Board (LSB)

A logical unit name assigned to an XSB. Each domain has its own set of LSB assignments. LSB numbers are used to control how resources such as kernel memory get allocated within domains.

1-4 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 19

TABLE 1-2 Terms Related to Hardware Configurations (Continued)

Domain A

Domain B

System board #0

System board #1

System board #2

System board #3

Domain B

System board #1

System board #3

System board #0

System board #2

Term Definition

System board The hardware resources of a PSB or an XSB. A system board is used

to describe the hardware resources for operations such as domain construction and identification. In this manual, this refers to the XSB.

Uni-XSB One of the division types of a PSB. Uni-XSB is a name for when a PSB

is logically only one unit (undivided status). It is a default value setting for the division type for a PSB. The division type can be changed by using the XSCF command setupfru(8). Uni-XSB may be used to describe a PSB division type or status.

Quad-XSB One of the division types of a PSB. Quad-XSB is a name for when a

PSB is logically divided into four parts. The division type can be changed by using the XSCF command setupfru(8). Quad-XSB may be used to describe a PSB division type or status.

1.2 Basic DR Functions

This section describes the basic DR functions.

FIGURE 1-3 shows DR processing.

FIGURE 1-3 DR Processing Flow

Chapter 1 Overview of Dynamic Reconfiguration 1-5

Page 20

In the example shown in FIGURE 1-3, system board #2 is deleted from domain A and added to domain B. In this way, the physical configuration of the hardware (mounting locations) is not changed but the logical configuration is changed for management of the system boards.

1.2.1 Adding a System Board

You can use DR to add a system board to a domain provided that board is installed in the system and not assigned to another domain. You can do so without stopping the Oracle Solaris OS running in the domain.

A system board is added in such stages as connect, and configure.

In the add operation, the selected system board is connected to the target domain. Then, the system board is configured to the Oracle Solaris OS of the domain. At this point, addition of the system board is completed.

1.2.2 Deleting a System Board

You can use DR to delete a system board from a domain without stopping the Oracle Solaris OS running in that domain.

A system board is deleted in such stages as unconfigure and disconnect. If the board must be assigned to another domain, the delete operation must also include an unassign step.

In the delete operation, the selected system board is unconfigured from its domain by the Oracle Solaris OS. Then, the board is disconnected from the domain. At this point, deletion of the system board is completed.

1.2.3 Moving a System Board

You can use DR to reassign a system board from one domain to another without stopping the Oracle Solaris OS running in either domain.

This move function can change the configurations of both domains without physical removal and remounting of the system board.

The move operation for a system board is a serial combination of the “delete” and “add” operations. In other words, the selected system board is deleted from its domain and then added to the target domain.

1-6 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 21

1.2.4 Replacing a System Board

You can use DR to remove a system board from a domain and either add it back later, or replace it with another system board, provided both boards satisfy DR requirements as described in this document. You can do so without stopping the Oracle Solaris OS running in either domain.

You can replace system board in the case of exchanging hardware resources such as CPUs, memory, I/O devices.

A system board is replaced successively in stages.

In the replace operation, the selected system board is deleted from the OS of the domain. Then, the system board is removed when it is ready to be released from its domain. After field parts replacement or other such task, the system board is re-installed and added.

Note – You cannot use DR to replace a system board in a midrange server because

doing so would replace an MBU. To replace a system board in a midrange server, you must turn off the power of all domains, then replace the board without using DR commands.

1.3 Security

DR operations are executed based on privileges. For information about privileges and user accounts, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers Administration Guide.

1.4 Overview of DR User Interfaces

DR operations are performed through the command line interface (CLI) within the XSCF shell or through the browser-based user interface (BUI) in the XSCF Web provided by the eXtended System Control Facility (XSCF). These operations are collectively managed by the XSCF. Furthermore, XSCF security management restricts DR operations to administrators who have the proper access privileges.

Chapter 1 Overview of Dynamic Reconfiguration 1-7

Page 22

For details of XSCF shell commands provided for DR, see Section 3.1, “How To Use

the DR User Interface” on page 3-1. XSCF Web is beyond the scope of this document.

See the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide for further information.

1-8 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 23

CHAPTER

What You Must Know Before Using DR

This chapter provides information you must know to successfully use the DR functions.

This chapter includes these sections:

■ Section 2.1, “System Configuration” on page 2-1

■ Section 2.2, “Conditions and Settings Using XSCF” on page 2-13

■ Section 2.3, “Conditions and Settings Using Oracle Solaris OS” on page 2-16

■ Section 2.4, “Status Management” on page 2-18

■ Section 2.5, “Operation Management” on page 2-27

2.1 System Configuration

This section describes the conditions, premises, and actions for operating the DR functions to construct a system.

2.1.1 System Board Components

There are three types of system board components that can be added and deleted by DR: CPU, memory, and I/O device. system board of a midrange server that is divided into one Uni-XSB, and into Quad-XSBs. high-end server that is divided into one Uni-XSB, and into Quad-XSBs.

FIGURE 2-3 and FIGURE 2-4 show examples of a system board of a

FIGURE 2-1 and FIGURE 2-2 show examples of a

2-1

Page 24

Note – Due to diagnostic requirements, the DR function works only on boards that

CMU IOU

Memory

XSB 00-0

I/O device

Memory

XSB 01-0

I/O device

MBU

have at least one CPU and memory.

FIGURE 2-1 Example of Hardware Configuration (with Uni-XSB of Midrange Server)

2-2 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 25

FIGURE 2-2 Example of Hardware Configuration (with Quad-XSBs of Midrange Server)

CMU IOU

Memory

XSB 00-2

Memory

XSB 00-3

XSB 00-0

Memory

I/O device

XSB 00-1

Memory

I/O device

Memory

XSB 01-2

Memory

XSB 01-3

XSB 01-0

Memory

I/O device

XSB 01-1

Memory

I/O device

MBU

Chapter 2 What You Must Know Before Using DR 2-3

Page 26

FIGURE 2-3 Example of a Hardware Configuration (with Uni-XSBs of High-end Server)

CMU IOU

Memory

XSB 00-0

I/O device

CMU IOU

XSB 00-2

XSB 00-3

XSB 00-0

Memory

I/O device

XSB 00-1

Memory

I/O device

Memory

I/O device

Memory

I/O device

FIGURE 2-4 Example of a Hardware Configuration (with Quad-XSBs of High-end Server)

2.1.1.1 CPU

Using DR to change a CPU configuration is easier than using it to change the configuration of memory or an I/O device. An added CPU is automatically recognized by the Oracle Solaris OS and becomes

2-4 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

available for use.

Page 27

A CPU to be deleted must meet the following conditions:

■ No running process is bound to the CPU to be deleted. If a running process is

bound to the target CPU, you must unbind or stop the process.

■ The CPU to be deleted does not belong to any processor set. If the target

processor belongs to a processor set, you must delete the CPU from the processor set by using the psrset(1M) command.

■ If the resource pools facility is in use by the domain, the CPU cannot be deleted

unless the minimum processor set sizes can otherwise be maintained. Use the Oracle Solaris commands pooladm(1M) and poolcfg(1M) to check these parameters and, if necessary, adjust the sizes of the domain's resource pools.

Note – These conditions also apply to movement of a system board.

If any of the above conditions are not met, the DR operation is stopped and a message is displayed. However, if you specify the deleteboard(8) command with the -f (force) option, these protections are ignored and DR continues the deletion process.

Note – Exercise care when using the -f (force) option, as doing so introduces risk of

domain failure.

To avoid this problem and automate the operations for CPUs, the Oracle Solaris OS provides the Reconfiguration and Coordination Manager (RCM) script function. For details of RCM, see Section 3.4, “RCM Script” on page 3-27.

For information about mixed configurations of SPARC64 VII+, SPARC64 VII, and SPARC64 VI processors, see Section 2.5.9, “SPARC64 VII+, SPARC64 VII, and

SPARC64 VI Processors and CPU Operational Modes” on page 2-30.

2.1.1.2 Memory

The DR functions classify system boards by memory usage into two types:

■ Kernel memory board

■ User memory board

Chapter 2 What You Must Know Before Using DR 2-5

Page 28

(1) Kernel Memory Board

A kernel memory board is a system board on which kernel memory (memory internally used by the Oracle Solaris OS and containing an OpenBoot PROM program) is loaded. Kernel memory cannot be removed from the system. But the location of kernel memory can be controlled, and kernel memory can be copied from one board to another.

■ To control whether a system board contains kernel memory, use one or more of

the following features, which are described below: kernel cage, floating boards, and kernel memory assignment.

■ To copy kernel memory from one board to another, use the Copy-rename

operation. Copy-rename makes it possible for you to perform DR operations on kernel memory boards.

(1.1) Kernel Cage

The kernel cage function must be in use for DR operations on memory to succeed. Without the kernel cage, kernel memory could be assigned to all system boards, making it impossible to perform DR operations on memory. With the kernel cage, kernel memory is limited to a minimum set of system boards.

For details on enabling this function, see Section 2.3.2, “Settings of Kernel Cage

Memory” on page 2-17.

(1.2) Floating Boards

A floating board is a system board that is designated to be moved easily to another domain. In general, kernel memory is not assigned to a floating board unless absolutely necessary.

However, kernel memory can be assigned to a floating board when one of the following is true:

■ The total amount of space available among non-floating boards is not enough to

hold the kernel memory.

■ The deleteboard(8) command is used with its -f (force) option.

For details on enabling the floating board option for a system board, see

Section 2.2.2.2, “Floating Board Option” on page 2-14. For further details, also see the

SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide or the setdcl(8) man page.

2-6 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 29

(1.3) Kernel Memory Assignment

When a domain is powered on, the Power On Self Test (POST) initially assigns an address space to each system board in that domain. The order in which address spaces are assigned depends on the LSB number and floating board option of each system board. The first address spaces are assigned to non-floating boards in ascending order of LSB number. Then, additional address spaces are assigned to floating boards, again in ascending order of their LSB numbers.

When the kernel cage is enabled, kernel memory is assigned to system boards in the order of their address spaces. The kernel cage begins in the first address space (which initially corresponds to the non-floating board with the lowest LSB number). If the kernel requires more memory, then the kernel cage expands to the next address space (which initially corresponds to the non-floating board with the next-lowest LSB number), and so on. The kernel cage extends into the address spaces of floating boards only if kernel memory is too large to fit in the address spaces of the non-floating boards.

Note – During a copy-rename operation, the address spaces initially assigned by

POST are exchanged between system boards. The effects of this process persist through reboots of a domain. Therefore, kernel memory may be assigned in a seemingly different order until the domain has gone through a full poweroff(8) and poweron(8) cycle, as this pair of operations cancels the effects of copy-rename operations.

For details on assigning LSB numbers to system boards, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide or the setdcl(8) man page.

(1.4) Copy-rename

Kernel memory itself cannot be removed, but it can be transferred to another system board. A DR operation to delete a kernel memory board must first perform this transfer, which is called a copy-rename operation.

The Oracle Solaris OS selects the target for the copy-rename operation from among the available user memory boards. The following selection and preference criteria are in effect:

■ The copy-destination board must not yet contain any kernel memory. (It must be

a user memory board.)

■ The copy-destination board must not be a floating board, unless the -f (force)

option is used with the deleteboard(8) command.

■ The copy-destination board must contain at least as much physical memory as the

system board being deleted.

Chapter 2 What You Must Know Before Using DR 2-7

Page 30

■ If more than one system board satisfies all the selection criteria to the same degree

of satisfaction, the one with the lowest LSB number is selected as the copy-destination board.

Note – If no system boards meet the selection criteria, the DR operation to delete the

kernel memory board will fail.

Once the copy-destination board has been selected, the Oracle Solaris OS performs a memory deletion on the selected user memory board.

Then, the kernel memory on the system board to be deleted is copied into memory on the selected copy-destination system board. The system is suspended while the copying is in progress. After all the memory is copied, the address space of the copy-destination board is renamed to that of the kernel memory board being deleted.

Note – If the address space of a system board is renamed by a copy-rename

operation, the change will persist across reboots of the domain. A poweroff(8)/poweron(8) cycle of the domain will reset the address space assignments and remove the effects of one or more copy-rename operations.

(2) User Memory Board

A user memory board is a system board on which no kernel memory is loaded. Before deleting user memory, the system attempts to swap out the physical pages to the swap area. Sufficient swap space must be available for this operation to succeed.

(2.1) Locked Pages and ISM Pages

Some user pages are locked into memory and cannot be swapped out. These pages receive special treatment by DR.

Intimate Shared Memory (ISM) pages are special user pages which are shared by all processes. ISM pages are permanently locked and cannot be swapped out as memory pages. ISM is usually used by Data Base Management System (DBMS) software to achieve better performance.

Although locked pages cannot be swapped out, the system automatically moves them to the memory on another system board to avoid any problem concerning the pages. Note, however, that the deletion of user memory fails if there is not sufficient free memory size on the remaining system boards to hold the relocated pages.

2-8 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 31

Although such moving of memory (called save processing) requires a certain length of time, system operations can continue during save processing because it is executed as a background task.

Note – The Dynamic Intimate Shared Memory (DISM) is a feature that allows

applications to dynamically resize their ISM segments. Some applications use RCM scripts to resize their DISM segments to assist DR. See the Oracle Solaris man page for rcmscript(4).

Deleting or moving a user memory board fails if either of the following statements is true:

■ The swap area does not have sufficient free space to save data from the user

memory to be deleted.

■ There are too many locked or ISM pages to be covered by the memory on other

system boards.

2.1.1.3 I/O Device

(1) Adding an I/O Device

The device driver processing executed by the Oracle Solaris OS is based on the premise that all device drivers dynamically recognize newly added devices. In the domain where DR is performed, all device drivers must support the addition of devices by DR. Upon the addition of an I/O device by DR, the I/O device is reconfigured automatically.

The path name of a device file under /dev is configured as the path name of the newly added I/O device to make the I/O device accessible.

(2) Deleting an I/O Device

An I/O device can be deleted when both of the following conditions are met:

■ The device to be deleted is not in use in the domain where the DR operation is to

be performed.

■ The device drivers in the domain where the DR operation is to be performed

support DR.

In most cases the device to be deleted is in use. For example, the root file system or any other file systems requisite for operation cannot be unmounted. To solve this problem, you can configure the system by using redundant

Chapter 2 What You Must Know Before Using DR 2-9

Page 32

configuration software to make the access path to each requisite I/O device redundant. For a disk drive unit, you can make the unit redundant by using disk mirroring software.

If a device driver that does not support DR is used in the domain, all access to I/O devices controlled by the device driver must be stopped, and the device driver must be unloaded by using the modunload(1M) command.

Note – Do not move a device that is part of a redundant configuration from one

domain to another domain. The consequences of two domains simultaneously accessing the same device through different paths could be disastrous, such as data corruption.

2.1.2 System Board Configuration Requirements

XSCF enables the Uni-XSB or Quad-XSB setting according to the configuration conditions to determine the division type. If the CPU or memory configuration does not meet the configuration conditions, neither Uni-XSB nor Quad-XSB can be set as the division type. For the CPU configuration and memory configuration conditions set for the division types, see the System Overview for your server.

The setting of division type may be changed for DR operation if a domain operation requirement dictates changing of a necessary hardware resource when a system board is added to the domain. In such cases, the CPU configuration and memory configuration conditions for changing the division type are the same as described above. For the conditions, see the System Overview for your server.

Note – Changing the division type before a DR operation may not be possible

depending on the system board status or DR operation, even if configuration conditions have been met.

2.1.3 System Board Pool Function

The system board pooling function places a specific system board in the status where that board does not belong to any domain.

2-10 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 33

This function can be effectively used to move a system board among multiple domains as needed. For example, a system board can be added from the system board pool to a domain where CPU or memory has a high load. When the added system board becomes unnecessary, the system board can be returned to the system board pool.

All system boards that are targets of DR operations must be registered in the target domain’s Domain Component List (DCL). A domain’s DCL, managed by XSCF, is a list of system boards that are, or are to be, attached to that domain. The DCL of each domain contains not only information of registered system boards but also domain information and option information of each system board.

Moreover, a system board that is pooled can be assigned to a domain only when it is registered on DCL. Pooled system boards must be properly managed.

You can add and delete system boards by combining the system board pooling function with the floating board, omit-memory, and omit-I/O options described in

Section 2.2, “Conditions and Settings Using XSCF” on page 2-13.

2.1.4 Checklists for System Configuration

This section describes the prerequisites and the checklists for configuring the system for DR.

1. Redundant Configuration of I/O Devices - Before a system board can be replaced, any I/O device connected to that board must be temporarily disconnected.

You should use redundant-configuration software to prevent any problem that might be caused by disconnection of an I/O device that would affect a job process. You should also confirm that the driver and software support DR before performing a DR operation.

2. Selection of PCI Cards Supporting DR - All PCI cards and I/O device interfaces on a system board must support DR. If not, you cannot execute DR operations on that system board. You must turn off the power supply to the domain before performing maintenance and installation.

3. Confirmation of DR Compliance of Drivers and Other Software - You must confirm that all I/O device drivers and software installed in the system support DR and allow the I/O device operations of DR.

You should also apply the latest patches to the drivers and other software before performing DR.

Chapter 2 What You Must Know Before Using DR 2-11

Page 34

4. Allocation of Sufficient Memory and Distributed Swap Areas - You must allocate sufficient memory resources to be used when the memory on a system board is disconnected. Performing a DR operation with a high load already applied to memory may significantly lower job process performance and DR operability.

5. Consideration of Hardware Configuration and System Boards on Which Kernel Memory is Loaded - Before determining the hardware configuration and operations, you must understand how job processes are affected by DR operations on system boards on which CPUs, memory, and I/O devices are mounted.

You can perform DR operations on system boards that contain kernel memory. When disconnecting a system board on which kernel memory is loaded, DR copies kernel memory into the memory on another system board. The copy operation is based on the premise that the copy-destination system board does not already contain any kernel memory.

When kernel memory is copied, the Oracle Solaris OS is temporarily suspended. Therefore, you must understand the effect of disconnecting the network connection with remote systems and other influences of the DR operation on job processes before determining system operations.

2.1.5 Reservation of Domain Configuration Changes

Besides letting you add, delete, or move system boards dynamically, DR also lets you order such reconfiguration to take place the next time the affected domains are turned on or turned off, or the domain is rebooted. Use the addboard(8), deleteboard(8), or moveboard(8) command with the -c reserve option to specify these actions.

Some of the reasons you might want to reserve a domain change include:

■ A hardware resource cannot be dynamically reconfigured by DR for business or

operational reasons.

■ Domain configuration settings should not be immediately changed.

■ You want to avoid changing the current domain configuration settings and

change the configuration immediately after the domain is rebooted when necessary to delete a system board having a driver or PCI card that does not support DR.

■ You want to assign a floating board to a specific domain beforehand to prevent

the system board from being acquired by another domain.

For how to reserve domain changes, see Section 3.1.10, “Reserving a Domain

Configuration Change” on page 3-25.

2-12 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 35

2.2 Conditions and Settings Using XSCF

This section describes the operating conditions required for XSCF to start DR operations and the settings that are established by XSCF.

2.2.1 Conditions Using XSCF

The DR operation to add a system board cannot be executed when the system board has only been mounted. The DR operation is enabled by registering the system board in the DCL by using the XSCF shell or XSCF Web. You must confirm that the system board to be added is registered in the DCL before performing the DR operation. As a matter of course, system boards to be deleted, moved, or replaced have already been registered in the DCL. You need not confirm that these boards have been registered in the DCL.

For details about the DCL and how to register system boards in the DCL and to confirm registration, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.

2.2.2 Settings Using XSCF

The DR functions provide users with some options to avoid the complexities of reconfiguration and memory allocation with the Oracle Solaris OS, and make DR operations smoother. You can set up these options using the XSCF shell or XSCF Web. This section describes the following options:

■ Configuration policy option

■ Floating board option

■ Omit-memory option

■ Omit-I/O option

These options are set using setdcl(8) command. For details of how to set the options, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide or the setdcl(8) man page.

Chapter 2 What You Must Know Before Using DR 2-13

Page 36

2.2.2.1 Configuration Policy Option

DR operations involve automatic hardware diagnosis to add or move a system board safely. Degradation of components occurs when the components are set according to the configuration of this option, and a hardware error is detected. This option specifies the range of degradation. Moreover, this option can be used for initial diagnosis by domain startup in addition to DR operations. The unit of degradation can be a component where a hardware error is detected, the system board (XSB) where the component is mounted, or a domain.

Values that can be set and units of degradation are explained in

The default value of the configuration policy option is FRU.

Note – Enable the configuration policy option when the power supply of the

domain is turned off.

TABLE 2-1 Unit of Degradation

Value Unit of degradation

FRU Hardware is degraded in units of components such as CPU and

memory.

XSB Hardware is degraded in units of system boards (XSB).

System Hardware is degraded in units of domains or the relevant domain is

stopped without degradation.

2.2.2.2 Floating Board Option

The floating board option controls kernel memory allocation. Upon deletion of a system board on which kernel memory is loaded, the OS is temporarily suspended. The suspended status affects job processes and may disable DR operations. To avoid this problem, use the floating board option to set the priority of kernel loading into the memory of each system board, which increases the likelihood of successful DR operations. To move a system board among multiple domains, this option can be enabled for the system board to facilitate the system board move.

TAB LE 2- 1.

The value of this option is “true” (to enable the floating board setting) or “false” (to disable the floating board setting). The default is “false”. A system board with “true” set for this option is called a floating board. A system board with “false” set for this option is called a non-floating board.

2-14 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 37

Kernel memory is allocated to the non-floating boards in a domain by priority in ascending order of LSB number. When only floating boards are set in the domain, one of them is selected and used as a kernel memory board. In that case, the status of the board is changed from floating board to non-floating board. When Copy-rename is operated by system board deletion or removal, and only floating board can be used because non-floating board cannot be used, specify the -f (force) option. Configuration of floating board option does not change when the force option is used.

Note – Enable the floating board option when the system board is in the system

board pool or when the system board is not connected to the domain configuration.

2.2.2.3 Omit-memory Option

When the omit-memory option is enabled, the memory on a system board cannot be used in the domain. Even when a system board actually has memory, this option enables you to make the memory on the system board unavailable through a DR operation to add or move the system board. This option can be used when the target domain needs only the CPU (and not the memory) of the system board to be added. If a domain has a high load on memory, an attempt to delete a system board from the domain may fail. This failure results if a timeout occurs in memory deletion processing (saving of the memory of the system board to be disconnected onto a disk by paging) when many memory pages are locked because of high load. To prevent this situation, you can enable the omit-memory option to facilitate the DR operation beforehand.

Note – For diagnosis and management of a system board, memory must be

mounted on the system board even if the omit-memory option is enabled. Enabling the omit-memory option reduces available memory in the domain and may lower system performance. This option must be used in consideration of the influence on jobs.

The value of this option is “true” (omit memory) or “false” (do not omit memory). The default value is “false”.

Note – Enable the omit-memory option when the system board is in the system

board pool or when the system board is not connected to the domain configuration.

Chapter 2 What You Must Know Before Using DR 2-15

Page 38

2.2.2.4 Omit-I/O Option

The omit-I/O option disables the PCI cards, disk drives, and basic local-area network (LAN) ports on a system board to prevent the target domain from using them.

Set this option to “true” if the domain needs to use only the system board’s CPU and memory.

Set this option to “false” if the domain needs to use the system board’s PCI cards and I/O units. In this case you must fully understand the restrictions on use of these I/O components. And you must stop the software (e.g. application programs or daemons) that uses them before you attempt to delete or move the system board.

The value of this option is “true” (omit I/O units) or “false” (do not omit I/O units). The default value is “false”.

Note – Enable the omit-I/O option when the system board is in the system board

pool or when the system board is not connected to the domain configuration.

2.3 Conditions and Settings Using Oracle Solaris OS

This section describes the operating conditions and settings required for DR operations.

2.3.1 I/O and Software Requirements

As described in Section 2.1, “System Configuration” on page 2-1, all I/O device drivers and software installed in a domain where DR is to be used must support DR. The device drivers that support DR must also support the following DDI and DKI entries:

attach(9E): DDI_ATTACH and DDI_RESUME detach(9E): DDI_DETACH and DDI_SUSPEND

If a device driver that does not support DR is present, the deletion of a system board might fail.

2-16 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 39

Even if the DDI_DETACH interface is supported, DDI_DETACH processing fails when the relevant driver is in use. Before starting the deletion of a system board, you must stop using all devices on the system board to be deleted.

The device drivers that do not support DR must be unloaded before a system board is deleted. To unload a device driver, you must stop using all I/O devices controlled by the device driver. To unload a device driver, you can use the Oracle Solaris command modunload(1M). Then, you can reload the driver for the remaining instances and resume using those remaining instances after deleting the system board.

2.3.2 Settings of Kernel Cage Memory

Kernel cage memory is a function used to minimize the number of system boards to which kernel memory is allocated. Kernel cage memory is enabled by default in the Oracle Solaris 10 OS.

If the kernel cage is disabled, the system may run more efficiently, but kernel memory will be spread among all boards and DR operations will not work on memory.

To determine whether kernel cage memory is enabled after the system has been rebooted, check the following message output from the /var/adm/messages file:

NOTICE: DR kernel Cage is ENABLED

If the kernel cage is disabled, the message will be:

NOTICE: DR kernel Cage is DISABLED

In most cases the kernel cage should be enabled. However, you must consider actual operations before changing the setting. If you do not need to perform DR operations, you do not need to enable the kernel cage. To enable kernel cage memory, remove or comment out the following setting from the /etc/system file:

set kernel_cage_enable=0

The OS must be rebooted to make the new setting effective.

Chapter 2 What You Must Know Before Using DR 2-17

Page 40

2.3.3 Setting of Oracle Solaris Service Management Facility (SMF)

Certain DR operations succeed only when the following Oracle Solaris Service Management Facility (SMF) services are active on the domain:

■ Domain SP Communication Protocol (dscp)

■ Domain Configuration Server (dcs)

■ Sun Cryptographic Key Management Daemon (sckmd)

For details, see the Notes about SMF services in Section 3.1.4, “Displaying Device

Information” on page 3-10, Section 3.1.6, “Adding a System Board” on page 3-15, Section 3.1.7, “Deleting a System Board” on page 3-17, and Section 3.1.8, “Moving a System Board” on page 3-19.

2.4 Status Management

The success of DR operations depends on the status of domains and system boards. This section describes the status information on the domains and system boards managed by XSCF, and the points to be noted for a better understanding of DR operation conditions.

2.4.1 Domain Status

XSCF manages the status of each domain. You can display and reference the status of each domain through a user interface provided by XSCF. For details of the user interface, see Chapter 3, DR User Interface.

XSCF manages the following aspects of domain status:

TABLE 2-2 Domain Status

Status Description

Powered Off Domain power is off.

Initialization Phase POST processing or OpenBoot PROM initialization is in progress.

OpenBoot Executing Completed

2-18 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Initialization of OpenBoot PROM is completed.

Page 41

TABLE 2-2 Domain Status (Continued)

Status Description

Booting Oracle Solaris OS is being booted or, due to the domain being

shutdown or reset, the system is in the OpenBoot PROM running state or is suspended in the OpenBoot PROM (ok prompt) state.

Running Oracle Solaris OS is running.

Shutdown Started Oracle Solaris OS is being shut down.

Panic State Oracle Solaris OS has panicked.

To perform a DR operation for a system board, you must determine the method of DR operation according to the status of the relevant domain. The conditions of domain status available for DR operation are described in individual sections of

Chapter 3, DR User Interface. For details of each method used for DR, see the

relevant section.

2.4.2 System Board Status

XSCF manages system board status in units of XSB for the following management items:

TABLE 2-3 System Board Management Items

Management item Description

Power Power on/off status of system board

Test Diagnostic status of system board

Assignment Status of assignment to domain

Connectivity Status of connection to domain

Configuration Status of addition into Oracle Solaris OS

The table below lists the status types available for individual management items.

TABLE 2-4 System Board Management Items

Management item Status Description

Power Power Off The system board is powered off and cannot be

used.

Power On The system board is powered on.

Chapter 2 What You Must Know Before Using DR 2-19

Page 42

TABLE 2-4 System Board Management Items (Continued)

Management item Status Description

Test Unmount The system board is not mounted or cannot be

recognized, perhaps because it is faulty.

Unknown The system board is not being diagnosed.

Te st in g Tes ti ng

Passed Passed

Failed A system board error was detected and the board

has been deconfigured.

Assignment Unavailable The system board is in the system board pool (not

assigned to a domain) and its status is one of the following: not-yet diagnosed, under diagnosis, or diagnosis error. All system boards that are not mounted are also shown as Unavailable.

Available The system board is in the system board pool and

its diagnosis has completed normally.

Assigned The system board is reserved or assigned to the

domain.

Connectivity Disconnected The system board is disconnected from the

domain configuration and is in the system board pool.

Connected The system board is connected to the domain

configuration.

Configuration Unconfigured The hardware resources of the system board have

been deleted from the Oracle Solaris OS.

Configured The hardware resources of the system board have

been added into the Oracle Solaris OS.

XSCF changes and configures system board status according to the conditions under which a system board is installed, removed, or registered in the DCL, or when a domain is started or stopped. System board status also changes when the system board is added, deleted, or moved by DR.

To perform a DR operation for a system board, you must determine the method of DR operation according to the status of the target system board. You can display and reference the status of each system board via a user interface provided by XSCF. For details of the user interface, see Chapter 3, DR User Interface.

2-20 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 43

2.4.3 Flow of DR Processing

This section describes the flow of DR processing and the changes in system board status during individual DR operations.

2.4.3.1 Flowchart: Adding a System Board

The flow of DR operations and the transition of system board status when a system board has been added or reserved for addition are described in the schematic flowchart, below.

Each system board status indicated in

FIGURE 2-5 is the main status that is changed.

Chapter 2 What You Must Know Before Using DR 2-21

Page 44

FIGURE 2-5 Flow of System Board Addition Processing

System board pool

DCL registration status

Test: passed

registration

Add

Error status

Test: fail

Diagnosis

Test: testing

Request to add

Request to add system board,

Error found

Domain configuration

Test: passed

Connection

Diagnosis

Process of addition into OS

Test: passed

Incorpor-

Request of

Test: passed Assignment: available

Addition or reserva-

process

tion, DCL

registration

or reservation

Assignment: assigned

system board

or domain reboot after registration/reservation

operation

Assignment: assigned

completed

change process

Assignment: assigned Connectivity: disconnected

to domain

Assignment: assigned Connectivity: connected

addition into OS

Assignment: assigned Connectivity: connected Configuration: unconfigured

ation into OS

Assignment: assigned Connectivity: connected Configuration: configured

2.4.3.2 Flowchart: Deleting a System Board

2-22 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

The flow of DR operations and the transition of system board status when a system board has been deleted or reserved for deletion are described in the schematic flowchart, below.

Each system board status indicated in

FIGURE 2-6 is the main status that is changed.

Page 45

FIGURE 2-6 Flow of System Board Deletion Processing

Status of deletion from OS

Test: passed

Status of addition into OS

Test: passed

Request of

Domain configuration

Test: passed

Disconnection

Reboot of

Deletion/

Deletion from

DCL registration status

Test: passed

Deletion

Domain configuration change

System board pool

Test: passed

Deletion from

deletion reservation

Assignment: assigned Connectivity: connected Configuration: configured

deletion from OS

Assignment: assigned Connectivity: connected Configuration: unconfigured

domain after reservation

OS completed

change process

Assignment: assigned Connectivity: connected

from domain

Assignment: assigned Connectivity: disconnected

Assignment: assigned

Domain

Assignment: available

from DCL

completed

2.4.3.3 Flowchart: Moving a System Board

The flow of DR operations and the transition of system board status when a system board has been moved or reserved for a move are described in the schematic flowchart, below.

Chapter 2 What You Must Know Before Using DR 2-23

Page 46

Each system board status indicated in FIGURE 2-7 is the main status that is changed.

Process to change domain

Assignment: assigned

Assignment:unavailable

Unassignment

Deletion of system board

Reservation to delete system board

Deletion Reboot of

Move process

Move reservation process

Configuration

Process to change

Assignment: unavailable

Assignment: assigned

Assignment

DCL registration status in

Status of assignment

Request to add system board Registration for

in original domain

completed original domain

Connectivity: disconnected Configuration: unconfigured

from domain

Connectivity: disconnected Configuration: unconfigured

change of original domain completed

configuration of destination domain

configuration in original domain

Connectivity: disconnected Configuration: unconfigured

to domain

Connectivity: disconnected Configuration: unconfigured

to destination domain destination domain

completed

destination domain

to destination domain

For the flow of system board addition processing or deletion processing and the related system board status, see Section 2.4.3.1, “Flowchart: Adding a System Board”

on page 2-21 or Section 2.4.3.2, “Flowchart: Deleting a System Board” on page 2-22,

respectively.

FIGURE 2-7 Flow of System Board Move Processing

2-24 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 47

2.4.3.4 Flowchart: Replacing System Board

The flow of DR operations and the transition of system board status when a system board has been replaced are described using the schematic flowchart.

Each system board state indicated in

The sample status before and after replacement as shown in the figure are explained below. The actual status after hardware replacement may not match the indicated status.

For the flow of system board addition processing or deletion processing and the related system board status, see Section 2.4.3.1, “Flowchart: Adding a System Board”

on page 2-21 or Section 2.4.3.2, “Flowchart: Deleting a System Board” on page 2-22,

respectively.

For details of hardware replacement operations, see the Service Manual for your server.

FIGURE 2-8 is the main status that is changed.

Chapter 2 What You Must Know Before Using DR 2-25

Page 48

FIGURE 2-8 Flow of System Board Replacement Processing

Deletion process

Deleting a system board

DCL registration status

Assignment: assigned

System board pool

Assignment: available

Deletion of system boards also

Request to delete from

Replacement

Hardware replacement and diagnosis

DCL registration status

Test: passed

System board pool

Replacement

Test: passed

Addition

Addition of system board

DCL registration status

from system board pool

process

completed

Assignment: assigned

Assignment: available

process

2-26 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 49

2.5 Operation Management

This section describes the premises and the actions for DR operations.

2.5.1 I/O Device Management

Upon the addition of a system board, device information is reconfigured automatically. However, addition of the system board and the reconfiguration of device information do not end at the same time.

Sometimes, device link in /dev directory is not automatically cleaned up by devfsadmd(1M) daemon. Using devfsadm(1M), you can manually clean up this device link. See the devfsadm(1M) Oracle Solaris man page for details.

2.5.2 Swap Area

The size of available virtual memory is the sum of the size of memory mounted in the system and the size of the swap area on the disk. You must ensure that the size of available memory is sufficient for all necessary operations.

2.5.2.1 Swap Area at System Board Addition

By default in Oracle Solaris, the swap area is also used to store a system crash dump. You should use a dedicated dump device, instead. See the Oracle Solaris man page dumpadm(1M). The default swap area used to store the crash dump varies in size according to the size of mounted memory.

The size of the dump device used to store the crash dump must be larger than the size of mounted memory. When a system board is added, thereby increasing the size of mounted memory, the dump device must be reconfigured as required. For details, see the dumpadm(1M) Oracle Solaris man page.

2.5.2.2 Swap Area at System Board Deletion

When you delete a system board, the memory of the system board is swapped to the swap area of the disks. The available swap area is decreased by the memory size to be deleted. So, before you execute a delete board command, check the total swap area to verify that enough free swap space is available to hold the board's physical

Chapter 2 What You Must Know Before Using DR 2-27

Page 50

memory contents. Be aware that some of the total swap space may be supplied by disks that are attached to the board to be deleted. When making your assessment, be certain to also account for the swap space that will be lost.

■ If the size of available memory (e.g., 1.5 gigabytes) is larger than the size of

deleted memory (e.g., 1 gigabytes), the total size of available memory will be 0.5 gigabytes after deleting the system board.

■ If the size of available memory (e.g., 1.5 gigabytes) is smaller than the size of

deleted memory (2 gigabytes), the attempt to delete the system board will fail.

To determine the size of currently available swap area, execute the swap -s command on the OS and verify that the memory size is marked available. For details, see the Oracle Solaris man page swap(1M). Moreover, the size of physical memory of system board to be deleted and information on I/O devices connected can be confirmed by the showdevices(8) command. See Section 3.1.4, “Displaying Device

Information” on page 3-10, or the showdevices(8) man page. see Appendix B for a

more complete example.

2.5.3 Real-time Processes

The Oracle Solaris OS is temporarily suspended when a kernel memory board is deleted or moved. If your system has any real-time requirements (such as might be indicated by the presence of real-time processes), be aware that such a DR operation could significantly affect these processes.

2.5.4 Memory Mirror Mode

The memory mirror mode is a function used to duplex memory to ensure the hardware reliability of memory. When memory mirror mode is enabled, the domain can continue operation even if a fault occurs in a part of memory (provided that the fault is recoverable).

Memory mirror mode cannot be set in some division types of PSB. For more information, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.

Enabling memory mirror mode does not restrict any DR functions. However, you must consider the domain configuration and operation when enabling memory mirror mode.

2-28 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 51

For example, when a kernel memory board with memory mirror mode enabled is deleted or moved, kernel memory is moved from the kernel memory board to another system board. Kernel memory is moved normally even if memory mirror mode is disabled for the move-destination system board. However, this operation results in lowered reliability of memory on the new kernel memory board.

You must properly plan and decide the setting of memory mirror mode by fully considering the requirements for the domain configuration and operations.

2.5.5 Capacity on Demand (COD)

DR works the same on COD boards as on other system boards, but standard COD restrictions still apply.

For detailed information on COD boards, see the SPARC Enterprise M4000/M5000/M8000/M9000 Servers Capacity on Demand (COD) User’s Guide.

2.5.6 XSCF Failover

An XSCF reset or failover might prevent a DR operation from completing. Log in to the active XSCF to determine if DR succeeded. If not, try it again.

2.5.7 Kernel Memory Board Deletion

An XSCF reset or failover during the Copy-rename phase of a deleteboard(8) or moveboard(8) operation might cause the domain to panic and display the following message::

Irrecoverable FMEM error error_code

If the XSCF reset or failover results in a domain panic, check the active XSCF to determine if the DR operation succeeded. If not, try it again.

Chapter 2 What You Must Know Before Using DR 2-29

Page 52

2.5.8 Deletion of Board with CD-RW/DVD-RW Drive

To delete the system board to which the server’s CD-RW/DVD-RW drive is connected, execute the following steps:

1. Stop the vold(1M) daemon by disabling the volfs service.

# /usr/sbin/svcadm disable volfs

2. Execute the DR operation.

3. Restart the vold(1M) daemon by enabling the volfs service.

# /usr/sbin/svcadm enable volfs

For details, see the vold(1M) Oracle Solaris man page.

2.5.9 SPARC64 VII+, SPARC64 VII, and SPARC64 VI Processors and CPU Operational Modes

Note – This section applies only to M4000/M5000/M8000/M9000 servers that run

or will run SPARC64 VII+ or SPARC64 VII processors.

The M4000/M5000/M8000/M9000 servers support system boards that contain a mix of SPARC64 VII+, SPARC64 VII, and SPARC64 VI processors.

Note – Supported firmware releases and Oracle Solaris releases vary based on

processor type. For details, see the Product Notes that apply to the XCP release running on your server and the latest version of the Product Notes (no earlier than XCP version 1100).

FIGURE 2-9 shows an example of a mixed configuration of SPARC64 VII and SPARC64

VI processors.

2-30 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 53

FIGURE 2-9 CPUs on CPU/Memory Board Unit (CMU) and Domain Configuration

CMU#0

CMU#1

CMU#2

CMU#3

CMU of mixed CPU

configuration

CMU of mixed CPU

configuration

CMU mounted with

SPARC64 VI only

CMU mounted with

SPARC64 VII only

: SPARC64 VII processor

: SPARC64 VI processor

Domain 1

Domain 2

Domain 0

Different types of processors can be mounted on a single CMU, as shown in CMU#2 and CMU#3 in types of processors, as shown in Domain 2 in

FIGURE 2-9. And a single domain can be configured with different

FIGURE 2-9.

2.5.9.1 CPU Operational Modes

An M4000/M5000/M8000/M9000 server domain runs in one of the following CPU operational modes:

■ SPARC64 VI Compatible Mode

All processors in the domain behave like and are treated by the Oracle Solaris OS as SPARC64 VI processors. The extended capabilities of SPARC64 VII+ and SPARC64 VII processors are not available in this mode. Domains 1 and 2 in

FIGURE 2-9 correspond to this mode.

■ SPARC64 VII Enhanced Mode

All boards in the domain must contain only SPARC64 VII+ or SPARC64 VII processors. In this mode, the server utilizes the extended capabilities of these processors. Domain 0 in

FIGURE 2-9 corresponds to this mode.

Chapter 2 What You Must Know Before Using DR 2-31

Page 54

To check the CPU operational mode, execute the prtdiag (1M) command on the Oracle Solaris OS. If the domain is in SPARC64 VII Enhanced Mode, the output will display SPARC64-VII on the System Processor Mode line. If the domain is in SPARC64 VI Compatible Mode, nothing is displayed on that line.

By default, the Oracle Solaris OS automatically sets a domain’s CPU operational mode each time the domain is booted based on the types of processors it contains. It does this when the cpumode variable – which can be viewed or changed by using the setdomainmode(8) command – is set to auto.

You can override the above process by using the setdomainmode(8) command to change the cpumode from auto to compatible, which forces the Oracle Solaris OS to set the CPU operational mode to SPARC64 VI Compatible Mode on reboot. To do so, power off the domain, execute the setdomainmode(8) command to change the cpumode setting from auto to compatible, then reboot the domain.

DR operations work normally on domains running in SPARC64 VI Compatible Mode. You can use DR to add, delete or move boards with any of the processor types, which are all treated as if they are SPARC64 VI processors.

DR also operates normally on domains running in SPARC64 VII Enhanced Mode, with one exception: You cannot use DR to add or move into the domain a system board that contains any SPARC64 VI processors. To add a SPARC64 VI processor you must power off the domain, change it to SPARC64 VI Compatible Mode, then reboot the domain.

In an exception to the above rule, you can use the DR addboard(8) command with its -c reserve or -c assign option to reserve or register a board with one or more SPARC64 VI processors in a domain running in SPARC64 VII Enhanced Mode. The next time the domain is powered off then rebooted, it comes up running in SPARC64 VI Compatible Mode and can accept the reserved or registered board.

Note – Change the cpumode from auto to compatible for any domain that has or

is expected to have SPARC64 VI processors. If you leave the domain in auto mode and all the SPARC64 VI processors later fail, the Oracle Solaris OS will see only the SPARC64 VII+ and SPARC64 VII processors – because the failed SPARC64 VI processors will have been degraded – and it will reboot the domain in SPARC64 VII Enhanced Mode. You will be able to use DR to delete the bad SPARC64 VI boards so you can remove them. But you will not be able to use DR to add replacement or repaired SPARC64 VI boards until you change the domain from SPARC64 VII Enhanced Mode to SPARC64 VI Compatible mode, which requires a reboot.

Setting cpumode to compatible in advance enables you to avoid possible failure of a later DR add operation and one or more reboots.

The SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide contains the above information, as well as more detailed instructions.

2-32 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 55

CHAPTER

DR User Interface

This chapter describes the user interfaces for DR.

■ Section 3.1, “How To Use the DR User Interface” on page 3-1

■ Section 3.2, “Command Reference” on page 3-26

■ Section 3.3, “XSCF Web” on page 3-27

■ Section 3.4, “RCM Script” on page 3-27

3.1 How To Use the DR User Interface

XSCF provides two user interfaces for DR: the command line interface by XSCF shell, and the browser-based user interface by XSCF Web. This section describes the main XSCF shell commands used for DR. For other related commands, see

Section 3.2, “Command Reference” on page 3-26. For XSCF Web, see Section 3.2, “Command Reference” on page 3-26 and Section 3.3, “XSCF Web” on page 3-27.

Note – If your server is configured with SPARC64 VII processors, some restrictions

regarding DR might apply. Please see Section 2.5.9, “SPARC64 VII+, SPARC64 VII,

and SPARC64 VI Processors and CPU Operational Modes” on page 2-30.

3-1

Page 56

XSCF shell commands for DR operations are classified into two types: DR display and DR operation commands.

TABLE 3-1 DR Display Commands

Command name Function

showdcl Display the DCL and domain status.

showdomainstatus Display domain status.

showboards Display system board information.

showdevices Display information about the CPUs, memory, and I/O devices on

system boards.

showfru Display PSB configuration information.

TABLE 3-2 DR Operation Commands

Command name Function

setdcl Update and edit the DCL.

setupfru Set the division type and memory mirror mode for a PSB.

addboard Add a system board to a domain.

deleteboard Delete a system board from a domain.

moveboard Move a system board between domains.

The sections below describe the DR display and DR operation commands in detail and show examples. For details of the options, operands, and usage of these commands, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF Reference Manual.

Note – Use of the user interfaces with XSCF shell and XSCF Web is restricted to

selected administrators, and requires administrator privileges for DR operations. When system boards are shared by multiple administrators, the administrators must carefully prepare and plan secure DR operations.

3.1.1 Displaying Domain Information

The showdcl(8) command displays domain information including the domain ID, configured system board numbers, and domain status in list format.

3-2 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 57

The showdcl(8) command is used before a DR operation to determine whether the domain status permits DR operation, and confirm the registration of the DR-target system board in the DCL. The showdcl(8) command is also used after a DR operation to confirm domain status and configuration.

To change domain settings or register a system board in the DCL, use the setdcl(8) command. To change PSB settings, use the setupfru(8) command.

The following examples show the format and specifiable options of the showdcl(8) command.

showdcl [-v] -a showdcl [-v] -d domain_id [-l lsb [-l lsb]]... showdcl -h

TABLE 3-3 Options of the showdcl Command

Option Description

-a Displays configuration information and status of all domains.

-v Displays detailed domain configuration information.

-h Displays usage information.

-d domain_id Displays information about the specified domain, where domain_id is

the domain number, possibly 0 to 23, depending on your server. Only one domain ID can be specified.

-l lsb Displays information about the specified logical system board (LSB), numbered 00 to 15. For information about multiple LSBs, list board numbers separated by a space. For example:

showdcl -l 00 -l 01.

TABLE 3-4 Items of Domain Information to be Displayed

Display items Description

DID Domain ID.

LSB Logical system board number.

XSB System board number.

Chapter 3 DR User Interface 3-3

Page 58

TABLE 3-4 Items of Domain Information to be Displayed (Continued)

Display items Description

Status Domain Status

Powered Off Domain power is off.

Initialization Phase

OpenBoot

POST processing or OpenBoot PROM initialization is in progress.

Initialization of OpenBoot PROM is completed. Executing Completed

Running Oracle Solaris OS is running.

Shutdown

Oracle Solaris OS is being shut down. Started

Panic State Oracle Solaris OS panic occurred.

No-mem Setting of omit-memory option

true Enabled: Oracle Solaris OS does not use memory

false Disabled: Oracle Solaris OS uses memory.

No-IO Setting of omit-IO option

true Enabled: Oracle Solaris OS does not use I/O device.

false Disabled: Oracle Solaris OS uses I/O device.

Float Setting of floating board option

true Enabled: Board is designated as a Floating board.

false Disabled: Board is not designated as Floating board.

Cfg-policy Setting of configuration policy

FRU Degradation in units of components.

XSB Degradation in units of XSB.

System Stopping of domain without degradation.

The table below lists the items displayed by the showdcl(8) command.

3-4 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 59

The following shows examples of displays by the showdcl(8) command.

■ Example 1: Display of information on domain #0

XSCF> showdcl -d 0 DID LSB XSB Status 00 Running

00 00-0 04 01-0 05 01-01 06 01-2 07 01-3 08 02-0

■ Example 2: Display of detailed information on domain #0

XSCF> showdcl -v -d 0 DID LSB XSB Status No-Mem No-IO Float Cfg-policy 00 Running FRU

00 00-0 False False False 01 02 03 04 01-0 False False False 05 01-1 False True False 06 01-2 False True True 07 01-3 True True True 08 02-0 True True True 09 10 11 -

3.1.2 Displaying Domain Status

The showdomainstatus(8) command lists the domains in the system and their status. This command displays the same domain status information as the showdcl(8) command.

Use the showdomainstatus(8) command to check domain status before and after a DR operation.

The following examples show the format and options of the showdomainstatus(8) command:

showdomainstatus -a showdomainstatus -d domain_id showdomainstatus -h

Chapter 3 DR User Interface 3-5

Page 60

TABLE 3-5 Options of the showdomainstatus Command

Option Description

-a Displays the status of all domains.

-d domain_id Displays information about the specified domain, where domain_id is

the domain number, possibly 0 to 23, depending on your server. Only one domain ID can be specified.

-h Displays usage information.

The table below lists the items displayed by the showdomainstatus(8) command.

TABLE 3-6 Items of Domain Information to be Displayed

Display items Description

DID Domain ID

Status Domain status

Powered Off Domain power is off.

Initialization Phase POST processing or OpenBoot PROM

initialization is in progress.

OpenBoot Executing Completed

Booting/OpenBoot PROM prompt

Running Oracle Solaris OS is running.

Shutdown Started Oracle Solaris OS is being shut down.

Panic State Oracle Solaris OS panic occurred.

Initialization by OpenBoot PROM is completed.

Oracle Solaris OS is being booted 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.

The following example shows a display of the showdomainstatus (8) command.

■ Example: Display of information on all domains

XSCF> showdomainstatus DID Domain Status 00 Running 01 Powered Off 02 03 Running

3-6 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 61

3.1.3 Displaying System Board Information

The showboards(8) command displays system board information including the domain ID of the domain to which the target system board belongs and various kinds of system board status in list format.

Use the showboards(8) command before a DR operation to determine whether the system board status permits DR operations, and to confirm the domain ID of the domain to which the target system board belongs. The showboards(8) command is also used after a DR operation to confirm system board status.

To change domain settings or register a system board in the DCL, use the setdcl(8) command. To change PSB settings, use the setupfru(8) command.

The following examples show the format and options of the showboards(8) command.

showboards [-v] -a [-c sp] showboards [-v] -d domain _id [-c sp] showboards [-v] xsb showboards -h

TABLE 3-7 Options of the showboards Command

Option Description

-v Displays detailed information about the system board.

-a Displays information about all mounted system boards.

-h Displays the usage information.

-d domain_id Displays information about the specified domain, where domain_id is

the domain number, possibly 0 to 23, depending on your server. Only one domain ID can be specified.

xsb Displays information about the specified XSB.

Specify xsb in the XX-Y format. (XX = 00 to 15, Y = 0 to 3). The value depends on your server.

-c sp Displays information about system boards in system board pool.

Chapter 3 DR User Interface 3-7

Page 62

The table below lists the items displayed by the showboards(8) command.

TABLE 3-8 Items of System Board Information to be Displayed

Display items Description

XSB System board number.

R Reservation status of a system board.

“*” is displayed for a system board when the board is reserved for addition, deletion, or a move.

DID (LSB) Domain ID of the domain into which the system board is added and

logical system board number “SP” is displayed for a system board that is in the system board pool.

Assignment Status of assignment to domain configuration

Unavailable The system board is in the system board pool (not

assigned to a domain) and its status is one of the following: not-yet diagnosed, under diagnosis, or diagnosis error. All system boards that are not mounted are also shown as Unavailable.

Available The system board is in the system board pool and its

diagnosis has completed normally.

Assigned The system board is assigned to the domain.

Pwr Power-on/off status of system board

nPower-off status.

The system board is powered off and cannot be used.

yPower-on status.

The system board is powered on.

Conn Status of connection to domain configuration

n Disconnected status.

The system board is disconnected from the relevant domain configuration or in the system board pool.

yConnected status.

The system board is connected to the relevant domain configuration.

Conf Status of addition into Oracle Solaris OS

nUnconfigured status.

The hardware resources of the system board have been deleted from the Oracle Solaris OS.

yConfigured status.

The hardware resources of the system board have been added into the Oracle Solaris OS.

3-8 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 63

TABLE 3-8 Items of System Board Information to be Displayed (Continued)

Display items Description

Test Diagnostic status of system board

Unmount The system board is not mounted or cannot be

recognized because it is faulty.

Unknown The system board is not being diagnosed.

Te st in g t es ti ng .

Passed The system board was tested, and passed.

Failed A system board error was tested, and failed.

The system board cannot be used or has been degraded.

Fault Normal/abnormal status of system board

Normal Normal.

Degraded Components have been degraded, but the system

board is operating. Degraded here means that a system board included in the corresponding component is faulty

Failed The system board cannot operate because of an error.

COD Indication of whether the system board is a COD board.

n The board is not a COD board.

y The board is a COD board.

The following examples show displays of the showboards(8) command

■ Example 1: Display of information on all system boards

XSCF> showboards -a XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

-----------------------------------------------------------------00-0 00(00) Assigned y y y Passed Normal 00-1 00(01) Assigned y n n Passed Degraded 00-2 SP Available y n n Unknown Normal 00-3 01(15) Assigned y y y Passed Normal

Chapter 3 DR User Interface 3-9

Page 64

■ Example 2: Display of detailed information on all system boards

XSCF> showboards -v -a XSB R DID(LSB) Assignment Pwr Conn Conf Test Fault COD

-------------------------------------------------------------------------00-0 00(00) Assigned y y y Passed Normal n 00-1 00(01) Assigned y n n Passed Degraded n 00-2 * SP Available y n n Unknown Normal n 00-3 01(15) Assigned y y y Passed Normal n

■ Example 3: Display of information on the system board in the system board pool

in domain #0

XSCF> showboards -c sp -d 0 XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

-----------------------------------------------------------------00-2 SP Available y n n Passed Normal

3.1.4 Displaying Device Information

Use the showdevices(8) command to display device information.

The showdevices(8) command displays information about the physical devices including CPUs, memory, and PCI cards mounted on system boards, and displays the hardware resources usable with these devices in hardware resource format. The showdevices(8) command is used before a DR operation to confirm information about and status of the hardware resources of the DR-target system board, and to determine the process to access the CPU and I/O devices.

Resource management applications or subsystems provide information concerning use of the hardware resources. A showdevices(8) command offline query about management target resources estimates the effect of each DR operation applied to the system boards and displays the results.

The following examples show the format and options of the showdevices(8) command.

showdevices [-v] [-p bydevice|byboard|query|force] xsb showdevices [-v] [-p bydevice|byboard] -d domain_id showdevices -h

Note – The showdevices(8) command only reports information about a running

domain.

3-10 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 65

Note – (Note 2) The showdevices(8) command will succeed only if the following

Oracle Solaris Service Management Facility (SMF) services are active on that domain:

- Domain SP Communication Protocol (dscp)

- Domain Configuration Server (dcs)

- Oracle Sun Cryptographic Key Management Daemon (sckmd).

TABLE 3-9 Options of the showdevices Command

Option Description

-v Specifies that the command displays information about all devices. Information about not only the management target devices but also

other devices is displayed. However, the displayed information includes resource information about the devices whose resources are managed and does not include resource information about the devices whose resources are not managed.

-p bydevice Specifies that the command display information about the devices mounted on a system board (CPU, memory, and I/O devices), sorted by device.

If neither -p bydevice nor -p byboard is specified, -p bydevice is the default.

-p byboard Specifies that the command display information about the devices mounted on system boards (CPU, memory, and I/O devices) by system board.

-p query Tests the detachability of the board by test-running the DR command without actually executing it.

-p force Tests the detachability of the board by test-running the DR command with the force flag without actually executing it.

xsb Specifies a system board (XSB) number. Specify xsb in the XX-Y

format. (XX = 00 to 15, Y = 0 to 3). The value depends on your server.

-d domain_id Specifies ID of the specified domain, where domain_id is the domain number, possibly 0 to 23, depending on your server. Only one domain ID can be specified.

Chapter 3 DR User Interface 3-11

Page 66

TABLE 3-10 Domain Information Displayed by the showdevices command

Display items Description

CPU CPU information.

DID Domain ID.

XSB System board number.

id CPU ID.

state CPU status.

speed CPU frequency (MHz).

ecache CPU cache size (Megabyte: MB).

usage Description of instance using resources.

Memory Memory information.

DID Domain ID

XSB System board number

board mem Size of memory on system board (MB).

perm mem Size of non-relocatable (kernel) memory on

system board (MB)

base address Base physical address of memory on system

board.

domain mem Size of memory in domain (MB).

target board System board number of the system board

whose kernel memory is drained.

deleted mem Size of already deleted memory (MB).

remaining mem Size of remaining memory to be deleted (MB).

IO Devices I/O device information.

DID Domain ID.

XSB System board number.

device Instance name and number of I/O device.

resource Management resource name.

usage Description of resource usage.

query Results of estimation with an offline query.

usage/reason Description of resource usage and reason for

the results of estimation with an offline query.

The following example shows a display by the showdevices(8) command.

3-12 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 67

■ Example: Display of device information on XSB00-0

XSCF> showdevices 00-0 CPU:

---DID XSB id state speed ecache 00 00-0 0 on-line 2048 4 00 00-0 1 on-line 2048 4

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 8192 2048 0x000003c000000000 65536

I/O 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.1.1.1

3.1.5 Displaying System Board Configuration Information

Use the showfru(8) command to display system board configuration information. The showfru(8) command displays information about the PSB division type and memory mirroring mode settings in list format.

To change the PSB configuration, use the setupfru(8) command.

The following examples show the format and options of the showfru(8) command.

showfru -a device showfru device location showfru -h

Chapter 3 DR User Interface 3-13

Page 68

TABLE 3-11 Options of the showfru Command

Option Description

-a Specifies that the command display all configuration information on devices of the type specified by devtype.

-h Displays usage information.

device Specifies a device type. Specify “sb” for DR.

location Specifies a device name. Specifies a physical system board (PSB)

number. Specify a decimal number from 00 to 15 for PSB. To display information about multiple system boards, several PSB numbers can be specified by delimiting each with a space. The range of PSB numbers to be specified varies depending on your server.

The table below lists the items displayed by the showfru(8) command.

TABLE 3-12 Items of System Board Configuration Information to be Displayed

Display items Description

Device Device type.

“sb” is the corresponding device for DR.

Location Mounting location of a device.

Displays a physical system board (PSB) number.

XSB Mode XSB division type.

Uni Uni-XSB (no division) mode.

Quad Quad-XSB: four-division mode.

Memory Mirror Mode

Memory mirror mode.

yes Memory mirror mode is enabled.

no Memory mirror mode is disabled.

The following example shows a display of the showfru(8) command.

■ Example: Display of configuration information on all system boards

XSCF> showfru -a sb Device Location XSB Mode Memory Mirror Mode sb 00 Quad yes sb 01 Quad yes sb 02 Quad no sb 03 Uni no

3-14 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 69

3.1.6 Adding a System Board

Use the addboard(8) command to add a system board to a domain or reserve the addition of a system board to a domain based on the DCL. The system board must already be registered in the target domain’s DCL.

Use the showdcl(8) command to check whether a system board is registered in the DCL. To register a system board in the DCL, use the setdcl(8) command.

Before executing the addboard(8) command, check the status of the DR-target domain and system board. You must determine whether you can perform the DR operation based on the status of the domain and system board.

The following examples show the format and options of the addboard(8) command.

addboard [[-q] -{y|n}] [-f] [-v] [-c configure] -d domain_id xsb [...] addboard [[-q] -{y|n}] [-f] [-v] -c assign -d domain_id xsb [...] addboard [[-q] -{y|n}] [-f] [-v] -c reserve -d domain_id xsb [...] addboard -h

TABLE 3-13 Options of the addboard Command

Option Description

-q Specifies the suppression of output message display.

-y or -n option determines how output messages are

The automatically answered, whether or not the messages themselves are suppressed (with the -q option) or displayed.

-y Specifies that a response of "yes" is made automatically to all output messages.

The -y or -n option determines how output messages are automatically answered, whether or not the messages themselves are suppressed (with the -q option) or displayed.

-n Specifies that a response of "no" is made automatically to all output messages.

The-y or -n option determines how output messages are automatically answered, whether or not the messages themselves are suppressed (with the -q option) or displayed.

-f Forcibly adds a system board that has not been diagnosed to a domain. This option for normal DR operations must not be used.

A faulty system board, or a system board where a fault is detected will not be forcibly added to the destination domain.

-v Displays the progress of this DR command. If the option is specified with the -q option, the -v option is

ignored.

Chapter 3 DR User Interface 3-15

Page 70

TABLE 3-13 Options of the addboard Command (Continued)

Option Description

-h Displays the usage information.

-c configure Specifies that the command add a system board to the domain. If no other -c option is specified, -c configure is the default.

-c assign Specifies that the command assign a system board to the domain.

With this option specified, the command assigns the target system board to the domain. The assigned system board is added to the domain when the addboard(8) command with the -c configure option specified is executed, and then the domain power is turned on or the domain rebooted.

-c reserve Specifies that the command reserve the addition of a system board to the domain.

With this option specified, the command executes the same processing as for the -c assign option, and it assigns the target system board to the domain. The assigned system board is added to the domain when the addboard(8) command with the -c configure option specified is executed, and then the domain power is turned on or the domain is rebooted.

-d domain_id Specifies the domain ID of the domain to add a system board, where domain_id is the domain number, possibly 0 to 23, depending on your

server. Only one domain ID can be specified.

xsb Specifies the system board (XSB) number of the system board to be

added. Specify xsb in the XX-Y format. (XX = 00 to 15, Y = 0 to 3). The value

depends on your server. To specify multiple system boards, several XSB numbers can be specified by delimiting each with a space.

Note – (Note 1) In the system board addition processing executed by this command,

a diagnosis of the system board to be added is performed first, and then the system board is added to the target domain. For this reason, much time may be required for the command to complete its operation.

Note – (Note 2) If DR processing by the addboard(8) command fails, the target

system board cannot be restored to its previous status. You must identify the cause of failure based on the error message output by the addboard(8) command and Oracle Solaris OS messages, and then take appropriate corrective action. Note that some errors require the domain to be rebooted.

3-16 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 71

Note – (Note 3) If a system board has been forcibly added to a domain by the

addboard(8) command with the -f option specified, normal operation of all added hardware resources may be disabled. For this reason, you should avoid using the -f option for normal DR operations. After adding a system board by using the addboard(8) command with the -f option specified, be sure to check the status of the added system board and the devices on the system board.

Note – (Note 4) You can execute the addboard(8) command on a domain that is not

running. When the domain is running, the addboard(8) command with "-c configure" will succeed only if the following Oracle Solaris Service Management

Facility (SMF) services are active on that domain:

- Domain SP Communication Protocol (dscp)

- Domain Configuration Server (dcs)

- Oracle Sun Cryptographic Key Management Daemon (sckmd)

3.1.7 Deleting a System Board

Use the deleteboard(8) command to delete a system board from a domain and assign it to the system board pool. If you specify the -c reserve option, the action takes place the next time the domain is powered off or rebooted.

Before executing the deleteboard(8) command, check the status of the target domain and system board, and the device usage status on the system board. You must determine whether you can perform the DR operation according to the status of the domains and system board, and the device usage status on the system board. You must also stop the processes that are bound to the CPU and the accessing of I/O devices to prepare for system board deletion. If the system board to be deleted is a kernel memory board, check the status and memory size of the system board to which kernel memory is to be moved.

The following examples show the format and options of the deleteboard(8) command.

deleteboard [[-q] -{y|n}] [-f] [-v] [-c disconnect] xsb [xsb...] deleteboard [[-q] -{y|n}] [-f] [-v] -c unassign xsb [xsb...] deleteboard [[-q] -{y|n}] [-f] [-v] -c reserve xsb [xsb...] deleteboard -h

Chapter 3 DR User Interface 3-17

Page 72

TABLE 3-14 Options of the deleteboard Command

Option Description

-q Specifies the suppression of output message display. The -y or -n option determines how output messages are

automatically answered, whether or not the messages themselves are suppressed (with the -q option) or displayed.

-y Specifies that a response of "yes" is made automatically to output messages.

The -y or -n option determines how output messages are automatically answered, whether or not the messages themselves are suppressed (with the -q option) or displayed.

-n Specifies that a response of "no" is made automatically to output messages.

The -y or -n option determines how output messages are automatically answered, whether or not the messages themselves are suppressed (with the-q option) or displayed.

-f Forcibly deletes a system board from the domain. This option for normal DR operations must not be used.

-v Displays the progress of this DR command. If the option is specified with the -q option, the -v option is ignored.

-h Displays the usage information.

-c disconnect Specifies that the command delete a system board from the domain

and set it in the status where it is assigned to the domain. This is a default option.

-c unassign Deletes the board and adds it to the system board pool. The command unconfigures and disconnects the system board from

the domain. If the board is in the state where it is assigned to the domain, the command unassigns the board from the domain and puts it in the system board pool. Also, if the domain power is off, the command similarly puts the board in the system board pool.

-c reserve Reserves the deletion of a system board from a domain. The system board is deleted from the domain and placed in the system board pool when the domain power is turned off or the domain is rebooted.

If the board is in the state where it is assigned to the domain, the command unassigns the board from the domain and places it in the system board pool. Also, if the domain power is off, the command similarly places the board in the system board pool.

xsb Specifies the system board (XSB) number of the system board to be

deleted. Specify xsb in the XX-Y format. (XX = 00 to 15, Y = 0 to 3). The value

depends on your server. To specify multiple system boards, several XSB numbers can be specified by delimiting each with a space.

3-18 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 73

Note – (Note 1) The time required for system board deletion processing depends on

the amount of hardware resources mounted on the target system board. For this reason, much time may be required for the command to end its operation. If the system board contains kernel memory, the OS is suspended for a while.

Note – (Note 2) If the DR processing executed by the deleteboard(8) command

fails, the target system board cannot be restored to the previous status. If DR processing fails, identify the cause of failure based on the error message output by the deleteboard(8) command and Oracle Solaris OS messages, and then take appropriate corrective action. Note that some errors require the domain to be rebooted.

Note – (Note 3) When a system board is forcibly deleted from a domain by the

deleteboard(8) command with the -f option specified, a serious problem may occur in a process that is bound to the CPU or in accessing an I/O device. For this reason, you should avoid using the -f option for normal DR operations. When using the deleteboard(8) command with the -f option specified, be sure to check the status of the domain and application processes.

Note – (Note 4) You can execute the deleteboard(8) command on a domain that is

not running. When the domain is running, the deleteboard(8) command with "-c disconnect" or "-c unassign" will succeed only if the following Oracle Solaris

Service Management Facility (SMF) services are active on that domain:

- Domain SP Communication Protocol (dscp)

- Domain Configuration Server (dcs)

- Oracle Sun Cryptographic Key Management Daemon (sckmd)

3.1.8 Moving a System Board

Use the moveboard(8) command to delete a system board from the move-source domain and add it to the move-destination domain, assign it to the move-destination domain, or reserve it to be moved later.

To execute the moveboard(8) command, the system board must have been configured in or assigned to the move-source domain, and be registered in the DCL for the move-destination domain.

Chapter 3 DR User Interface 3-19

Page 74

Use the showdcl(8) command to check whether a system board is registered in the DCL. To register a system board in the DCL, use the setdcl(8) command.

Before executing the moveboard(8) command, check the status of the move-source and move-destination domains and move-target system board, and the device usage status on the system board. You must determine whether you can perform the DR operation according to the status of the domains and system board, and the device usage status on the system board. You must also stop any processes that are bound to the CPU and any that are accessing I/O devices to prepare for system board deletion. If the system board to be deleted is a kernel memory board, check the status and memory size of the system board to which kernel memory is to be moved.

The following examples show the format and options of the moveboard(8) command.

moveboard [[-q] -{y|n}][-f][-v][-c configure] -d domain_id xsb[xsb...] moveboard [[-q] -{y|n}][-f][-v] -c assign -d domain_id xsb[xsb...] moveboard [[-q] -{y|n}][-f][-v] -c reserve -d domain_id xsb[xsb...] moveboard -h

TABLE 3-15 Options of the moveboard Command

Option Description

-q Specifies the suppression of output message display. The -y or -n option determines how output messages are

automatically answered, whether or not the messages themselves are suppressed (with the -q option) or displayed.

-y Specifies that a response of "yes" is made automatically to output messages.

The -y or -n option determines how output messages are automatically answered, whether or not the messages themselves are suppressed (with the -q option) or displayed.

-n Specifies that a response of "no" is made automatically to output messages.

The -y or -n option determines how output messages are automatically answered, whether or not the messages themselves are suppressed (with the -q option) or displayed.

-f Forcibly deletes a system board from the move-source domain and move it to the move-destination domain. This option for normal DR operations must not be used. A faulty system board, or a system board where a fault is detected will not be forcibly added to the destination domain.

-v Displays messages about the progress of this DR operation. If the option is specified with the -q option, the -v option is ignored.

-h Displays the usage information.

3-20 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 75

TABLE 3-15 Options of the moveboard Command (Continued)

Option Description

-c configure Specifies that the command delete a system board from the move-source domain and adds it to the move-destination domain.

If no other -c option is specified, -c configure is the default. The move operation from the move-source domain is performed

when the domain power is off or the Oracle Solaris OS is running in the move-source domain. However, if the domain power is off or the Oracle Solaris OS is not running in the move-destination domain, the move operation from the move-source domain is not performed and DR processing terminates with an error.

-c assign Specifies that the command delete a system board from the move-source domain and assign it to the move-destination domain.

The assigned system board is added to the move-destination domain when the addboard(8) command is executed in the move-destination domain, the power of the move-destination domain is turned on, or the move-destination domain is rebooted.

The move operation from the move-source domain is performed and the system board is set to the state where it is assigned to the move-destination domain when the domain power is off in both the move-source domain and the move-destination domain or the Oracle Solaris OS is not running in both domains.

-c reserve Specifies that the command reserve a system board move in the move-source domain.

The system board is deleted from the move-source domain and assigned to the move-destination domain when the power of move-source domain is turned off or the move-source domain rebooted. The assigned system board is added to the move-destination domain when the addboard(8) command is executed in the move-destination domain, the power of the move-destination domain is turned on, or the move-destination domain is rebooted.

The move operation from the move-source domain is performed and the system board is set to the state where it is assigned to the move-destination domain when the domain power is off or the Oracle Solaris OS is not running in the move-source domain.

-d domain_id Specifies the domain ID of the move-destination domain, where domain_id is the domain number, possibly 0 to 23, depending on your

server. Only one domain ID can be specified.

xsb Specifies the system board (XSB) number of the system board to be

moved. Specify xsb in the XX-Y format. (XX = 00 to 15, Y = 0 to 3). The value depends on your server. To specify multiple system boards, several XSB numbers can be specified by delimiting each with a space.

Chapter 3 DR User Interface 3-21

Page 76

Note – (Note 1) The time required for system board deletion processing in the

move-source domain depends on the amount of hardware resources mounted on the target system board. Moreover, in the system board addition processing in the move-destination domain, the system board to be added is first diagnosed, and then added to the domain. For this reason, much time may be required for the command to end its operation. Oracle Solaris OS is suspended for a while when the system board includes kernel memory.

Note – (Note 2) If the DR processing executed by the moveboard(8) command fails,

the target system board cannot be restored to the previous status. If DR processing fails, identify the cause of failure based on the error message output by the moveboard(8) command and Oracle Solaris OS messages in the move-source and move-destination domains, and then take appropriate corrective action. Note that some errors require one of the domains to be rebooted.

Note – (Note 3) When a system board is forcibly deleted from the move-source

domain by the moveboard(8) command with the -f option specified, a serious problem may occur in a process that is bound to the CPU or in accessing an I/O device. For this reason, you should avoid using the -f option for normal DR operations. When using the moveboard(8) command with the -f option specified, be sure to check the status of the move-source domain and application processes.

Note – (Note 4) You can execute the moveboard(8) command on a source domain

or a destination domain that is not running. When the source domain is running, the moveboard(8) command with "-c configure" or "-c assign" will succeed only if the following Oracle Solaris Service Management Facility (SMF) services are active on that domain:

- Domain SP Communication Protocol (dscp)

- Domain Configuration Server (dcs)

- Oracle Sun Cryptographic Key Management Daemon (sckmd)

3.1.9 Replacing a System Board

Use the deleteboard(8) and addboard(8) commands to replace a system board. Use them to replace, add, or delete such hardware resources as the CPU, memory, and I/O devices, or replace the PSB of a CMU or IOU.

3-22 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 77

Note – In a midrange server, you cannot use DR commands to replace a system

board. Instead, turn off the power of all domains, and then replace the target system board.

To replace a system board in a domain, first delete the target system board from the domain by using the deleteboard(8) command to make the PSB replaceable. Next, replace the PSB with a new one, and then add the target system board to the domain.

For details of the conditions and actions for executing the deleteboard(8) command, see Section 3.1.7, “Deleting a System Board” on page 3-17. For details of the conditions and actions for executing the addboard(8) command, see

Section 3.1.6, “Adding a System Board” on page 3-15.

Note – (Note 1) Before replacing a system board, you must know the division type

of the replacement-target PSB and the configurations and operation status of all domains to which all XSBs on the PSB belong. If the division type of the replacement-target PSB is Quad-XSB and the XSBs on the replacement-target PSB belong to multiple domains, you must consult with all administrators of the relevant domains in advance to adequately adjust the method of replacing the system board. If the division type of the replacement-target PSB is Uni-XSB, its replacement does not affect any other domains. However, prior adjustment may be required when the replacement-target system board is used as a floating board for multiple domains or hardware replacement work may affect other domains

Note – (Note 2) If the DR processing executed by the deleteboard(8) or

addboard(8) commands fails, the target system board cannot be restored its

previous status. Identify the cause of failure based on the error messages output by the commands and Oracle Solaris OS messages, and then take appropriate corrective action. Note that some errors require the domain to be rebooted.

Note – (Note 3) If a system board is forcibly deleted from a domain by the

deleteboard(8) command with the -f option specified, a serious problem may occur in a process bound to the CPU or accessing an I/O device. For this reason, you should avoid using the -f option in normal DR operations. If you must use the deleteboard(8) command with the -f option specified, be sure to check the status of the domain and application processes before and after execution.

Chapter 3 DR User Interface 3-23

Page 78

Note – (Note 4) To execute the addboard(8) command to add a system board by

DR, the system board must already be registered in DCL. Use the showdcl(8) command to check whether a system board is registered in the DCL. To register a system board in the DCL, use the setdcl(8) command.

To replace hardware, you must set the system board to the state where it is assigned to the domain or to the state where it is placed in the system board pool by using the deleteboard(8) command.

3-24 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 79

3.1.10 Reserving a Domain Configuration Change

Use the addboard(8), deleteboard(8), or moveboard(8) command to reserve a domain configuration change.

A domain configuration change is reserved when a system board cannot be added, deleted, or moved immediately for operational reasons. The reserved addition, deletion, or move of the system board is executed when the power of the target domain is turned on or off, or the domain rebooted. If a system board is placed in the system board pool, a domain configuration change can be reserved to assign the system board to the intended domain in advance, preventing the system board from being acquired by another domain.

To reserve the addition of a system board to a domain, use the addboard(8) command with the -c reserve option specified. The system board will be added to the domain when the domain power is turned on, the domain is rebooted, or the next time the addboard(8) command with the -c configure option specified is executed. For details about the addboard(8) command, see Section 3.1.6, “Adding a System

Board” on page 3-15.

To reserve the deletion of a system board from a domain, use the deleteboard(8) command with the -c reserve option specified. The system board will be deleted from the domain when the domain power is turned off, the domain is rebooted, or the next time the deleteboard(8) command with the -c disconnect or -c unassign option specified is executed. For details about the deleteboard(8) command, see Section 3.1.7, “Deleting a System Board” on page 3-17.

To reserve a system board move in a domain to another domain, use the moveboard(8) command with the -c reserve option specified. The system board will be deleted from the move-source domain and moved to the move-destination domain when the power of the move-source domain is turned off, the move-destination domain is rebooted, or the next time the moveboard(8) command with the -c configure or -c assign option specified is executed. For details about the moveboard(8) command, see Section 3.1.8, “Moving a System

Board” on page 3-19.

Chapter 3 DR User Interface 3-25

Page 80

3.2 Command Reference

This section lists the DR commands and other commands related to DR.

For details of the commands, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF Reference Manual. For the DR commands, see Section 3.1, “How To Use the DR User Interface” on page 3-1.

Note – (Note 1) Use of each command is restricted to selected administrators only. To use

each command, you must have appropriate administrator privileges. For details, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF Reference Manual.

Note – (Note 2) This section does not list all commands related to DR. For other DR-related

commands, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF Reference Manual.

TABLE 3-16 DR Display Commands

Command name Function

showdcl Displays the DCL and the domain status.

showdomainstatus Displays domain status.

showboards Displays system board information.

showdevices Displays information about the CPUs, memory, and I/O devices on

system boards.

showfru Displays PSB configuration information.

TABLE 3-17 DR Operation Commands

Command name Function

setdcl Updates and edits the DCL.

setupfru Sets the division type and memory mirror mode for PSB.

addboard Adds a system board into a domain.

deleteboard Deletes a system board from a domain.

moveboard Moves a system board between domains.

3-26 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 81

TABLE 3-18 DR-related Commands

Command name Function

poweron Turns on the power of all domains or a specified domain.

poweroff Turns off the power of all domains or a specified domain.

setdscp Configures DSCP network.

showdscp Displays the DSCP network configuration.

addfru Installs a Field Replaceable Unit (FRU).

deletefru Removes a Field Replaceable Unit (FRU).

replacefru Replaces a Field Replaceable Unit (FRU).

showhardconf Displays all components mounted in the server.

showstatus Lists degraded components.

showlog Displays an error log, power log, event log, console log, panic log,

3.3 XSCF Web

XSCF Web lets you execute DR functions from a browser. XSCF Web is beyond the scope of this document. For details, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.

IPL log, temperature/humidity log, and monitoring message log.

3.4 RCM Script

Reconfiguration Coordination Manager (RCM) is a framework used to manage the dynamic disconnection of system components. RCM provides script functions that enable you to write your own scripts for dynamic reconfiguration. Using RCM scripts enables you to avoid complicated DR operations (e.g., stopping applications and releasing devices from applications).

For details of how to register RCM scripts and script execution timing, see the Oracle Solaris man page for rcmscript(4).

Chapter 3 DR User Interface 3-27

Page 82

Note – (Note 1) An RCM script can only automate actions performed to prepare for

the deletion of a system board. When a system board is added to a domain, any actions required for use of the added resources must be manually performed.

Note – (Note 2) You should test the RCM scripts you create for DR before executing

the DR operations. The RCM scripts may not be able to execute certain processing.

3-28 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 83

CHAPTER

Practical Examples of DR

This chapter provides examples of DR operations, such as the addition, deletion, move, and replacement of system boards.

Each example shows an operation procedure using the command line interface of the XSCF shell. Similar procedures can also be applied to DR operations using the browser-based interface of the XSCF Web.

Note that the sections below explain only procedures such as those for checking the status of parts and devices for DR operations and not hardware operations (e.g., installing, removing, and replacing system boards). See the Service Manual for your server, as needed.

Note – If your server is configured with SPARC64 VII processors, some restrictions

regarding DR might apply. Please see Section 2.5.9, “SPARC64 VII+, SPARC64 VII,

and SPARC64 VI Processors and CPU Operational Modes” on page 2-30.

This chapter includes these sections:

■ Section 4.1, “Flow of DR Operation” on page 4-2

■ Section 4.2, “Example: Adding a System Board” on page 4-7

■ Section 4.3, “Example: Deleting a System Board” on page 4-9

■ Section 4.4, “Example: Moving a System Board” on page 4-11

■ Section 4.5, “Examples: Replacing a System Board” on page 4-13

■ Section 4.6, “Examples: Reserving Domain Configuration Changes” on page 4-20

4-1

Page 84

4.1 Flow of DR Operation

This section provides the flows of basic DR operations to add, delete, move, and replace system boards, along with flow diagrams.

4-2 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 85

4.1.1 Flow: Adding a System Board

Checking the domain status

The domain

Normal

Addition operation for

Addition processing of

Hardware

Power-on or restart

Error

Reserve operation

DR operation

Stop status

DR operation not operation possible

of the domain

possible, or

domain

configuration

to be changed

is operating.

Checking operation and selecting a DR operation

- Operation status and configuration of a domain

- Judgment of whether the DR operation can be performed

Checking the status of the system board to be added

Checking the device status

for adding a system board

not possible

maintenance

the system board

of the domain

the system board Change operation for the domain configuration

FIGURE 4-1 Flow: Adding a System Board

Chapter 4 Practical Examples of DR 4-3

Page 86

4.1.2 Flow: Deleting a System Board

Checking operation and

Checking the domain status

DR operation

The domain is

Checking the status of

DR operation

Deletion operation for

Deletion processing of

Reserve operation

Power-on or restart

DR operation

Stop status of

selecting a DR operation

- Operation status and configuration of a domain

- Judgment of whether the DR operation can be performed

possible

not possible,

or domain

configuration to be changed

not possible

operating.

a domain

the system board to be deleted Checking the device status

possible

operation not possible

for deleting a system board

the system board

of the domain

the system board Change operation for the domain configuration

FIGURE 4-2 Flow: Deleting a System Board

4-4 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 87

4.1.3 Flow: Moving a System Board

Checking operation and selecting

Confirmation of the move-source

Checking the status of the system

Move operation for the

Move processing of the system

DR operation

DR operation possible

Reserve operation for

Power-on or restart of

Addition operation for

DR operation

DR operation not

DR operation

Status of reserved addition in

a DR operation

- Operation status and

configuration

of the move-source domain

- Operation status and configuration of the move-destination domain

- Judgment of whether the DR operation can be performed

possible

possible, or domain

and move-destination domains and selecting an operation

configuration to be changed

not possible, or domain configuration to be changed

possible

not possible

board to be moved Checking the device status

moving a system board

the move-source domain

board Change operation for the move-

source and move-destination

domain configurations

the system board in the move-destination domain

the move-destination domain

system board

FIGURE 4-3 Flow: Moving a System Board

Chapter 4 Practical Examples of DR 4-5

Page 88

4.1.4 Flow: Replacing a System Board

Deletion reservation operation for the system

board in its domain

Checking operation and selecting a DR operation

Deletion reservation

Deletion DR

Power-off of

Hardware replacement

Stop status

Pooled

There is a domain for

There is no

Checking operation and selecting a DR operation

DR addition

Power-on of the

Start of

State of the domain

- Operation status and configuration of a domain

- Configuration of the system board to be replaced

- Checking the device status

of the

system

reservation deletion

operation for the system board in its domain

Deletion operation for

its domain

the system board in

of the domain

the relevant domain

which deletion has been reserved.

domain for which deletion has been reserved.

Deletion operation for

in its domain

the system board

domain

Start of domain

relevant domain

in operation

board

domain

- Adjustment between other domains

FIGURE 4-4 Flow: Replacing a System Board

4-6 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 89

4.2 Example: Adding a System Board

Domain#0

XSB#00-0

XSB#01-0

Add

Domain#0

XSB#00-0

XSB#01-0

This section provides an example of the DR operation to add a system board to a domain. In the example, a procedure conforming to section 4.1.1, "Flow: Adding a

System Board.", is used, and the system board shown in the figure is added by using

the XSCF shell.

FIGURE 4-5 Example: Adding a System Board

1. Login to XSCF.

2. Check the status of the domain.

Execute the showdcl(8) command to display domain information, and then check the operation status of the domain. Based on the operation status of the domain, determine whether to perform the DR operation or change the domain configuration.

3. Check the status of the system board to be added.

XSCF> showdcl -d 0 DID LSB XSB Status 00 Running

00 00-0 01 01-0

Execute the showboards(8) command to display system board information, and then check the status of the system board to be added and confirm its registration in the DCL.

Chapter 4 Practical Examples of DR 4-7

Page 90

If you need to change the PSB configuration, use the setupfru(8) command. If the system board to be added is not registered in the DCL, register the system board in the DCL of the target domain by using the setdcl(8) command.

XSCF> showboards -a XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

---------------------------------------------------------------00-0 00(00) Assigned y y y Passed Normal 01-0 SP Available y n n Passed Normal

4. Add the new system board.

Execute the addboard(8) command to add the system board to the move-destination domain.

XSCF> addboard -c configure -d 0 01-0

5. Check the status of the domain and added system board.

When the addboard(8) command ends normally, execute the showdcl(8) command to check the operation status of the domain, and then execute the showboards(8) command to check the status of the added system board.

If the addboard(8) command completes abnormally or leaves the board in an unwanted status, refer output messages to identify the problem, then correct it.

XSCF> showdcl -d 0 DID LSB XSB Status 00 Running

00 00-0

01 01-0

XSCF> showboards -d 0 XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

-----------------------------------------------------------------00-0 00(00) Assigned y y y Passed Normal 01-0 00(01) Assigned y y y Passed Normal

4-8 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 91

4.3 Example: Deleting a System Board

Domain#0

Delete

XSB#00-0

XSB#01-0

Domain#0

XSB#00-0

XSB#01-0

This section provides an example of operation to delete a system board from a domain. In the example, a procedure conforming to Section 4.1.2, “Flow: Deleting a

System Board” on page 4-4, is used, and the system board shown in the figure is

deleted using the XSCF shell.

FIGURE 4-6 Example: Deleting a System Board

1. Login to XSCF.

2. Check the status of the domain.

XSCF> showdcl -d 0 DID LSB XSB Status 00 Running

00 00-0 01 01-0

Chapter 4 Practical Examples of DR 4-9

Page 92

3. Check the status of the system board to be deleted.

Execute the showboards(8) command to display system board information, and then check the status of the system board to be deleted.

XSCF> showboards -a XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

------------------------------------------------------------------00-0 00(00) Assigned y y y Passed Normal 01-0 00(01) Assigned y y y Passed Normal

4. Delete the system board.

Execute the deleteboard(8) command to delete the system board and pool it in the system board pool.

XSCF> deleteboard -c unassign 01-0

5. Check the status of the domain and deleted system board.

When the deleteboard(8) command ends normally, execute the showdcl(8) command to check the operation status of the domain, and then execute the showboards(8) command to check the status of the deleted system board.

If the deleteboard(8) command completes abnormally or leaves the board in an unwanted status, refer output messages to identify the problem, then correct it.

XSCF> showdcl -d 0 DID LSB XSB Status 00 Running

00 00-0 01 01-0

XSCF> showboards -a XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

---------------------------------------------------------------00-0 00(00) Assigned y y y Passed Normal 01-0 SP Available y n n Passed Normal

4-10 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 93

4.4 Example: Moving a System Board

Domain#0

XSB#00-0

XSB#01-0

XSB#00-1

Domain#1

Move

Domain#0

XSB#00-0

XSB#01-0

XSB#00-1

Domain#1

This section provides an example of an operation to move a system board between domains. In the example, a procedure conforming to Section 4.1.3, “Flow: Moving a

System Board” on page 4-5, is used, and the system board shown in the figure is

moved using the XSCF shell.

FIGURE 4-7 Example: Moving a System Board

1. Login to XSCF.

2. Check the status of the move-source domain.

Execute the showdcl(8) command to display domain information, and then check the operation status of the move-source domain.

XSCF> showdcl -d 0 DID LSB XSB Status 00 Running

00 00-0 01 00-1

3. Check the status of the move-destination domain.

Execute the showdcl(8) command to display domain information, and then check the operation status of the move-destination domain. Based on the operation status of the move-source and move-destination domains, determine whether to perform the DR operation or change the domain configuration.

XSCF> showdcl -d 1 DID LSB XSB Status 01 Running

00 01-0 01 00-1

Chapter 4 Practical Examples of DR 4-11

Page 94

4. Check the status of the system board to be moved.

Execute the showboards(8) command to display system board information, and then check the status of the system board to be moved.

XSCF> showboards 00-1 XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

---- -------- ----------- ---- ---- ---- ------- --------------00-1 00(01) Assigned y y y Passed Normal

5. Move the system board.

Execute the moveboard(8) command to delete the system board from the move-source domain and add it to the move-destination domain.

XSCF> moveboard -c configure -d 1 00-1

6. Check the status of the move-source domain.

When the moveboard(8) command ends normally, execute the showdcl(8) command to display and check the operation status of the move-source domain.

If the moveboard(8) command completes abnormally or leaves the board in an unwanted status, refer output messages to identify the problem, then correct it.

XSCF> showdcl -d 0 DID LSB XSB Status 00 Running

00 00-0 01 00-1

7. Check the status of the move-destination domain and moved system board.

Execute the showdcl(8) command to check the operation status of the move-destination domain, and then execute the showboards(8) command to check the status of the moved system board.

XSCF> showdcl -d 1 DID LSB XSB Status 01 Running

00 01-0 01 00-1

XSCF> showboards 00-1 XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

------------------------------------------------------------------00-1 01(01) Assigned y y y Passed Normal

4-12 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 95

4.5 Examples: Replacing a System Board

Domain#0

XSB#00-0

XSB#01-0

Delete

Faulty

New

Replace

Add

system board

This section provides examples of operations to replace a system board in a domain. The examples illustrate replacement of a system board in a Uni-XSB environment and a system board in a Quad-XSB environment. In each sample operation, a procedure conforming to Section 4.1.4, “Flow: Replacing a System Board” on

page 4-6, is used, and the system board shown in each figure is replaced using the

XSCF shell.

Note – You cannot use DR to replace a system board in a midrange server because

replacing a system board replaces an MBU. To replace a system board in a midrange server, you must turn off the power for all domains, then perform a hardware replacement.

4.5.1 Example: Replacing a Uni-XSB System Board

FIGURE 4-8 Example: Replacing a Uni-XSB System Board

1. Login to XSCF.

Chapter 4 Practical Examples of DR 4-13

Page 96

2. Check the status of the domain.

XSCF> showdcl -d 0 DID LSB XSB Status 00 Running

00 00-0 01 01-0

3. Check the status of the system board to be replaced.

Execute the showboards(8) command to display system board information, and then check the status of the system board to be deleted. The DR operation for replacement may not be possible if the board to be replaced does not support the DR delete operation.

XSCF> showboards 01-0 XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

----------------------------------------------------------------01-0 00(01) Assigned y y y Passed Normal

4. Delete the system board.

Execute the deleteboard(8) command to delete the system board.

XSCF> deleteboard -c disconnect 01-0

5. Check the status of the system board.

Execute the showboards(8) command to display system board information, and then check the status of the system board.

XSCF> showboards 01-0 XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

----------------------------------------------------------------01-0 00(01) Assigned y n n Passed Normal

6. Physically replace the system board.

Execute the replacefru(8) command, then follow the displayed instructions to replace the system board per the Active Replacement procedure. For information about Active Replacement, see the Service Manual for your server.

XSCF> replacefru

4-14 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 97

7. Check the status of the replaced system board.

Execute the showboards(8) command to display system board information, and then check the status of all related system boards and confirm their registration in the DCL.

If necessary to change the system board configuration (e.g., number of divisions), do so by using the setupfru(8) command. If the system board is not registered in the DCL, register it in the DCL for the target domain by using the setdcl(8) command.

XSCF> showboards 01-0 XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

----------------------------------------------------------------01-0 00(01) Assigned y n n Passed Normal

8. Check the status of the domain.

XSCF> showdcl -d 0 DID LSB XSB Status 00 Running

00 00-0 01 01-0

9. Add the new system board to the domain.

Execute the addboard(8) command to add the system board to the move-destination domain.

XSCF> addboard -c configure -d 0 01-0

10. Check the status of the domain and added system board.

If the addboard(8) command completes abnormally or leaves the board in an unwanted status, see the output messages to identify the problem, then correct it.

XSCF> showdcl -d 0 DID LSB XSB Status 00 Running

00 00-0 01 01-0

Chapter 4 Practical Examples of DR 4-15

Page 98

XSCF> showboards 01-0

Domain#0

XSB#00-0

Domain#1

XSB#01-0

XSB#01-1

XSB#01-2

XSB#01-3

Faulty

system

board

New system board

Replace

Delete

Add

XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

----------------------------------------------------------------01-0 00(01) Assigned y y y Passed Normal

4.5.2 Example: Replacing a Quad-XSB System Board

FIGURE 4-9 Example: Replacing a Quad-XSB System Board

1. Login to XSCF.

4-16 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Page 99

2. Check the configurations and status of all domains to which the relevant system boards belong.

Execute the showdcl(8) command to display domain information, and then check the configurations and operation status of all domains to which the relevant XSBs belong.

Based on the configurations and operation status of the domains, determine whether to perform the DR operation or replace the replacement-target system board after stopping the domains. If a domain is configured by only the XSBs in the PSB to be replaced, the DR operation for replacement is disabled, and the domain must be stopped for replacement.

In this example, domain #1 has a configuration that requires it to be stopped for system board replacement.

XSCF> showdcl -a DID LSB XSB Status 00 Running

00 00-0 01 01-0 02 01-1

------01 Running

00 01-2 01 01-3

3. Check the status of all related system boards.

Execute the showboards(8) command to display system board information, and then check the status of all system boards related to the PSB to be replaced. The DR operation for replacement may not be possible if the board to be replaced does not support the DR delete operation.

XSCF> showboards -a XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

----------------------------------------------------------------00-0 00(00) Assigned y y y Passed Normal 01-0 00(01) Assigned y y y Passed Normal 01-1 00(02) Assigned y y y Passed Normal 01-2 01(00) Assigned y y y Passed Normal 01-3 01(01) Assigned y y y Passed Normal

4. Delete all system boards related to the CMU to be replaced.

Execute the deleteboard(8) command to delete the system boards, and then assign the boards to a domain that permits the DR operation.

XSCF> deleteboard -c disconnect 01-0 01-1

Chapter 4 Practical Examples of DR 4-17

Page 100

5. Power off Domain #1 so the CMU can be replaced.

Execute the poweroff(8) command so that the CMU being replaced will not be in use by domain #1.

XSCF> poweroff -d 1

6. Check the status of all related system boards.

Execute the showboards(8) command to display system board information, and then check the status of all related system boards.

XSCF> showboards -a XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

-----------------------------------------------------------------00-0 00(00) Assigned y y y Passed Normal 01-0 00(01) Assigned y n n Passed Normal 01-1 00(02) Assigned y n n Passed Normal 01-2 01(00) Assigned y n n Passed Normal 01-3 01(01) Assigned y n n Passed Normal

7. Physically replace the system board.

XSCF> replacefru

8. Check the status of the replaced system board.

Execute the showboards(8) command to display system board information, and then check the status of the system board to be added and confirm its registration in the DCL.

If you need to change the PSB configuration, use the setupfru(8) command. If the system board is not registered in the DCL, register it in the DCL for the target domain by using the setdcl(8) command.

XSCF> showboards -a XSB DID(LSB) Assignment Pwr Conn Conf Test Fault

-------------------------------------------------------------------00-0 00(00) Assigned y y y Passed Normal 01-0 00(01) Assigned y n n Passed Normal 01-1 00(02) Assigned y n n Passed Normal 01-2 01(00) Assigned y n n Passed Normal 01-3 01(01) Assigned y n n Passed Normal

4-18 SPARC Enterprise Mx000 Servers Dynamic Reconfiguration User’s Guide • January 2012

Fujitsu SPARC Enterprise M4000, SPARC Enterprise M5000, SPARC Enterprise M8000, SPARC Enterprise M9000 Features Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Contents

Preface

Audience

Related Documentation

Text Conventions

Syntax of the Command-Line Interface (CLI)

Documentation Feedback

Overview of Dynamic Reconfiguration

1.1 DR

1.2 Basic DR Functions

1.2.1 Adding a System Board

1.2.2 Deleting a System Board

1.2.3 Moving a System Board

1.2.4 Replacing a System Board

1.3 Security

1.4 Overview of DR User Interfaces

What You Must Know Before Using DR

2.1 System Configuration

2.1.1 System Board Components

2.1.1.1 CPU

2.1.1.2 Memory

2.1.1.3 I/O Device

2.1.2 System Board Configuration Requirements

2.1.3 System Board Pool Function

2.1.4 Checklists for System Configuration

2.1.5 Reservation of Domain Configuration Changes

2.2 Conditions and Settings Using XSCF

2.2.1 Conditions Using XSCF

2.2.2 Settings Using XSCF

2.2.2.1 Configuration Policy Option

2.2.2.2 Floating Board Option

2.2.2.3 Omit-memory Option

2.2.2.4 Omit-I/O Option

2.3 Conditions and Settings Using Oracle Solaris OS

2.3.1 I/O and Software Requirements

2.3.2 Settings of Kernel Cage Memory

2.3.3 Setting of Oracle Solaris Service Management Facility (SMF)

2.4 Status Management

2.4.1 Domain Status

2.4.2 System Board Status

2.4.3 Flow of DR Processing

2.4.3.1 Flowchart: Adding a System Board

2.4.3.2 Flowchart: Deleting a System Board

2.4.3.3 Flowchart: Moving a System Board

2.4.3.4 Flowchart: Replacing System Board

2.5 Operation Management

2.5.1 I/O Device Management

2.5.2 Swap Area

2.5.2.1 Swap Area at System Board Addition

2.5.2.2 Swap Area at System Board Deletion

2.5.3 Real-time Processes

2.5.4 Memory Mirror Mode

2.5.5 Capacity on Demand (COD)

2.5.6 XSCF Failover

2.5.7 Kernel Memory Board Deletion

2.5.8 Deletion of Board with CD-RW/DVD-RW Drive

2.5.9 SPARC64 VII+, SPARC64 VII, and SPARC64 VI Processors and CPU Operational Modes

2.5.9.1 CPU Operational Modes

DR User Interface

3.1 How To Use the DR User Interface

3.1.1 Displaying Domain Information

3.1.2 Displaying Domain Status

3.1.3 Displaying System Board Information

3.1.4 Displaying Device Information

3.1.5 Displaying System Board Configuration Information

3.1.6 Adding a System Board

3.1.7 Deleting a System Board

3.1.8 Moving a System Board

3.1.9 Replacing a System Board

3.1.10 Reserving a Domain Configuration Change

3.2 Command Reference

3.3 XSCF Web

3.4 RCM Script

Practical Examples of DR

4.1 Flow of DR Operation

4.1.1 Flow: Adding a System Board