I recently had a customer who wished to build an ESX infrastructure using their IBM FAStT 500 Storage Server, with 4 EXP500 Storage Expansion Units full of 72GB drives until a more robust EMC solution is purchased. Though the FAStT 500 is not specifically listed in the VMware SAN Compatibility Guide, we were confident it would work. Little did we know what an adventure it would be….

A couple things to remember…. First, this “SAN” is old. I had originally thought it was installed in late 2003, however, it was a bit older than that as it was installed by IBM in 2002. Second, at any given time, only 1 server had been connected to this Storage System.

When the first ESX server was installed, the HBAs connected to the FAStT 500, and a Rescan done on the Storage Adapter settings, all 4 “LUNs” (IBM may call them Logical drives) to which the ESX server had access to were displayed. However, when trying to create a VMFS datastore, the error message “Failed to update disk partition information” popped up on the screen. We got around this error by disconnecting one of the HBAs, so we wondered if the device understand multipathing.

When the second ESX server was installed, it too recognized all 4 LUNs, but it did not recognize the VMFS datastores. Troubleshooting led us to an IBM RedBook explaining, in good detail, how to get VMware 2.1 working on a FAStT 500 using “storage partitioning” (I equated to the EMC Storage Group/Lun Masking equivalent). Basically, the LUNs need to be assigned to a “Host Group”, and then the ESX servers could be assigned as hosts to the host group.

Storage Partitioning did not come as a standard feature on the FAStT 500. It required an additional purchase and was enabled using a .KEY file obtained by IBM tech support or the vendor from which the SAN was purchased. To make a long story even longer, we contacted IBM support, who sent us to their Entitlement department, who sent us to Hardware Support, who sent us back to Entitlement, and finally Sales. Eventually, we were told we’d have to pay “$3,109” in order to continue the case and “potentially” obtain a Software Feature Key.

Around this time, another IT administrator stumbled across a firmware and NVSRAM update hidden in the bowels of IBM’s Storage Support site. Much to everyone’s surprise, the firmware update asked, in effect, “Would you like to enable some of the advanced features of the FAStT Storage System”. Indeed, please do! Once the storage system rebooted, our ESX servers worked like a champ!! VMFS datastore sharing, HBA multipathing, vmotion, etc, etc, it all worked!!

So, if any of you out there have an IBM FAStT 500 Storage System, you too can be sure an ESX 3.5 infrastructure can be built upon it. The firmware version which fixed our issues was, and the NVSRAM is version N3552F500R830V05. Be sure to apply the firmware update first, and the NVSRAM update second.