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 Installing Utilities for Updating the BIOS and Firmware). 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
Keep in mind that manual firmware dumps do not collect fatal firmware errors. If the OneCommand Manager utility is installed and running, the HBA firmware detects a fatal error, and then notifies the HBA driver of the error. The driver then notifies the OneCommand Manager utility (via the elxhbamgrd daemon process) to start the firmware dump. This firmware dump starts automatically, and the dump file is stored in the default dump location, based on your operating system.
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.