- Preface
-
- Configuring the Fabric Interconnects
- Configuring Ports and Port Channels
- Configuring Communication Services
- Configuring Authentication
- Configuring Organizations
- Configuring Role-Based Access Control
- Configuring DNS Servers
- Configuring System-Related Policies
- Managing Licenses
- Managing Virtual Interfaces
- Registering Cisco UCS Domains with Cisco UCS Central
- Index
Contents
- Managing Blade Servers
- 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
- 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
- Recovering the Corrupt BIOS on a Blade Server
- Issuing an NMI from a Blade Server
- Health LED Alarms
- Viewing Health LED Status
Managing Blade Servers
This chapter includes the following sections:
- 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
- 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
- Recovering the Corrupt BIOS on a Blade Server
- Issuing an NMI from a Blade Server
- Health LED Alarms
- Viewing Health LED Status
Blade Server Management
You can manage and monitor all blade servers in a Cisco UCS domain through Cisco UCS Manager. Some blade server management tasks, such as changes to the power state, can be performed from the server and service profile.
The remaining management tasks can only be performed on the server.
If a blade server slot in a chassis is empty, Cisco UCS Manager provides information, errors, and faults for that slot. You can also reacknowledge 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
Decommissioning is performed when a blade server is physically present and connected but you want to temporarily remove it from the configuration. Because it is expected that a decommissioned blade server will be eventually recommissioned, a portion of the server's information is retained by Cisco UCS Manager for future use.
Removing a Blade Server
Removing is performed when you physically remove a blade server from the server 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. Once 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 those servers added to a server pool automatically during discovery will be removed automatically. Servers that have been manually added to a server pool have to be removed manually. |
If you need to add a removed blade server back to the configuration, it must be reconnected and then rediscovered. When a server is reintroduced to Cisco UCS Manager it is treated like a new server and is subject to the deep discovery process. For this reason, it's possible that Cisco UCS Manager will assign the server a new ID that may 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.
Do not use any of the following options on an associated server that is currently powered off:
If you reset, cycle, or use the physical power buttons on a server that is currently powered off, the server's actual power state may 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 may 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 |
||
|---|---|---|---|---|
Up |
Powered Off |
Powered On |
||
Down |
Powered On |
Powered On
|
Booting a Blade Server
Associate a service profile with a blade server or server pool.
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.
Associate a service profile with a blade server or server pool.
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 #
Power Cycling a Blade Server
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 shut down, the server is power cycled. The option to have Cisco UCS Manager complete all management operations before it resets the server does not guarantee that these operations will be completed 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 will become out of sync with the actual power state and the servers may 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. |
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 if you need to have Cisco UCS Manager 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.
| Command or Action | Purpose |
|---|
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
Physically remove the server from its chassis before performing the following procedure.
| Command or Action | Purpose |
|---|
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 #
If you physically re-install the blade server, you must re-acknowledge the slot to have Cisco UCS Manager rediscover the server.
For more information, see Acknowledging a Blade Server.
Decommissioning a Blade Server
| Command or Action | Purpose |
|---|
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
| Command or Action | Purpose |
|---|
The following example turns on the locator LED for 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 #
Turning Off the Locator LED for a Blade Server
| Command or Action | Purpose |
|---|
The following example turns off the locator LED for 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 #
Resetting the CMOS for a Blade Server
On rare occasions, troubleshooting a server may require you to reset the CMOS. This procedure is not part of the normal maintenance of a server.
| Command or Action | Purpose |
|---|
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
On rare occasions, such as an issue with the current running firmware, troubleshooting a server may require you to reset the CIMC. This procedure 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 for as long as it takes for the CIMC to reboot. While this usually only takes 20 seconds, there is a possibility that the peak power cap could be exceeded during that time. To avoid exceeding the configured power cap in a very low power-capped environment, consider staggering the rebooting or activation of CIMCs.
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 #
Recovering the Corrupt BIOS on a Blade Server
On rare occasions, an issue with a blade server may require you to recover the corrupted BIOS. This procedure is not part of the normal maintenance of a server. After you recover the BIOS, the blade server boots with the running version of the firmware for that server.
Remove all attached or mapped USB storage from a server before you attempt to recover the corrupt BIOS on that server. If an external USB drive is attached or mapped from vMedia to the server, BIOS recovery fails.
The following example shows how to recover the BIOS:
UCS-A# scope server 1/7 UCS-A /chassis/server # recover-bios S5500.0044.0.3.1.010620101125 UCS-A /chassis/server* # commit-buffer UCS-A /chassis/server #
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.
| Command or Action | Purpose |
|---|
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:
Viewing Health LED Status
| Command or Action | Purpose |
|---|
The following example shows how to display the health LED status and sensor alarms for chassis 1 server 1:
UCS-A# scope server 1/1
UCS-A /chassis/server # show health-led
Health LED:
Severity: Minor
Reason:: P0V75_STBY:Voltage Threshold Crossed;TEMP_SENS_FRONT:Temperature Threshold Crossed;
Color: Amber
Oper State:: On
Sensor Alarm:
Severity: Minor
Sensor ID: 7
Sensor Name: P0V75_STBY
Alarm Desc: Voltage Threshold Crossed
Severity: Minor
Sensor ID: 76
Sensor Name: TEMP_SENS_FRONT
Alarm Desc: Temperature Threshold Crossed
Severity: Minor
Sensor ID: 91
Sensor Name: DDR3_P1_D2_TMP
Alarm Desc: Temperature Threshold Crossed
UCS-A /chassis/server #
