Cisco UCS Manager Infrastructure Management Using the CLI, Release 3.1

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Book Contents

Find Matches in This Book

Available Languages

Download Options

Book Title

Cisco UCS Manager Infrastructure Management Using the CLI, Release 3.1

Chapter Title

Blade Server Hardware Management

PDF - Complete Book (3.8 MB) PDF - This Chapter (1.39 MB)
View with Adobe Reader on a variety of devices
ePub - Complete Book (1.12 MB)
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi - Complete Book (1.75 MB)
View on Kindle device or Kindle app on multiple devices

Results

Updated:: April 27, 2017

Chapter: Blade Server Hardware Management

Blade Server Hardware Management

Blade Server Management
Guidelines for Removing and Decommissioning Blade Servers
Recommendations for Avoiding Unexpected Server Power Changes
Booting a Blade Server
Shutting Down a Blade Server
Resetting a Blade Server to Factory Default Settings
Power Cycling a Blade Server
Performing a Hard Reset on a Blade Server
Acknowledging a Blade Server
Removing a Blade Server from a Chassis
Decommissioning a Blade Server
Turning On the Locator LED for a Blade Server
Turning Off the Locator LED for a Blade Server
Resetting the CMOS for a Blade Server
Resetting the CIMC for a Blade Server
Clearing TPM for a Blade Server
Issuing an NMI from a Blade Server
Health LED Alarms
Smart SSD

Blade Server Management

You can manage and monitor all blade servers in a Cisco UCS domain through Cisco UCS Manager. You can perform some blade server management tasks, such as changes to the power state, from the server and service profile.

The remaining management tasks can only be performed on the server.

The power supply units go into power save mode when a chassis has two blades or less. When a third blade is added to the chassis and is fully discovered, the power supply units return to regular mode.

If a blade server slot in a chassis is empty, Cisco UCS Manager provides information, errors, and faults for that slot. You can also re-acknowledge the slot to resolve server mismatch errors and to have Cisco UCS Manager rediscover the blade server in the slot.

Guidelines for Removing and Decommissioning Blade Servers

Consider the following guidelines when deciding whether to remove or decommission a blade server using Cisco UCS Manager:

Decommissioning a Blade Server

If you want to temporarily decommission a physically present and connected blade server, you can temporarily remove it from the configuration. A portion of the server's information is retained by Cisco UCS Manager for future use, in case the blade server is recommissioned.

Removing a Blade Server

Removing is performed when you physically remove a blade server from the Cisco UCS Manager by disconnecting it from the chassis. You cannot remove a blade server from Cisco UCS Manager if it is physically present and connected to a chassis. After the physical removal of the blade server is completed, the configuration for that blade server can be removed in Cisco UCS Manager.

During removal, active links to the blade server are disabled, all entries from databases are removed, and the server is automatically removed from any server pools that it was assigned to during discovery.

Note

Only servers added to a server pool automatically during discovery are removed automatically. Servers that were manually added to a server pool must be removed manually.

To add a removed blade server back to the configuration, it must be reconnected, then rediscovered. When a server is reintroduced to Cisco UCS Manager, it is treated as a new server and is subject to the deep discovery process. For this reason, it is possible for Cisco UCS Manager to assign the server a new ID that might be different from the ID that it held before.

Recommendations for Avoiding Unexpected Server Power Changes

If a server is not associated with a service profile, you can use any available means to change the server power state, including the physical Power or Reset buttons on the server.

If a server is associated with, or assigned to, a service profile, you should only use the following methods to change the server power state:

In Cisco UCS Manager GUI, go to the General tab for the server or the service profile associated with the server and select Boot Server or Shutdown Server from the Actions area.
In Cisco UCS Manager CLI, scope to the server or the service profile associated with the server and use the power up or power down commands.

Important:

Do not use any of the following options on an associated server that is currently powered off:

Reset in the GUI
cycle cycle-immediate or reset hard-reset-immediate in the CLI
The physical Power or Reset buttons on the server

If you reset, cycle, or use the physical power buttons on a server that is currently powered off, the server's actual power state might become out of sync with the desired power state setting in the service profile. If the communication between the server and Cisco UCS Manager is disrupted or if the service profile configuration changes, Cisco UCS Manager might apply the desired power state from the service profile to the server, causing an unexpected power change.

Power synchronization issues can lead to an unexpected server restart, as shown below:

Desired Power State in Service Profile

Current Server Power State

Server Power State After Communication Is Disrupted

Powered Off

Powered On

Down

Powered On

Note

Running servers are not shut down regardless of the desired power state in the service profile.

Booting a Blade Server

Before You Begin

Associate a service profile with a blade server or server pool.

Procedure

	Command or Action	Purpose
Step 1	UCS-A# scope org org-name	Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name .
Step 2	UCS-A /org # scope service-profile profile-name	Enters organization service profile mode for the specified service profile.
Step 3	UCS-A /org/service-profile # power up	Boots the blade server associated with the service profile.
Step 4	UCS-A /org/service-profile # commit-buffer	Commits the transaction to the system configuration.

The following example boots the blade server associated with the service profile named ServProf34 and commits the transaction:

UCS-A# scope org /
UCS-A /org* # scope service-profile ServProf34
UCS-A /org/service-profile* # power up
UCS-A /org/service-profile* # commit-buffer
UCS-A /org/service-profile #

Shutting Down a Blade Server

When you use this procedure to shut down a server with an installed operating system, Cisco UCS Manager triggers the OS into a graceful shutdown sequence.

Note

When a blade server that is associated with a service profile is shut down, the VIF down alerts F0283 and F0479 are automatically suppressed.

Before You Begin

Associate a service profile with a blade server or server pool.

Procedure

	Command or Action	Purpose
Step 1	UCS-A# scope org org-name	Enters organization mode for the specified organization. To enter the root organization mode, type / as the `org-name`.
Step 2	UCS-A /org # scope service-profile profile-name	Enters organization service profile mode for the specified service profile.
Step 3	UCS-A /org/service-profile # power down	Shuts down the blade server associated with the service profile.
Step 4	UCS-A /org/service-profile # commit-buffer	Commits the transaction to the system configuration.

The following example shuts down the blade server associated with the service profile named ServProf34 and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope service-profile ServProf34
UCS-A /org/service-profile # power down
UCS-A /org/service-profile* # commit-buffer
UCS-A /org/service-profile #

Resetting a Blade Server to Factory Default Settings

You can now reset a blade server to its factory settings. By default, the factory reset operation does not affect storage drives and flexflash drives. This is to prevent any loss of data. However, you can choose to reset these devices to a known state as well.

Important:

Resetting storage devices will result in loss of data.

Perform the following procedure to reset the server to factory default settings.

Procedure

Command or Action

Purpose

Step 1

UCS-A# scope server [chassis-num/server-num | dynamic-uuid]

Enters server mode for the specified server.

Step 2

UCS-A /chassis/server # reset factory-default [delete-flexflash-storage | delete-storage [create-initial-storage-volumes] ]

Resets server settings to factory default using the following command options:

factory-default—Resets the server to factory defaults without deleting storage
delete-flexflash-storage—Resets the server to factory defaults and deletes flexflash storage
delete-storage—Resets the server to factory defaults and deletes all storage
create-initial-storage-volumes—Resets the server to factory defaults, deletes all storage, sets all disks to their initial state

Important:
Do not use the create-initial-storage-volumes command option if you want to use storage profiles. Creating initial volumes when you are using storage profiles may result in configuration errors.

Step 3

UCS-A /chassis/server* # commit-buffer

Commits any pending transactions.

The following example resets the server settings to factory default without deleting storage, and commits the transaction:

UCS-A# scope server 2/4
UCS-A /chassis/server # reset factory-default
UCS-A /chassis/server* # commit-buffer

The following example resets the server settings to factory default, deletes flexflash storage, and commits the transaction:

UCS-A# scope server 2/4
UCS-A /chassis/server # reset factory-default delete-flexflash-storage

UCS-A /chassis/server* # commit-buffer

The following example resets the server settings to factory default, deletes all storage, and commits the transaction:

UCS-A# scope server 2/4
UCS-A /chassis/server # reset factory-default delete-storage
UCS-A /chassis/server* # commit-buffer

The following example resets the server settings to factory default, deletes all storage, sets all disks to their initial state, and commits the transaction:

UCS-A# scope server 2/4
UCS-A /chassis/server # reset factory-default delete-storage create-initial-storage-volumes
UCS-A /chassis/server* # commit-buffer

Power Cycling a Blade Server

Procedure

	Command or Action	Purpose
Step 1	UCS-A# scope server chassis-num / server-num	Enters chassis server mode for the specified blade server.
Step 2	UCS-A /chassis/server # cycle {cycle-immediate \| cycle-wait}	Power cycles the blade server. Use the cycle-immediate keyword to immediately begin power cycling the blade server; use the cycle-wait keyword to schedule the power cycle to begin after all pending management operations have completed.
Step 3	UCS-A# commit-buffer	Commits the transaction to the system configuration.

Command or Action

Purpose

Step 1

UCS-A# scope server chassis-num / server-num

Enters chassis server mode for the specified blade server.

Step 2

UCS-A /chassis/server # cycle {cycle-immediate | cycle-wait}

Power cycles the blade server.

Use the cycle-immediate keyword to immediately begin power cycling the blade server; use the cycle-wait keyword to schedule the power cycle to begin after all pending management operations have completed.

Step 3

UCS-A# commit-buffer

Commits the transaction to the system configuration.

The following example immediately power cycles blade server 4 in chassis 2 and commits the transaction:

UCS-A#  scope server 2/4
UCS-A /chassis/server # cycle cycle-immediate
UCS-A /chassis/server* # commit-buffer
UCS-A /chassis/server #

Performing a Hard Reset on a Blade Server

When you reset a server, Cisco UCS Manager sends a pulse on the reset line. You can choose to gracefully shut down the operating system. If the operating system does not support a graceful shutdown, the server is power cycled. The option to have Cisco UCS Manager complete all management operations before it resets the server does not guarantee the completion of these operations before the server is reset.

Note

If you are trying to boot a server from a power-down state, you should not use Reset.

If you continue the power-up with this process, the desired power state of the servers become out of sync with the actual power state and the servers might unexpectedly shut down at a later time. To safely reboot the selected servers from a power-down state, click Cancel, then select the Boot Server action.

Procedure

	Command or Action	Purpose
Step 1	UCS-A# scope server chassis-num / server-num	Enters chassis server mode for the specified server.
Step 2	UCS-A /chassis/server # reset {hard-reset-immediate \| hard-reset-wait}	Performs a hard reset of the blade server. Use the hard-reset-immediate keyword to immediately begin hard resetting the server; use the hard-reset-wait keyword to schedule the hard reset to begin after all pending management operations have completed.
Step 3	UCS-A /server # commit-buffer	Commits the transaction to the system configuration.

Command or Action

Purpose

Step 1

UCS-A# scope server chassis-num / server-num

Enters chassis server mode for the specified server.

Step 2

UCS-A /chassis/server # reset {hard-reset-immediate | hard-reset-wait}

Performs a hard reset of the blade server.

Use the hard-reset-immediate keyword to immediately begin hard resetting the server; use the hard-reset-wait keyword to schedule the hard reset to begin after all pending management operations have completed.

Step 3

UCS-A /server # commit-buffer

Commits the transaction to the system configuration.

The following example performs an immediate hard reset of blade server 4 in chassis 2 and commits the transaction:

UCS-A#  scope server 2/4
UCS-A /chassis/server # reset hard-reset-immediate
UCS-A /chassis/server* # commit-buffer
UCS-A /chassis/server #

Acknowledging a Blade Server

Perform the following procedure to rediscover the server and all endpoints in the server. For example, you can use this procedure if a server is stuck in an unexpected state, such as the discovery state.

Procedure

	Command or Action	Purpose
Step 1	UCS-A# acknowledge server chassis-num / server-num	Acknowledges the specified blade server.
Step 2	UCS-A# commit-buffer	Commits the transaction to the system configuration.

The following example acknowledges server 4 in chassis 2 and commits the transaction:

UCS-A#  acknowledge server 2/4
UCS-A* # commit-buffer
UCS-A #

Removing a Blade Server from a Chassis

Before You Begin

Procedure

	Command or Action	Purpose
Step 1	UCS-A# remove server chassis-num / server-num	Removes the specified blade server.
Step 2	UCS-A# commit-buffer	Commits the transaction to the system configuration.
Step 3	Go to the physical location of the chassis and remove the server hardware from the slot.	For instructions on how to remove the server hardware, see the Cisco UCS Hardware Installation Guide for your chassis.

The following example removes blade server 4 in chassis 2 and commits the transaction:

UCS-A#  remove server 2/4
UCS-A* # commit-buffer
UCS-A #

What to Do Next

If you physically re-install the blade server, you must re-acknowledge the slot for the Cisco UCS Manager to rediscover the server.

For more information, see Acknowledging a Blade Server.

Decommissioning a Blade Server

Procedure

	Command or Action	Purpose
Step 1	UCS-A# decommission server chassis-num / server-num	Decommissions the specified blade server.
Step 2	UCS-A# commit-buffer	Commits the transaction to the system configuration.

The following example decommissions blade server 4 in chassis 2 and commits the transaction:

UCS-A# decommission server 2/4
UCS-A* # commit-buffer
UCS-A #

Turning On the Locator LED for a Blade Server

Procedure

Command or Action

Purpose

Step 1

UCS-A# scope server chassis-num / server-num

Enters chassis server mode for the specified chassis.

Step 2

UCS-A /chassis/server # enable locator-led [multi-master | multi-slave]

Turns on the blade server locator LED. For the Cisco UCS B460 M4 blade server, you can add the following keywords:

multi-master—Turns on the LED for the master node only.
multi-slave—Turns on the LED for the slave node only.

Step 3

UCS-A /chassis/server # commit-buffer

Commits the transaction to the system configuration.

The following example turns on the locator LED on blade server 4 in chassis 2 and commits the transaction:

UCS-A# scope server 2/4
UCS-A /chassis/server # enable  locator-led
UCS-A /chassis/server* # commit-buffer
UCS-A /chassis/server #

The following example turns on the locator LED for the master node only on blade server 7 in chassis 2 and commits the transaction:

UCS-A# scope chassis 2/7
UCS-A /chassis/server # enable locator-led multi-master
UCS-A /chassis/server* # commit-buffer
UCS-A /chassis/server #

Turning Off the Locator LED for a Blade Server

Procedure

	Command or Action	Purpose
Step 1	UCS-A# scope server chassis-num / server-num	Enters chassis mode for the specified chassis.
Step 2	UCS-A /chassis/server # disable locator-led [multi-master \| multi-slave]	Turns off the blade server locator LED. For the Cisco UCS B460 M4 blade server, you can add the following keywords: multi-master—Turns off the LED for the master node only. multi-slave—Turns off the LED for the slave node only.
Step 3	UCS-A /chassis/server # commit-buffer	Commits the transaction to the system configuration.

Command or Action

Purpose

Step 1

UCS-A# scope server chassis-num / server-num

Enters chassis mode for the specified chassis.

Step 2

UCS-A /chassis/server # disable locator-led [multi-master | multi-slave]

Turns off the blade server locator LED. For the Cisco UCS B460 M4 blade server, you can add the following keywords:

multi-master—Turns off the LED for the master node only.
multi-slave—Turns off the LED for the slave node only.

Step 3

UCS-A /chassis/server # commit-buffer

Commits the transaction to the system configuration.

The following example turns off the locator LED on blade server 4 in chassis 2 and commits the transaction:

UCS-A# scope chassis 2/4
UCS-A /chassis/server # disable locator-led
UCS-A /chassis/server* # commit-buffer
UCS-A /chassis/server #

The following example turns off the locator LED for the master node on blade server 7 in chassis 2 and commits the transaction:

UCS-A# scope chassis 2/7
UCS-A /chassis/server # disable locator-led multi-master
UCS-A /chassis/server* # commit-buffer
UCS-A /chassis/server #

Resetting the CMOS for a Blade Server

Sometimes, troubleshooting a server might require you to reset the CMOS. Resetting the CMOS is not part of the normal maintenance of a server.

Procedure

	Command or Action	Purpose
Step 1	UCS-A# scope server chassis-num / server-num	Enters chassis server mode for the specified chassis.
Step 2	UCS-A /chassis/server # reset-cmos	Resets the CMOS for the blade server.
Step 3	UCS-A /chassis/server # commit-buffer	Commits the transaction to the system configuration.

The following example resets the CMOS for blade server 4 in chassis 2 and commits the transaction:

UCS-A# scope server 2/4
UCS-A /chassis/server # reset-cmos
UCS-A /chassis/server* # commit-buffer
UCS-A /chassis/server #

Resetting the CIMC for a Blade Server

Sometimes, with the firmware, troubleshooting a server might require you to reset the CIMC. Resetting the CIMC is not part of the normal maintenance of a server. After you reset the CIMC, the server boots with the running version of the firmware for that server.

If the CIMC is reset, the power monitoring functions of Cisco UCS become briefly unavailable until the CIMC reboots. Typically, the reset only takes 20 seconds; however, it is possible that the peak power cap can exceed during that time. To avoid exceeding the configured power cap in a low power-capped environment, consider staggering the rebooting or activation of CIMCs.

Procedure

	Command or Action	Purpose
Step 1	UCS-A# scope server chassis-num / server-num	Enters chassis server mode for the specified chassis.
Step 2	UCS-A /chassis/server # scope CIMC	Enters chassis server CIMC mode
Step 3	UCS-A /chassis/server/CIMC # reset	Resets the CIMC for the blade server.
Step 4	UCS-A /chassis/server/CIMC # commit-buffer	Commits the transaction to the system configuration.

The following example resets the CIMC for blade server 4 in chassis 2 and commits the transaction:

UCS-A# scope server 2/4
UCS-A /chassis/server # scope CIMC
UCS-A /chassis/server/cimc # reset
UCS-A /chassis/server/cimc* # commit-buffer
UCS-A /chassis/server/cimc #

Clearing TPM for a Blade Server

You can clear TPM only on Cisco UCS M4 blade and rack-mount servers that include support for TPM.

Caution

Clearing TPM is a potentially hazardous operation. The OS may stop booting. You may also see loss of data.

Before You Begin

TPM must be enabled.

Procedure

	Command or Action	Purpose
Step 1	UCS-A# scope server [chassis-num/server-num \| dynamic-uuid]	Enters server mode for the specified server.
Step 2	UCS-A# /chassis/server # scope tpm tpm-ID	Enters org TPM mode for the specified TPM.
Step 3	UCS-A# /chassis/server/tpm # set adminaction clear-config	Specifies that the TPM is to be cleared.
Step 4	UCS-A# /chassis/server/tpm # commit-buffer	Commits the transaction to the system configuration.

The following example shows how to clear TPM for a blade server:

UCS-A# scope server 1/3
UCS-A# /chassis/server # scope tpm 1
UCS-A# /chassis/server/tpm # set adminaction clear-config
UCS-A#/chassis/server/tpm* # commit-buffer

Issuing an NMI from a Blade Server

Perform the following procedure if the system remains unresponsive and you need Cisco UCS Manager to issue a Non-Maskable Interrupt (NMI) to the BIOS or operating system from the CIMC. This action creates a core dump or stack trace, depending on the operating system installed on the server.

Procedure

	Command or Action	Purpose
Step 1	UCS-A# scope server [chassis-num/server-num \| dynamic-uuid]	Enters server mode for the specified server.
Step 2	UCS-A /chassis/server # diagnostic-interrupt
Step 3	UCS-A /chassis/server* # commit-buffer	Commits any pending transactions.

The following example sends an NMI from server 4 in chassis 2 and commits the transaction:

UCS-A# scope server 2/4
UCS-A /chassis/server # diagnostic-interrupt
UCS-A /chassis/server* # commit-buffer
UCS-A /chassis/server #

Health LED Alarms

The blade health LED is located on the front of each Cisco UCS B-Series blade server. Cisco UCS Manager allows you to view the sensor faults that cause the blade health LED to change color from green to amber or blinking amber.

The health LED alarms display the following information:

Name	Description
Severity column	The severity of the alarm. This can be one of the following: Critical—The blade health LED is blinking amber. Minor—The blade health LED is amber.
Description column	A brief description of the alarm.
Sensor ID column	The ID of the sensor the triggered the alarm.
Sensor Name column	The name of the sensor that triggered the alarm.

Viewing Health LED Status

Viewing Health LED Status

Procedure

	Command or Action	Purpose
Step 1	UCS-A# scope server chassis-id / server-id	Enters chassis server mode for the specified server.
Step 2	UCS-A /chassis/server # show health-led expand	Displays the health LED and sensor alarms for the selected server.

The following example shows how to display the health LED status and sensor alarms for chassis 1 server 3:

UCS-A# scope server 1/3
UCS-A /chassis/server # show health-led expand
Health LED:
    Severity: Normal
    Reason:
    Color: Green
    Oper State: On

UCS-A /chassis/server #

Smart SSD

Beginning with release 3.1(3), Cisco UCS Manager supports monitoring SSD health. This feature is called Smart SSD. It provides statistical information about the properties like wear status in days, percentage life remaining, and so on. For every property, a minimum, a maximum and an average value is recorded and displayed. The feature also allows you to provide threshold limit for the properties.

Note

The Smart SSD feature is supported only for a selected range of SSDs. It is not supported for any HDDs.

The SATA range of supported SSDs are:

Intel
Samsung
Micron

The SAS range of supported SSDs are:

Toshiba
Sandisk
Samsung
Micron

Note

Power-On Hours and Power Cycle Count are not available on SAS SSDs.
Smart SSD feature is supported only on M4 servers and later.

Viewing SSD Health Statistics

Viewing SSD Health Statistics

Perform this procedure to view the SSD Health statistics.

Procedure

	Command or Action	Purpose
Step 1	UCS-A# scope server chassis-id / server-id	Enters chassis server mode for the specified server.
Step 2	UCS-A /chassis/server # show stats	Displays the SSD health statistics for the specified server.

The following example displays the SSD health statistics for blade 3 in chassis 1:

UCS-A# scope server 1/3
UCS-A /chassis/server # show stats

Ssd Health Stats:
    Time Collected: 2016-12-07T19:35:15.920
    Monitored Object: sys/chassis-1/blade-3/board/storage-SAS-1/ssd-health-stats-1
    Suspect: No
    Id: 1
    Power Cycle Count: 1022
    Power On Hours: 4793
    Percentage Life Left: 92
    Wear Status In Days: 1679
    Thresholded: 0

    Time Collected: 2016-12-07T19:35:38.912
    Monitored Object: sys/chassis-1/blade-3/board/storage-SAS-1/ssd-health-stats-2
    Suspect: No
    Id: 2
    Power Cycle Count: 1017
    Power On Hours: 4270
    Percentage Life Left: 87
    Wear Status In Days: 1587
    Thresholded: 0

    Time Collected: 2016-12-07T19:35:15.920
    Monitored Object: sys/chassis-1/blade-3/board/storage-SAS-4/ssd-health-stats-1
    Suspect: No
    Id: 1
    Power Cycle Count: 1506
    Power On Hours: 5029
    Percentage Life Left: 98
    Wear Status In Days: 1788
    Thresholded: 0
        
    Time Collected: 2016-12-07T19:35:15.920
    Monitored Object: sys/chassis-1/blade-3/board/storage-SAS-4/ssd-health-stats-2
    Suspect: No
    Id: 2
    Power Cycle Count: 58
    Power On Hours: 4731
    Percentage Life Left: 100
    Wear Status In Days: 1825
    Thresholded: 0
UCS-A /chassis/server #

Was this Document Helpful?

Feedback

Contact Cisco

Open a Support Case
(Requires a Cisco Service Contract)