HBAnyware CoreKit Linux Installation Instructions

This installation kit contains the following components:

    HBACMD version 4.0a31
    DFC Library version 3.0.28-1-1
    HBAAPI version 2.1.g
    Multipulse version 3.0.30-1        
    Fcauth version 1.19-1-1

Dependencies:

    lpfc driver version 8.2.0.33.3p or later
     
					 
HBAnyware CoreKit requires that the lpfc driver module be installed.


Installing HBAnyware CoreKit:

 1. Copy the applications kit tar file to a directory on the install machine
 2. cd to the directory which you copied the tar file
 3. Untar the file: tar -xvf tarfilename 
 4. cd (change directory) to the appropriate sub-directory associated to the 
    target machine architecture and OS distribution
 5. su to root
 6. type : rpm -Uhv *.rpm

 7. Installation Complete: type /usr/sbin/hbanyware/hbacmd listhbas 
    to run script utility


Uninstalling HBAnyware CoreKit

 1. obtain current CoreKit RPM package name using query : 
           rpm -qa | grep elxlinux
 2. erase core kit package returned in step 1 using RPM erase
    (rpm -e xxxx) command


----------------------------------------------------------------------
Known Issues

A. The following issues apply to all Linux distributions

A.1. Virtual Connect backwards compatibility

A.1.1 Background
    Starting with HBAnyware CoreKit version 3.2, Emulex provides support for LightPulse
    adapters that are reprogrammed with WWPNs outside the typical Emulex range,
    such as HP's upcoming Virtual Connect for Fibre Channel on the BladeSystem
    c-Class platform.  

A.1.2 Resolution
    In such environments, HBAnyware CoreKit version 3.2 must be deployed across all 
    servers on the SAN, as well as any other management console used for 
    out-of-band management, so that all adapters appear in the discovery tree.


B. The following issues apply to RHEL4/SLES9 Linux distributions only

B.1 Problem reading extended PCI configuration register information for PCI
    Express adapters. 

B.1.2 Resolution
    HBAnyware display of PCI extended configuration register information 
    sometimes reports all zeros. This is a problem in the linux kernel that
	has since been resolved in later distributions.

C. The following issues apply to RHEL5/SLES10 and later Linux distributions

C.1. Netlink (libnl) library package requirement

C.1.1 Background
    Certain libraries provided by this HBAnyware/applications kit have a 
    dependency on the distribution kernel's Netlink library (libnl). This 
    library package is installed by default when the RHEL5 or SLES10-SP1 
    distribution kernel is installed.

    On IA64 and AMD64/EM64T 64-bit architectures, the distribution by 
    default installs the native 64-bit libnl library package. To support
    32-bit applications which depend on HBAnyware components (i.e. HBAAPI
    libraries), the 32-bit libnl library package will need to be installed
    separately from the distribution.

    On i386 and PPC architectures, the distribution installs by default the 
    32-bit libnl library package. On PPC architecture to support 64-bit 
    applications which depend on HBAnyware components (i.e. HBAAPI libraries), 
    the 64-bit libnl library package will need to be installed separately from 
    the distribution.

    Note that HBAnyware utilities (i.e. hbanyware, hbacmd) are not affected by
    this issue. The proper variant of HBAnyware utilities will be installed to 
    match the default installed libnl library package.

C.1.2 Resolution
    The installation process of this HBAnyware/applications kit will warn the 
    user when the 32- or 64-bit missing libnl library package could be needed.
    Users who wish to support applications that depend on the missing libnl 
    package will need to:

    i) Find and install the missing (32- or 64-bit) libnl library package from 
    the distribution media or distribution network. For SLES10-SP1 the YaST 
    management tool can be used for the installation.

    ii) Re-run the application kit's install script to install the related 
    HBAnyware components.


C.3. Extraneous message seen when exiting dfc utility

C.3.1 Symptoms
    When exiting the dfc utility the following message may be seen:
    
        User defined signal 1
 
C.3.2 Background
    This is due to a thread termination by one of the underlying libraries. It 
    does not cause functional failure and can be ignored. 

D.1 Configuring some HBA's for authentication and some HBA's not in same 
    machine is cumbersome and some switches exhibit anomolous behavior

D.1.1 Symptoms
    When authentication driver parameter is enabled but some HBA's are
    not configured for authentication, some switches exhibit an issue
    indicating authentication is required on the SAN. In such cases, the
    driver will log the following message:

    Elx_msg1050: Authentication mode is disabled, but required by the fabric
    Description: Discovery failed because switch fabric required
    authentication but authentication mode was not configured or the
    authentciation mode for this port pair is disabled.

D.1.2 WorkAround
    Either disable the authentication parameter (if authentication not
    desired) or disable authentication on switch side for HBA's not desired 
    to be authenticated.

D.2 The hbanyware GUI will display "n/a" (not available) for the OS Device Name
    for Vport target disk devices. This will be fixed in the hbanyware 4.1 release.

----------------------------------------------------------------------
                     
