Direct upgrade from Virtual Connect v1.24 to Virtual Connect v3.17

[chuckk281]

Dmytro had a Virtual Connect upgrade question:

*****************

Hi,  all

I should like to upgrade the Virtual Connect  firmware. My current version is VC v1.24. 

Can I do it directly  to v3.17 without doing an intermediate version upgrade? I see in release notes that direct upgrade supported from v1.31, and my is  v1.24? Here are some cautions in the manuals: 

----- to make backup of config is there command to restoreJ can’t find

vcsu -a configbackup -i 192.168.251.32 -u hpadmin -p hpinvent -vcu hpadmin -vcp hpinvent -l c:\temp\                   

---- to upgrade all modules with activation odd-even and wait for activation 5mins for each module

vcsu -a update -i 192.168.251.32 -u hpadmin -p hpinvent –vcu hpadmin –vcp hpinvent -l  C:\temp\vcfc-317.bin –oe odd-even -we 5 -of odd-even -wf 5 -f version,health 

************************

Jon had some advice for Dmytro:

********************

Update to VC 1.34 first, then to the desired end version of the Onboard Administrator firmware (i.e. 3.21).  Update all the server, PMC, iLO, HBA and NIC firmware and drivers in addition to teaming/bonding and MPIO software.  The BladeSystem Firmware Release sets can be your guide there; the drivers should be concurrent if possible.  Keep an eye on storage compatibility lists to avoid conflicts, particularly with HBA firmware and drivers.  SPOCK provides fibre switch firmware compatibility to VC firmware references.  Somehow, all these matrices need to fit together.  Then upgrade to 3.17.  Complicated environments involving external storage may need careful planning.

I agree with the 5 minute idea; some say as much as 15 minutes, though I am not certain if there is any official guidelines to stand on.  Although theoretically, it should not be necessary, some NIC teaming and MPIO software are slow in failing over; inoptimal configurations or outright hardware problems can cause further delays.  Spanning Tree Protocol (STP) may need time to readjust to the new network states.  There are also some sensitive fault recovery software out there, especially in the VMWare space.  The longer the delay, the greater the chance that none of these external factors will affect a successful failover.

******************

Any other advice for Dmytro?