Having created a VSF stack of Aruba 2930Fs, the immediate need of firmware maintenance is obviously raising the question of how!. Dealing with that, luckily a new software had been released and I was able to test.

Daring the result … it was shocking simple and runs as every other Aruba / Procurve firmware upgrade and you just have to cover the second vsf stack member.


vsf member 1
copy tftp flash 192.168.2.5 WC_16_07_0002.swi primary
vsf member 2
copy tftp flash 192.168.2.5 WC_16_07_0002.swi primary


Verify the upload with a show flash the firmware image something like, even you may ckeck the according member context again:


Image Size (bytes) Date Version
----------------- ------------ -------- --------------
Primary Image : 29328334 09/05/18 WC.16.07.0002
Secondary Image : 29072623 06/22/18 WC.16.06.0006


Boot ROM Version
----------------
Primary Boot ROM Version : WC.16.01.0004
Secondary Boot ROM Version : WC.16.01.0004


Default Boot Image : Primary
Default Boot ROM : Primary


and then simply


#boot system flash primary


Following the boot process on the serial interface output of the master looks pretty much like any firmware upgrade you may have done on one of these switches. Nevertheless they perform a failover, including serial output, which feels a bit strange. After that you may check the result in every memebers context again.


LABVSF01(config)# vsf member 1
LABVSF01(vsf member-1)# show version


Image stamp:
/ws/swbuildm/rel_xanadu_zeus_qaoff/code/build/lvm(swbuildm_rel_xanadu_zeus_qaof
f_rel_xanadu_zeus)
Sep 5 2018 11:54:18
WC.16.07.0002
794
Boot Image: Primary


Boot ROM Version: WC.16.01.0004
Active Boot ROM: Primary


LABVSF01(vsf member-1)# vsf member 2
LABVSF01(vsf member-2)# show version


Image stamp:
/ws/swbuildm/rel_xanadu_zeus_qaoff/code/build/lvm(swbuildm_rel_xanadu_zeus_qaof
f_rel_xanadu_zeus)
Sep 5 2018 11:54:18
WC.16.07.0002
794
Boot Image: Primary


Boot ROM Version: WC.16.01.0004
Active Boot ROM: Primary


Confirming that both stack nodes now run on the desired new firmware version 16.07.0002 in this case.

A simple reload did not do the job as in the single switch case and resulted in a “firmware version missmatch” and reloads on the secondary old software image. This looked strangely on the serial console since the session was forwarded to the current master always and the missmatch could only be observed for a short peiod in time, till the stack recovered itself.

So far the described procedure worked in a couple of test cycles.

[Edit 29-07-2019]
In a two node cluster in current versions is a certain likelyness software will correctly to the connected nodes. Up to now, this process as well as the ordered reboot had not worked properly to my experience. There seems to be some voting.

So up to now it is absolutly critical to verify firmware distribution before starting to reboot.

For manual reboot make sure that the current commander is the one you are connected to (even trhough a firewall) and that you reboot this one the last.

[Edit end]

[Edit 06-01-2020]

finally I found the cluster size independent solution. Rebooting the stack should be performed with:

boot system flash primary

In case the new firmware was copied in the primary flash. 

[Edit end]

Kyp. F.