Manage Learn to apply best practices and optimize your operations.

How to plan for a firmware upgrade

Many storage administrators don't manage drivers or firmware until something happens, such as an upgrade or new hardware implementation.

This article first appeared in "Storage" magazine in their December issue. For more articles of this type, please...


What you will learn from this tip: How to document your storage environment in preparation for a stress-free firmware upgrade.

You know the drill: The server team upgrades to a new operating system version and, in doing so, introduces connectivity problems into your storage environment. You discover the only way to fix the problem is to upgrade the firmware. You dig a little deeper only to realize the upgrade has dependencies that will affect your entire environment, launching you into a firmware- and driver-upgrade frenzy filled with lots of planning, lost weekends and late nights.

Many storage administrators don't manage drivers or firmware until something happens, such as an upgrade or new hardware implementation. Of course, the amount of firmware you need to manage is in direct proportion to the complexity of your environment and the systems you've implemented. Some vendors don't stipulate firmware and driver versions as long as the other systems in the environment support installed versions. Other vendors have charts, matrixes, spreadsheets and executables for every proprietary product in the environment, all of which seem to overlap and have cross dependencies, making a firmware upgrade a heavily researched and carefully planned event. Most environments seem to fall between these two extremes.

Get it down on paper

When evaluating and possibly upgrading your environment, the first step is to document everything in the SAN, including:

  • Make and model numbers of servers and their firmware versions (motherboard, etc.)
  • Operating system versions, service packs and patch levels
  • Host bus adapter (HBA) firmware, drivers, failover or redundancy software
  • HBA load-balancing software Infrastructure firmware/software versions (switches, directors, SAN extenders)
  • Storage resource management (SRM) software package and current revision levels
  • Disk subsystems and proprietary software

Some SRM packages and software from disk subsystem vendors can gather much of this information. For example, EMC Corp.'s Grab utility corrals all of the server, EMC software and HBA data, and EMC will convert this information into a Host Environment Analysis Tool (HEAT) report, which is a cleaned-up version of the Grab output. This report also compares the server's configuration to that of EMC's support matrix and highlights anything out of compliance. Only EMC can convert grabs to HEAT reports.

However you gather this information, make sure you create a document that's easy to access and update by anyone on your team. Some administrators try to keep all of this information in a spreadsheet, some write scripts that pull the data from their SRM tool and stick it in a flat file, while others create and store individual server configuration files tucked away in a shared folder.

If you have an accurate record of your firmware and driver revisions, you're light-years ahead of most of your peers. However, many documentation efforts start with great intentions only to be abandoned within a few months because of the effort required to maintain this information. It's a time-consuming chore, but having all of this information readily available is worth the effort.

Read more of this tip in Storage magazine.

For more information:

About the author: Dean Auger has worked in storage for several years as a technical consultant, implementer, sales engineer and, most recently, in the financial industry.

Dig Deeper on SAN technology and arrays