Simpler Navigation for Servers and Operating Systems
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
ProLiant Servers (ML,DL,SL)
Showing results for 
Search instead for 
Did you mean: 

How to access Hardware Information of Proliant


How to access Hardware Information of Proliant



I would like to know how the different tools get the hardware information. I mean there are different resources like lspci, SMH page, vSphere client. All seems to be able to collect the hardware information freely even if they are not provided by HP. Is there any sort of standard by which independent vendors can query HP system? Also what are the tools that can report wealth of inromation cross-operating system? The tools seem to report information incosistently. For instance, sometimes lspci cannot report something which vSphere can report. Also the information is sometimes incomplete. For instance, the CPU is reported to be Genuine Intel 2.0 GHz. where as I would like to more about like whether it is Xeon or Core 2 etc. So I would like to know about a list of tools where I can use alternative tools if one of the tools fail.



Honored Contributor

Re: How to access Hardware Information of Proliant



The information avalible to you is from SNMP and WMI (WBEM).


Other Vendors like Vmware probably uses API's to HP system Bios and/or ILO

Honored Contributor

Re: How to access Hardware Information of Proliant

The PCI bus standards include a standardized method for identifying devices attached to the PCI/PCI-X/PCI-Express bus. The information is in the form of vendor/device/subvendor/subdevice ID numbers. On Linux systems, there is a file containing a list of known PCI ID numbers: it is usually located at /usr/share/misc/pci.ids. The "lspci" command uses this list to identify PCI devices using their ID numbers. The lspci command is independent of device drivers: because it uses the standard identification methods included in the bus technology, it can query any PCI-compatible device. On the other hand, it can display only the information encoded in the standard identifiers: an appropriate device driver can often find out more using device-specific methods.


(On Debian, you can update the pci.ids table to the latest available version with the command "update-pciids": other distributions may have something similar, or you can just download the latest version of the file from and replace the standard version with it manually. This will only affect "lspci" and similar hardware information gathering tools: driver modules have their compatibility information encoded into the drivers themselves.)


Another standardized information source is DMI: the "dmidecode" command can usually find and decode quite a bit of information on the system, including things like the system serial number.


Memory DIMMs each have a small standardized SPD data chip that identifies the manufacturer, model, size and access properties (speed, wait state requirements, etc.) of the memory: if your system allows access to the chipset i2c bus (and there exists an i2c driver for your chipset), then the SPD data can be read and used to describe the memory configuration.


On Linux at least, the "hp-health" apparently provides the SPD access and perhaps some other HP-proprietary hardware information sources. The "hp-snmp-agents" collect hardware information from both the standard sources and from hp-health and make it accessible by the SNMP service of the system. The SMH mostly just takes what is available via the SNMP service and presents it in a nice web UI.


The CPU model information is also encoded in numeric format. The exception is the "GenuineIntel" string: it is actually included in the processor as text (for copyright/trademark reasons, I guess). Although the basic CPU type information is available in Linux with "cat /proc/cpuinfo", there are dedicated tools like the "cpuid" command which can dig a bit deeper and usually will decode the model codes into human-recognizable model names. (Obviously, the tool needs a table of known model numbers vs. names: if the CPU is newer than the table included with the tool, complete decoding may not be possible.)