A few people have been asking for details on upgrading Cisco UCS to newer versions, and find the Cisco documentation confusing.
I have caputred the steps from 2.0 to 2.1 however the process will be similar for most upgrades. Always make sure you understand what you are doing, and this is a rough guide, and may contain errors, so I accept no responsibility if you bring down your environemnt.
Step 1: Download Firmware, review release notes and upgrade guide.
Download components used, this will always include (unless using stand alone C-Series which isn’t covered in this guide):
1. The Release notes, (if you haven’t read and understdood these then please pay somebody else to do it).
2. The infrastructure bundle,
3. Either B-Series, C-Series, or both. Depending on your environment.
Full Cisco upgrade guide can be found here, this should also be read and understood, again if you don’t understand it get clarification or hire somebody who has done this previously.
Step 2: Upload Firmware Packages to FI’s
Ensure you have selected equipment, Firmware Management, Download Tasks, then click the + on the far right.
This is pretty self-explanatory, select the file and click OK.
When finished select to show the navigator to check the unpacking process is complete before proceeding with the update.
This process can take 10 minutes so is a good time to grab a coffee or check your pre-requisites have been met:
Repeat the process with the B and C series bundles as required.
Step 3: Updating IOM’s
Cisco have 2 methods for updating the blade components (Adapters, CIMC, BIOS, and Board Controllers). I prefer to use a management firmware policy, and Host Firmware Policy. This means we can skip a number of steps streamlining the update process, and update the blade components at the end.
If you attempt to update a blade that has a firmware policy associated with it you will receive the following error:
“Updating” in UCS terminology merely sets the backup version that is installed onto the hardware component. This then requires “activating” before it is used as the start-up version.
The only thing that we need to update using my method is the IOM (or FEX). Use the Filter drop down to select “IO Modules” and then the “Set Version” drop down to apply this to all IOM’s managed by this UCSM.
The Update Status will change to Updating, wait till this is finished.
Step 4: Activate UCSM
Again we select “UCS Manager” from the drop down and set the required version, we also click the “Ignore Compatibility Check” button (it sounds scary but is required).
We click yes on the equally scary warning message:
This will log you out of UCSM as it updates:
You should now note the new version is shown on the splash screen (your computer may have a cache with the old splash screen so it may not update till next time you log in):
Once logged back in we need to update the IOM’s, we only set the start-up version of each IOM as they will reboot once we update the FI’s, this is done by the “Set Startup Version Only” tickbox.
The status will change fairly quickly to Pending Next boot:
Step 5: Update Subordinate FI
Check HA status either with the GUI:
Or SSH to the FI and check it from there using either the “Show cluster state” command:
Or to troubleshoot the “Show cluster extended-state” command, note that all IOM’s must be functioning for HA to be OK, so if you screwed up the last step and rebooted an IOM you will have to resolve that first.
Once confirmed that HA is Ready, we can filter by “Fabric Interconnect” and set the version.
Ensuring you only selected the subordinate FI, you can click Yes on the below:
Step 6: Failover FI
This process will take some time and once complete you should again confirm the cluster is back up using the “Show cluster extended-state” command.
Once done you can issue the following commands which will failover the FI’s, making the newly updated FI-B the primary.
“Cluster lead b” (assuming FI-B was the subordinate at the start of the update procedure)
As soon as you enter that command the SSH session, and UCSM will disconnect as can be seen in the foreground:
Step 7: Update new Subordinate FI
We then repeat the update for the new subordinate FI (the one that was the primary at the start of the procedure), as shown below, and accept the warning again:
Step 8: Update blade components
The remaining blade components to be updated are set via the management firmware policy, so these will need to be modified to include new firmware for adapters, CIMC, BIOS, and Board Controllers (High performance blades only).
You can create a new host firmware policy as shown below, or modify the existing one.
If you create a new Host Firmware package, and Management Firmware Package you will need to change the policy on each Service Profile, or Updating Template in the location shown below:
As long as you are using the “User Ack” maintenance policy, you will then get a Pending Activity to reboot the blades, which will also update the firmware.
NOTE: IF YOU ARE NOT USING THE “USER ACK” POLICY YOUR BLADES WILL REBOOT IMMEDIATELY.