You can manage and monitor all rack-mount servers that have been integrated with a Cisco UCS domain through Cisco UCS Manager. All management and monitoring features are supported for rack-mount servers except power capping. Some rack-mount server management tasks, such as changes to the power state, can be performed from both the server and service profile. The remaining management tasks can only be performed on the server.
Cisco UCS Manager provides information, errors, and faults for each rack-mount server that it has discovered.
Tip
For information about how to integrate a supported Cisco UCS rack-mount server with Cisco UCS Manager, see the Cisco UCS C-series server integration guide for your Cisco UCS Manager release.
Guidelines for Removing and Decommissioning Rack-Mount Servers
Consider the following guidelines when deciding whether to remove or decommission a rack-mount server using Cisco UCS Manager:
Decommissioning a Rack-Mount server
Decommissioning is performed when a rack-mount server is physically present and connected but you want to temporarily remove it from the configuration. Because it is expected that a decommissioned rack-mount server will be eventually recommissioned, a portion of the server's information is retained by Cisco UCS Manager for future use.
Removing a Rack-Mount server
Removing is performed when you physically remove the server from the system by disconnecting the rack-mount server from the fabric extender. You cannot remove a rack-mount server from Cisco UCS Manager if it is physically present and connected to the fabric extender. Once the rack-mount server is disconnected, the configuration for that rack-mount server can be removed in Cisco UCS Manager.
During removal, management interfaces are disconnected, 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 rack-mount 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.
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 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
Note
Running servers are not shut down regardless of the desired power state in the service profile.
Booting a Rack-Mount Server
Before You Begin
Associate a service profile with a rack-mount server.
Procedure
Command or Action
Purpose
Step 1
UCS-A# scope orgorg-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-profileprofile-name
Enters organization service profile mode for the specified service profile.
Step 3
UCS-A /org/service-profile # power up
Boots the rack-mount 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 rack-mount server associated with the service profile named ServProf34 and commits the transaction:
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.
Before You Begin
Associate a service profile with a rack-mount server.
Procedure
Command or Action
Purpose
Step 1
UCS-A# scope orgorg-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-profileprofile-name
Enters organization service profile mode for the specified service profile.
Step 3
UCS-A /org/service-profile # power down
Shuts down the rack-mount 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 rack-mount server associated with the service profile named ServProf34 and commits the transaction:
Use the cycle-immediate keyword to immediately begin power cycling the rack-mount 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 rack-mount server 2 and commits the transaction:
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.
Procedure
Command or Action
Purpose
Step 1
UCS-A# scope serverserver-num
Enters server mode for the specified rack-mount server.
Use the hard-reset-immediate keyword to immediately begin hard resetting the rack-mount 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 rack-mount server 2 and commits the transaction:
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.
Procedure
Command or Action
Purpose
Step 1
UCS-A# acknowledge serverserver-num
Acknowledges the specified rack-mount server.
Step 2
UCS-A# commit-buffer
Commits the transaction to the system configuration.
The following example acknowledges rack-mount server 2 and commits the transaction:
UCS-A# acknowledge server 2
UCS-A* # commit-buffer
UCS-A #
Decommissioning a Rack-Mount Server
Procedure
Command or Action
Purpose
Step 1
UCS-A# decommission serverserver-num
Decommissions the specified rack-mount server.
Step 2
UCS-A# commit-buffer
Commits the transaction to the system configuration.
The following example decommissions rack-mount server 2 and commits the transaction:
UCS-A# decommission server 2
UCS-A* # commit-buffer
UCS-A #
Renumbering a Rack-Mount Server
Before You Begin
If you are swapping IDs between servers, you must first decommission both servers and then wait for the server decommission FSM to complete before proceeding with the renumbering steps.
Procedure
Command or Action
Purpose
Step 1
UCS-A# show server inventory
Displays information about your servers.
Step 2
Verify that the server inventory does not include the following:
The rack-mount server you want to renumber
A rack-mount server with the number you want to use
If either of these rack-mount servers are listed in the server inventory, decommission those servers. You must wait until the decommission FSM is complete and the rack-mount servers are not listed in the server inventory before continuing. This might take several minutes.
To see which servers have been decommissioned, issue the show server decommissioned command.
Physically disconnect the CIMC LOM cables that connect the rack-mount server to the fabric extender before performing the following procedure. For high availability setups, remove both cables.
Procedure
Command or Action
Purpose
Step 1
UCS-A# remove serverserver-num
Removes the specified rack-mount server.
Step 2
UCS-A# commit-buffer
Commits the transaction to the system configuration.
The following example removes rack-mount server 4 and commits the transaction:
UCS-A# remove server 4
UCS-A* # commit-buffer
UCS-A #
What to Do Next
If you physically reconnect
the rack-mount server, you must re-acknowledge it to have
Cisco UCS Manager rediscover the 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.
Procedure
Command or Action
Purpose
Step 1
UCS-A# scope serverserver-num
Enters server mode for the specified rack-mount server.
Step 2
UCS-A /server # scope CIMC
Enters server CIMC mode
Step 3
UCS-A /server/CIMC # reset
Resets the CIMC for the rack-mount server.
Step 4
UCS-A /server/CIMC # commit-buffer
Commits the transaction to the system configuration.
The following example resets the CIMC for rack-mount server 2 and commits the transaction:
Recovering the Corrupt BIOS on a Rack-Mount Server
On rare occasions, an issue with a rack-mount server may require you to recover the corrupted BIOS. This procedure is not part of the normal maintenance of a rack-mount server. After you recover the BIOS, the rack-mount server boots with the running version of the firmware for that server.
Before You Begin
Important:
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.
Procedure
Command or Action
Purpose
Step 1
UCS-A#
scope serverserver-id
Enters server mode for the specified rack-mount server.
Step 2
UCS-A /server #
recover-biosversion
Loads and activates the specified BIOS version.
Step 3
UCS-A /server #
commit-buffer
Commits the transaction.
The following example shows how to recover the BIOS:
Shows the status for all servers in the Cisco UCS domain.
The following example shows the status for all servers in the Cisco UCS domain. The servers numbered 1 and 2 do not have a slot listed in the table because they are rack-mount servers.
Server Slot Status Availability Overall Status Discovery
--------------------------------------------------------------------
1/1 Equipped Unavailable Ok Complete
1/2 Equipped Unavailable Ok Complete
1/3 Equipped Unavailable Ok Complete
1/4 Empty Unavailable Ok Complete
1/5 Equipped Unavailable Ok Complete
1/6 Equipped Unavailable Ok Complete
1/7 Empty Unavailable Ok Complete
1/8 Empty Unavailable Ok Complete
1 Equipped Unavailable Ok Complete
2 Equipped Unavailable Ok Complete
Issuing an NMI from a Rack-Mount 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: