• Login
• Become a member
• RSS
• Part of the TechTarget network

What are some common mistakes made when using IPMI?
The biggest mistake one can make is to not use it [because] IPMI is a pre-integrated management feature in servers. In fact, the Aberdeen Group -- an industry research firm -- stated in an August 2003 white paper that IPMI has become a checklist requirement for IT [when] evaluating infrastructure needs. So, what's the end result of IPMI's work in this situation?
In summary, IPMI helps minimize overall downtime and costs during the server life cycle by speeding the initial provisioning process, eliminating the need to physically visit the server to diagnose and rectify problems, to have some kind of predictive failure notification prior to system outages and to perform more intelligent diagnostics before dispatching personnel. In this case, what would have happened without IPMI?
Without an IPMI-enabled system, the administrator would have to visit the remote location to reboot the hung server, resulting in extra time and costs. With IPMI, the server can be remotely rebooted with a simple standardized IPMI reset command. Additionally, by viewing the IPMI event log, failing components are more readily identified. When IPMI identifies whether a problem arises from software versus a hardware issue, it arms administrators with more knowledge to improve [their] diagnosis before having to dispatch service personnel.

Using additional features like console redirection and virtual media, IT

can interact and view the boot process [or] use files from a remote console to run diagnostics or flash firmware. IPMI 1.5 offers multi-layered passwords and MD2 or MD5 signatures for additional security to ensure only known administrators have access. What happens if there is a failure?
Let's assume that a remote server OS hangs. Without IPMI, the administrator cannot reconnect to the server agents or console from a remote location. With IPMI, the administrator can check the server's operational status -- temperature, fans, voltage, drive errors and other components -- by retrieving the server event log stored on the BMC. He finds no other events that may have indicated specific hardware problems that would have led to a hung OS. A simple reboot appears to be the remedy. What happens when the server is in production?

IPMI is not a replacement for existing management technologies; it's a complementary technology that improves system health. Steve Rokov Director of technical marketingOSA Technologies

With the server in production use, an administrator can view a server's operational status via a centrally located console. Assuming a malfunction occurs, such as the temperature rising in a server, the IPMI-enabled system would immediately send an event alert to the pre-identified remote console. This is regardless of whether the OS is running or not. Because IPMI sends the alert prior to the crash, the server administrator can inform staff to perhaps replace the fan or schedule a shutdown. The opportunity to have this level of predictive failure notification prior to components' failing can make a huge difference on overall service availability. Could you offer some specific examples of IPMI in action in the enterprise?
As an example, consider the process of taking 'bare metal' servers into production. Many management techniques and software that do this require some knowledge of the server's hardware in order to provision them with the correct OS, drivers, applications and network settings. Typically, PXE boots and multiple OS image downloads are required. Sometimes not all the information can be captured. With IPMI, the server can describe itself -- meaning that, with IPMI utilities, a more immediate and accurate server hardware asset template can be developed. And, with a better idea of the target server's configuration, more intelligent decisions can be made. Overall, using IPMI can speed the provisioning process of taking servers into production. How is IPMI usually deployed today?
IPMI is implemented as firmware running on a dedicated controller chip -- also known as a baseboard management controller, or BMC. Typically, the BMC is on the system motherboard, or blade. A BMC is used with IPMI firmware to create the basis for a standalone platform management subsystem -- independent of processors, the BIOS and the OS. This is the key concept to grasp, as it allows for manageability, monitoring and recovery during states where the system processor, BIOS or even the OS is not available.

These characteristics remove limitations encountered with all OS-dependent management agents, such as when the OS is hung up. However, IPMI is not a replacement for existing management technologies; it's a complementary technology that improves system health. Finally, by implementing IPMI manageability as a separate subsystem within a platform, management software is abstracted from platform hardware management, meaning the same software can manage other IPMI systems, so long as they have IPMI-compliant firmware.

Join the conversationComment

All Rights Reserved,Copyright 2003 - 2013, TechTarget