Kirk is absolutely correct,
Make sure you read the entire upgrade guide, and understand the pre-requisites and requirements for each part. It walks you through the whole process and I usually spend about 4-6 hours to prep for any UCSM firmware upgrades, including environmental discovery, downloading code, pre-staging code, and reviewing the upgrade process for that version of firmware.
A few other recommendations:
Take a full state backup and an all config backup of the UCS system before any upgrade.
You will want to add all applicable firmware packages to the firmware page from the equipment tab before upgrading the infrastructure.
Check to make sure the FI's have space for a new version of firmware to be staged up, if this is an older system with multiple code versions still on the FI's, you might need to remove some of the older code to make sure you have room for the new upgrade firmware packages.
Make sure all maintenance policies are set to User Ack before initiating any code upgrades. If a stand alone service profile was set, or the service profiles are not bound to an updating template (initializing templates will not push out changes, best practice is to have an updating template for all of your blades, depending on hardware/OS installed you will probably need more than one updating service profile template for your infrastructure) you could miss the maintenance policy and it would reboot immediately. **If you're re-binding a service profile back to a template, make a clone first, this will give you a backup if you need to revert back to the original settings. When you re-bind a profile to an updating template you are going to remove any customized settings you might not have been aware of for that profile. The updating template will push it's configuration from the template and over-write anything that was different.**
If you have any hardware/OS that will be required to stay at a lower firmware version, make sure your service profile templates have a firmware policy set, and it is at the required versions selected. If there is no firmware policy in the service profile template, it will upgrade the blades when you run the B-firmware package.
Read the upgrade document completely, and understand the process flow required. I usually upgrade the packages, with the infrastructure first, the b-series second, and the c-series 3rd. Pre-stage the code to the server blades with the Auto-install option once your infrastructure upgrade is completed. The upgrade process allows for setting the new code in the backup firmware version, and when you enter your upgrade window you can resume the upgrade and initiate the server reboots so you won't have to wait to stage the code out to the blades.
I always recommend to my customers that they perform any code upgrade in a designated maintenance window in the event any issues are encountered.
Your IOM cards and FI's are going to be going down one at a time. If your configuration is not symmetrical, make sure you understand what is connected to what, and when it will go offline. I've seen scenarios where backup servers were only connected to FI-A and few other odd configurations, which would have impact on the infrastructure upgrade.
For UCS Mini FI's I would be particularly careful, and make sure that you're in a scheduled maintenance window. I've had a UCSM infrastructure upgrade cause network disruption on a UCS Mini in this scenario, both FI's in the IOM slots went into discovery mode and lost their network, and the chassis had to be re-acknowledged after the upgrade completed. I had TAC on the case after the first FI rebooted, and there was network disruption. They were not able to find a cause, and TAC continued the upgrade, unfortunately the same issue occurred and the network disruption happened twice. This has made me extra cautious on UCS Mini firmware upgrades. This caused a brief outage during the upgrade, and post-upgrade the 5108 chassis had to be re-acknowledged which was an additional outage for that entire chassis.
Before you acknowledge the server reboots, put your installed OS into a state that is ready to be rebooted. Migrate all VMs off and put a VMware host in Maintenance mode (especially if there is no DRS on the VMware cluster), shut down a Windows server etc to ensure that there are no issues bringing down that blade because it will reboot.
The UCSM firmware upgrade process is relatively easy, just make sure you've prepared properly. Checked all your installed hardware compatibility, software compatibility, and any dependencies from your running OS versions. For example, VMware might need the VIB files updated for the enic and fnic drivers after the UCSM upgrade completes etc.
Compatibility Matrix:
https://ucshcltool.cloudapps.cisco.com/public/
And lastly, be patient, the upgrade process will take some time, and if this is a production environment make sure you have an appropriate window for this maintenance because you're not going to be rebooting all blades at the same time, you will want to wait for the first one to complete, check the environment, and move on down the list.
Hope this was somewhat helpful.
