I know that Equallogic is pretty popular among some here. We've got two PS5000X (on firmware v4.0.2) that need to be updated to 4.1.4 so that a 3rd SAN (A PS6000x) can enter the group.
All our hosts are ESX4.
Can anyone experienced with EQL and firmware updates in a VMWare environment advise on the best approach here - can we do a hot firmware update one SAN at a time with everything connected? I am aware that firmware updates now upgrade one controller at a time which is an improvement on the old approach. Is there any danger to doing it hot (e.g. filesystem corruption) and do we need to change any timeout values anywhere or can we just leave everything as the default?
We went through the idenical update on our arrays. 4.0.2 to 4.1.4. Our ESXi hosts were running with local storage and all guests and RDMs (via iSCSI in the guest) were on the arrays. The upgrade process went flawlessly. We were able to see the controllers swich from passive to active as the update progressed.
We are using Qlogic HBAs in our environment. We had to change our timeouts and turn on ARP redirect. Our guests also needed a iSCSI timeout reg key. Equallogic has all this stuff well documented.
Thanks for your reply. By 'iSCSI timeout reg key', do you mean changing the timeout values on your Windows guests using the registry editor (and doing the same for the Linux guests?) as recommended in the documentation.
We used the software iscsi initiator, but could not find any documentation on modifying timeout values for that...
Yes. They are reg values that need to be changed.
Not sure about Linux VMs. We are a Windows shop.
I thought this information might be helpful for other EQL users. Equallogic support has informed me that the VMWare software iSCSI initiator already has timeout values set to a value high enough to not be affected by array's restart. You only need to check (and adjust) timeout values in the Guest OSs and for iSCSI HBA cards (Qlogic) if those are being used in the ESX server.
I also did a test upgrade on our new array. The upgrade was from 4.1.3 to 4.1.4 - Pings were dropped for about 35 seconds (8 packets or so...). I have no idea how long a full production array would take to reinitialize though so 60 seconds does sound like the minimum time out value one should consider.