We encountered the following “Conflicting VIBs” blocker, while upgrading ESXi 5.5 hosts to 6.0:
The Mellanox driver is required for infiniBand, as we do not have a requirement for infiniBand we could safely remove the MLX4 VIBs prior to the upgrade. Continue reading
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
ID = INST_1
Type = installed
Version = 2.4.2.21519
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 2.4.3.21980 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-2.4.3.21980-RETAIL.tgz.bin.gpg” 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
ID = CAND_1
Type = candidate
Version = 2.4.3.21980
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)
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
Firstly download the latest version from the EMC-approved section of the Emulex website for EMC VNX/VMAX:
http://www.emulex.com/downloads/oem-qualified/emc/
In this example we are downloading the Emulex LPe16002 Firmware and BootCode version 1.1.43.3:
To view the existing firmware during boot (Ctrl+E at Emulex BIOS Prompt):
Or you you can also check via console:
[root@hpdb1 ~]# cat /sys/class/scsi_host/host*/fwrev
1.1.21.8, sli-4:2:b
1.1.21.8, sli-4:2:b
1.1.21.8, sli-4:2:b
1.1.21.8, sli-4:2:b
Applying Update Using OneCommand Manager CLI:
After downloading the zip file from the EMC-approved section of the Emulex website I then extracted the file A11433.grp to the appropriate directory: /usr/sbin/lpfc
Execute the command hbacmd listhbas | grep ‘Port WWN’, and record the Port WWN information for all adapters within the host:
[root@hpdb1 ~]# hbacmd listhbas | grep ‘Port WWN’
Port WWN : 10:00:00:90:fa:02:be:76
Port WWN : 10:00:00:90:fa:02:be:77
Port WWN : 10:00:00:90:fa:02:be:b6
Port WWN : 10:00:00:90:fa:02:be:b7
Next run the “hbacmd” command to install Firmware and BootCode version 1.1.43.3 (hbacmd Download WWPN|MAC Filename):
hbacmd download 10:00:00:90:fa:02:be:76 /usr/sbin/lpfc/A11433.grp
hbacmd download 10:00:00:90:fa:02:be:77 /usr/sbin/lpfc/A11433.grp
hbacmd download 10:00:00:90:fa:02:be:b6 /usr/sbin/lpfc/A11433.grp
hbacmd download 10:00:00:90:fa:02:be:b7 /usr/sbin/lpfc/A11433.grp
Confirm Update was successful:
[root@hpdb1 /]# cat /sys/class/scsi_host/host*/fwrev
1.1.43.3, sli-4:2:b
1.1.43.3, sli-4:2:b
1.1.43.3, sli-4:2:b
1.1.43.3, sli-4:2:b
Thank you @CliffCahill for your assistance.
