• OpenHPI
• FAQ

OpenHPI

What is OpenHPI?

OpenHPI is an open source project created with the intent of providing an implementation of the SA Forum's Hardware Platform Interface (HPI). HPI provides an abstracted interface for managing computer hardware, typically for chassis and rack based servers.

How the OpenHPI is structured?

OpenHPI supports HPI with a common set of core infrastructure code and a series of code plugins that are hardware and/or protocol specific.

• Infrastructure: The core library is considered infrastructure. This is the section of code which provides and internal representation of resources and events, and exposes them as HPI data structures.

• Plugin interface: This is the method of communication between the OpenHPI infrastructure and real hardware. It is designed to be abstract enough to allow communication to any type of hardware over any interface or protocol. Plugin ABI can interface with a device driver or network protocol

What are the different plugins present in OpenHPI?

There exist a number of plugins in the OpenHPI to enable different types of hardware and interfaces.

• Simulator: Plugin which can be used to test the OpenHPI functionality.

• IPMI: An IPMI interface module based on the libOpenIPMI library.

• IPMIdirect: An IPMI module based that directly talks to device driver for ATCA and IPMI 1.5 systems.

• snmp_bc: A SNMP interface module for IBM BladeCenter/RSA.

• sysfs: A Linux sysfs (kernel > 2.6) interface module based on the libsysfs library.

• watchdog: An interface to the Linux watchdog device. Softdog is used in place of a real hardware watchdog.

• oa_soap: An interface to the HP BladeSystem c-Class OA based on SOAP XML interface.

• ilo2_ribcl: An interface to the HP ProLiant rack mount servers based on SOAP XML interface.

How the openhpi plugin works?

• The OpenHPI plugin is a libtool dynamic library. The lt_dlopenext call is used to open and load the symbols from the plugin. Plugin Application Binary Interface (ABI).
• The plugin can implement the plugin ABIs depending on functionality supported by the hardware or interface. Not all ABIs needs to implemented, 'open' and 'get_event' ABIs has to be implemented. If an ABI is not implemented by the plugin, then ABI function pointer is set to NULL.
• OpenHPI plugin handler has pointers to the ABI function table of the plugin. Plugin ABIs are loaded only once per plugin. Plugin contains a structure which contains function pointers to the ABIs. * Most of the functions in the plugin ABI map very closely to those in the SAF HPI, however they are named with more Linux friendly naming convention. The saHpiResourcePowerStateGet SAF HPI API maps to get_power_state OpenHPI ABI

How openhpi daemon works?

The daemon is compiled as a standalone application and can be run as either as foreground or background application. The OpenHPI daemon accepts connections from remote/local clients to perform OpenHPI library function calls. The daemon wraps the standard OpenHPI function library with a sockets-based API that is architecture neutral for all types of clients. We can start the openhpi daemon by specifying the configuration file.

openhpid -c /usr/local/etc/openhpi/openhpi.conf

The OpenHPI client library provides all the connection functionality needed by the client application to connect to the OpenHPI daemon running on the local or remote server Client library uses two environment variables to locate the daemon service.

• OPENHPI_DAEMON_HOST - URL for the host running the daemon. If not defined, defaults to 'localhost'
• OPENHPI_DAEMON_PORT - The port number the host is listening on for client connections. If not defined, defaults to 4743.

If these variables are not defined, the client library uses the defaults. The client and the daemon do not have to be on the same hardware architecture. The daemon could be running on an i386 processor and the client running on an x86-series processor. The client library and daemon use a marshaling technique to resolve architecture and structure padding conflicts. The user need not worry with architectural differences between the client and daemon

What are the utilities provided by OpenHPI?

OpenHPI provides several utilities.

hpi_shell

This utility can be used to simulate the HPI application. This utility provides the various commands to test the HPI implementation

• Walk through of RPT and RDR table is done using the ‘rpt’ and ‘rdr’ command respectively
• Sensor information can be obtained the by using the ‘sen’ command * ‘inv’ command provides the inventory information of the specified resource
• ‘power’ and ‘reset’ commands is used to change the power state and reset the resources respectively.
• ‘event’ command can be used to enable or disable the event display

hpitop

hpitop utility lists the resources in hierarchical tree format.

hpievents

hpievents utility captures the HPI events and displays the same. hpievents utility listens for the events for the specified time or infinite time

hpiinv

hpiinv provides the inventory information of all the resources

hpisensor

All the resource sensor information can be obtained using the hpisensor utility

hpipower & hpireset

These two utilities can be used to manage the power or reset the resources.

hpitree

hpitree traverse through the RPT and RDR table

How to start openhpid for managing the multiple systems?

Configure multiple plugins intances (handlers) for the systems that needs to managed in openhpi.conf file. But, use of the different entity root is recommended.

How to see the DEBUG messages?

If the debug messages are enabled, the openhpi prints the debug message on the console/terminal. The debug messages can be enabled by exporting the OPENHPI_DEBUG environment variable to YES.

export OPENHPI_DEBUG=YES

NOTE: If you have run the openhpid as daemon (not in foreground), then DO NOT close the terminal/console from where the openhpid is started. On closing the terminal/console, openhpid continuous to run but the debug messages will not be visible.

How to connect to the openhpi daemon running in remote system?

The openhpi client library connects to the openhpi daemon running in the system pointed by the environment variable OPENHPID_DAEMON_HOST. If the OPENHPID_DAEMON_HOST environment variable is not defined, then it tries to connect to the openhpi daemon running in local system. Export the environment variable OPENHPID_DAEMON_HOST with the server hostname/IP address of the server where the openhpi daemon is running. This makes the openhpi client libary to connect to openhpi daemon running in remote system.

export OPENHPID_DAEMON_HOST=myhost.mydomain.com

I am not able to connect to the recently installed openhpi library

If multiple versions of the openhpi is installed on the same system, then the applications/test programs may connect to the previous version of the openhpi. It is advised to uninstall the openhpi, before installing the latest openhpi. In case, if the openhpi is installed via source tar ball and source tar ball has got deleted. Then manually search and delete the openhpi libraries (usually found under /usr/local/lib) and openhpi executables (usually found under /usr/local/sbin and /usr/local/bin).

openhpi utility programs are failing due to openhpi library linking issue

• After installing the openhpi, you need to update the ldconfig. This makes the openhpi library get loaded with openhpi test programs. The same is explained in openhpi bug # 71730 Newer linux distros have gone to new method to populate ldconfig db. ldconfig cb is cached and all look ups go to the cache. Whenever a new library gets added to /usr/local/lib, ldconfig needs to be run to update the ldconfig lib cache. Running ldconfig at the end of install will update the db and avoid running into daemon initialization due to not being to find newly added OpenHPI libraries to the ldconfig db.

• Export the LD_LIBRARY_PATH with the openhpi libraries.

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib:/usr/local/lib/openhpi

How to debug the openhpi daemon?

The openhpi daemon can be debugged using GDB. To enable debugging, configure script should be run with enabling the debugging

./configure --enable-debuggable

• Start the openhpi daemon with gdb and put the appropriate break points. Please run the openhpi daemon with foreground option

gdb openhpid
GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions. There is absolutely no warranty for GDB.  Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) run -c /etc/openhpi/openhpi.conf -n

• Attach the gdb with the already started openhpi daemon.

ps -eaf | grep openhpid root     10122     1  0 12:41 ?        00:00:00
openhpid -c /etc/openhpi/openhpi.conf 

gdb openhpid 10122

I am not able to see the openhpi daemon error logs in Ubuntu/Debian

The openhpi daemon uses the syslog daemon to log the error messages. In Redhat and Suse, the syslog daemon puts the log messages into /var/log/messages file. While in Ubuntu and Debian, the log messages are put in /var/log/syslog file.

I am facing some problems while using the OpenHPI. What to do?

• Start the openhpi daemon with debug enabled in a terminal. (export OPENHPI_DEBUG=YES; openhpid -c /etc/openhpi/openhpi.conf -n)
• Start the client on different terminal.

• Collect the output of the both the terminals and post it to openhpi-devel <openhpi-devel@lists.sourceforge.net> mailing list

I want to use the same resource id on system reboot. Is it possilbe?

Entity path and resource id association is persistent. It is stored in auto-generated and updated uid_map file. So you can even restart openhpid and resources will be have the same ids.