FDMI stands for Fabric Device Management Interface and is such an enormously cool feature and unfortunately one of the least used. From an operational management perspective FDMI provides a wealth of information to the fabric regarding the attached devices. The thing that flabbergasted me is that almost no device (HBA/Array) has this turned on of even has the functionality embedded.

FDMI, from a fabric perspective, is a separate database which is (partially) synchronized across all domains in that fabric. The database records in FDMI contain information in 3 blocks: HBA attribute block, Port Attribute block and Port statistics block. The HBA attribute block has information about the HBA static values like WW Node-name,manufacturer, serial number, model and model description, hardware revision, firmware, driver, OS name and version, boot bios state and version (for boot from san configurations) and some vendor specific field which they can use at their disposal. As you can see these are the generic HBA characteristics which are valid for the entire HBA.

If you have a multiport HBA the Port Attribute block contain the port specific values. Supported FC4-type (SCSI/FCP,IPFC etc), supported speeds, current speed, maximum frame-size, OS device-name, host name, WWPort name, supported classes of service etc. etc. Also in this block there is a vendor specific field.

The last block is also a very interesting one as it contains the values from the LESB (Link Error Status Block) of the device. This means you are able to see the errors that have occurred from the switch-port towards the HBA. (The porterrshow command on the switch shows the same information in the opposite direction (Device to switch)

Now here’s the catch. Almost no vendor has this feature turned on by default or even has it implemented in their FC stack.

The only thing it takes is beyond the PLOGI one additional ELS (extended link service) frame to the fabric management server providing this information which is done within less than 1ms. During initialization you won’t even notice it.

Both Qlogic and Emulex have a tickbox in the HBA management interface where you can enable FDMI. If you run any UX system there is a cli parameter which flicks the switch.

So now you say: “What bloody good is it to me???”

Well, you can make very good use of this feature especially if you run FOS 7.4 or up.

Spreadsheets, spreadsheets everywhere.

Whenever I ask for connectivity documentation is always get a spreadsheet with the connection tables of which host is connected to where and what zone-sets it belongs to etc. etc. etc. In my 10 year tenure with HDS looking after storage infrastructures from a pre-sales, services and support person I have never seen a spreadsheet that was entirely correct. This basically yields the result of being totally useless as you don’t have the time of checking every record and field if they are valid or not.

Automate it

With FOS 7.4 Brocade allows info in the FDMI fields being used in the port-name entry. For this to work you first have to enable the “FDMI Host-name” feature via the configure command. If both FDMI is enabled on the HBA and this FDMI Hostname feature you will see that the switch portname will be automatically filled with this info.

Instruct your server/OS friends so that they turn on FDMI. It has no influence on any IO operations and will not interfere with your data.

The alternative

Since FOS 7.4 Brocade also has a ‘Dynamic Portname” feature which will create a portname based on the information already in the switch. It assembles a few pieces of information and uses the switchname, port-type, port number and zone-alias name. For troubleshooting purposes this is very handy as it will also trickle into management interfaces like BNA or other SNMP based management platforms.

switch:admin> portname
port 0: EDGE1_sw76.E_PORT.0
port 1: EDGE1_sw76.(none).1
port 2: EDGE1_sw76.(none).2
port 3: EDGE1_sw76.(none).3
port 4: EDGE1_sw76.(none).4
port 5: EDGE1_sw76.(none).5
port 6: EDGE1_sw76.F_PORT.6.emlx
port 7: EDGE1_sw76.F_PORT.7.(none)

The two are mutually exclusive though so you cannot enable both. I will send in an RFE to change that to have FDMI by default with Dynamic as a fallback for each individual port.

So in short, when you deploy servers in a FC fabric have FDMI enabled and make sure you use either FDMI or Dynamic Portnames. This will save you so much time when searching for what is connected to where and given the fact it is automated the chances of human error is nill.

Let me know if you use FDMI?

[socialpoll id=”2308581″]