Stress-free firmware upgrades


This article can also be found in the Premium Editorial Download "Storage magazine: How does your storage salary stack up?."

Download it now to read this article plus other related content.

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.

Firmware upgrade matrix

Get it down on paper
When evaluating and

Requires Free Membership to View

possibly upgrading your environment, the first step is to document everything in the storage area network (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.

This was first published in December 2004

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: