Before installing the HBA into the system, review the best practices in this section to avoid potential issues:
Follow these general best practices for installing and configuring the HBA:
Spread the I/O load amongst multiple HBAs and multiple ports to avoid bottlenecks and promote higher availability.
Use fixed link speeds instead of auto-negotiation wherever possible. While the HBA supports auto-negotiation, auto-negotiation slows things down in the event of a fabric rebuild.
Do not configure both tape devices and disks on the same HBA port, even if using a switch and zoning.
If more than one of a given HBA model is present in the configuration, enable only the OpROM for the first HBA seen in the boot sequence. There is a limited amount of space for OpROMs, so do not unnecessarily enable all OpROMs, as space usage issues might occur.
When installing the HBA, be sure to also install the latest version (version 11.1.218.x or newer) of the command-line utility available from the manufacturer's website (See To Upgrade Firmware Using the OneCommand Manager CLI). Keep the HBA utilities, firmware, and drivers up-to-date, and update them in that order.
After installing the OneCommand Manager CLI utility, ensure that the elxhbamgrd daemon process is running (The OneCommand Manager utility starts this daemon process, by default, upon installation.). In the event of a failure, the elxhbamgrd daemon produces a usable firmware dump for troubleshooting. The location of dump files varies, based on your operating system:
Windows: OneCommandManager-installation-directory\Util\Dump
Oracle Solaris: /opt/ELXocm/Dump
Linux: /var/log/emulex/ocmanager/Dump
Firmware dumps are written to Flash memory on the HBA, and the files reside there until you manually extract and clear the files to produce room for new firmware dumps. A firmware dump cannot be overwritten in Flash. With the OneCommand Manager utility installed and running, if a failure occurs on the HBA, the utility captures and collects firmware dumps during boot up, and then automatically clears the Flash memory on the HBA. However, if the failure case does not capture the dump file, or the OnceCommand Manager utility is not running, you can manually run the OneCommand Manager utility in order to collect and capture the dump file.
Follow these best practices for switches and zoning in your environment:
FC-SW configurations: check with the switch manufacturer for optimal configuration recommendations, including zoning.
Note that FC-AL is not supported at 16Gb/s or faster. Use FC-P2P instead.
Use single initiator hard zoning to do the following:
Avoid Registered State Change Notification (RSCN) storms.
Shield devices from indiscriminate SCSI inquiries.
Provide security by avoiding inappropriate access.
Use meaningful names for zones, and document the entire configuration.
Use only FCP-2 (also called FC-TAPE or FCP Error Recovery) with tape and/or sequential devices. While FCP-2 might not cause problems for hard disk drives (HDDs), FCP-2 is a sequence-level error recovery mechanism that is irrelevant to HDDs.
If using FC tape backups, place tape ports and backup servers on the same FC switch to avoid tying up inter-switch links (ISLs).
SAN switches can be a major source of disruption if you do not take extreme care with respect to configuration. Do not perform updates to switch OSes and/or firmware, or enable new features on SAN switches, until you have first tried the updated switches in a test configuration. The HBA might not support newer switch features, and switch OS and/or firmware updates might require changes to, and/or restoration of, switch configuration settings.
If you plan to install a Boot From SAN (BFS) HBA, follow these best practices:
Some devices and operating systems do not yet support UEFI-based BIOS and can boot only from the Legacy BIOS boot mode. However, many servers with UEFI firmware allow you to enable a legacy BIOS compatibility mode.
Legacy BIOS issues - many tweaks and patches have been added over the years to resolve various issues, and not all were done with the larger ecosystem (many different types of servers, HBAs, OSes, and so on) in mind.
Secure Boot (a UEFI-specific feature) can help you control the boot process, preventing unauthorized code from running.
Larger devices (>2TB) require the use of a GUID Partition Table (GPT) instead of a Master Boot Record (MBR). GPT is the standard for EFI; it can be implemented in legacy BIOSes, but it is more difficult to set up. So, while you might be able to boot from a >2TB device in the legacy BIOS, it might not be seamless. If you are dual-booting with an OS that is already installed in one mode or the other, however, it is good practice to boot in the same boot mode as the one that is already in use.
Disable OpROM and BIOS for all HBA cards except the one connected to the boot device.
When installing a Boot From SAN (BFS) HBA, configure a single connection to a single SAN target/LUN, install the boot OS, and get that working before installing other HBAs and storage. If the configuration is complex, finding the root cause for any BFS issues becomes far more complicated.
Once BFS is installed and working, make sure the HBA driver and firmware are at the latest revision levels. If required, configure a multipath connection, and perhaps one or more alternate boot LUNs.
Test the storage environment by doing the following:
Boot the OS on the host server, and then disable the primary path to the SAN boot device to validate the multipath connection.
Physically pull the cable from the system.
Intentionally disrupt zoning at the FC switch that you plan to attach to the HBA.
If you have installed any alternate boot LUNs, try to boot from those (after disrupting the primary connection(s)).
Make sure the boot LUN is set as the first boot device in the system BIOS/UEFI settings.