EMC VNXe – Code Upgrade

Before proceeding with any upgrade of code on the VNXe please reference the target code release notes on https://support.emc.com/. The VNXe landing page: http://emc.com/vnxesupport will provide you with all the relevant material and downloads for your upgrade.

Code Upgrade Via UEMCLI
It is important there are no configurations on the VNXe taking place while an upgrade is in progress either through Unisphere or UEMCLI. For details around NDU or otherwise please ensure you reference the software candidate release notes. For single SP VNXe3100/3150 systems the array will be inaccessible during the system restart so best to plan to upgrade during a maintenance window.

1. Check the current version of code:
uemcli -d mgmt_ip -u Local/admin -p Password123# /sys/soft/ver show

Type = installed
Version =
Release date = 2013-12-05 19:01:50

2. It is good practice to run a health check and resolve any issues prior to system upgrades:
uemcli -d mgmt_ip -u Local/admin -p Password123# /sys/general healthcheck

Operation completed successfully.

3. Upload the upgrade candidate software, in this case the upgrade candidate is Version of the VNXe Operating Environment. The VNXe OE upgrade files use an encrypted binary file format (.gpg files):
uemcli -d mgmt_ip -u Local/admin -p Password123# -upload -f “path:\VNXe-MR4SP3.1-upgrade-” upgrade

Uploaded 784.54 MB of 784.54 MB [ 100.0% ] -PROCESSING-
Operation completed successfully.

4. Confirm the presence of the candidate file on the VNXe:
uemcli -d mgmt_ip -u Local/admin -p Password123# /sys/soft/ver show

Type = candidate
Version =
Release date = 2014-10-10 19:35:27
Image type = software

5. Perform the upgrade:
uemcli -d mgmt_ip -u Local/admin -p Password123# /sys/soft/upgrade create -candId CAND_1

Operation completed successfully.

6. Monitor the upgrade session (takes approx 1Hr to complete):
uemcli -d mgmt_ip -u Local/admin -p Password123# /sys/soft/upgrade show

Status = running
Creation time = 2015-02-09 19:44:51
Elapsed time = 8m 09s
Estimated time left = 10m 00s
Progress = Task 21 of 40 (reboot_peer_sp_if_required)

Cisco MDS – Upgrading Firmware

MDS 9000 Series Firmware Upgrade

It is always good practice to read the software ‘release notes’ before proceeding with an upgrade. The ‘Cisco MDS 9000 NX-OS and SAN-OS Software’ release notes can be found here.

These are the steps I follow when upgrading:

1. Open an SSH session to the switch.

2. Take a backup of your configuration. Firstly ensure that your running configuration has been applied to the startup-config:
copy running-config startup-config
Then backup your startup configuration. In this example we are backing up to an ftp server:
copy system:startup-config ftp://FTPserver_IP/startup-config.cfg

3. Ensure the switch is in a healthy state before proceeding:
If the MDS is a Director Level switch, then check the redundancy and module status:
show system redundancy status
show module

During the upgrade the standby supervisor is upgraded first. Once the upgrade has completed on the standby then an automatic switchover occurs and the upgraded standby becomes primary while the other supervisor is upgraded. The odd time I have experienced with a Director switch that the supervisor does not switch back to the original primary after the code upgrade has completed. In this scenario simply use these cmds to switch manually:
attach module #
system switchover (if running on standby)

4. Check the current firmware version:

5. Change directory to bootflash and upload the new bin files to the switch. This example uses an ftp transfer:
copy ftp://user@IP_Address/m9100-s3ek9-kickstart-mz.5.2.8c.bin m9100-s3ek9-kickstart-mz.5.2.8c.bin
copy ftp://user@IP_Address/m9100-s3ek9-mz.5.2.8c.bin m9100-s3ek9-mz.5.2.8c.bin

6. Ensure the code was uploaded to the bootflash directory successfully:

7. Determine if the upgrade will be non-disruptive:
show install all impact system bootflash:///m9100-s3ek9-mz.5.2.8c.bin
For a non-disruptive upgrade the switches are designed in such a way that the ports will remain connected and traffic flow will continue non-disrupted throughout the upgrade. This is so because the switch has been engineered in such a way that the control plane is separate to the data plane. In the case of a director level switch the modules are upgraded and rebooted in a rolling fashion one at a time non-disruptively(non-disruptively due to the separation of the control and data planes).

8. Check the MD5 and confirm the files validity:
show version image bootflash:///m9100-s3ek9-mz.5.2.8c.bin
show version image bootflash:///m9100-s3ek9-kickstart-mz.5.2.8c.bin

9. Check for any incompatibilities between the running and the upgrade code versions. This will check for features that are currently running on the switch but are not supported on the upgrade code level:
show incompatibility system bootflash:///m9500-sf2ek9-mz.5.2.8c.bin

10. Enter the following command to install the new firmware on the switch:
install all system m9100-s3ek9-mz.5.2.8c.bin kickstart m9100-s3ek9-kickstart-mz.5.2.8c.bin

11. Display the status of the upgrade:
‘show install all status’

12. Run ‘show version’ to ensure the switch is now running at the upgraded code level. As you can see from the below example the ‘system version’ is still on the previous firmware level – a reload is required to apply the upgrade. NOTE: A reload is disruptive to traffic flow (As pointed out by @dynamoxxx below). This is not common and I have only identified this with the 9148 Switch when upgrading from 5.0.x to 5.8.x.

After reload the system version should be at the upgraded version:

It is good practice to delete the old install files from the bootflash directory:
cd bootflash:
delete m9100-s3ek9-kickstart-mz.5.0.1a.bin
delete m9100-s3ek9-mz.5.0.1a.bin