Hardware Management Console (HMC)
Briefly, what is an HMC?
 |
An HMC is a single-purpose closed appliance for controlling multiple System p and/or System i servers. An HMC connects to the service processor of each POWER5 server via an Ethernet network and allows the servers to be managed, including power up/down, starting, stopping, and configuring Logical Partitions (LPARs), accessing each LPAR's system console, and installing firmware. A systems administrator can sit at the HMC or remotely access it. An HMC is an IBM PC with special software (referred to as machine code) installed. Because an HMC is built using commodity hardware and can manage multiple servers, acquiring an HMC does not add much to the total cost of a solution. At left is a picture of a desktop HMC but many customers prefer the 1U rack-mounted version. |
Key sites for more information
For information regarding an HMC running V7 machine code, see the Hardware Management Console Version 7 web page in the IBM Systems Hardware Information Center. For information on using the HMC, follow the link to the Operations Guide for the Hardware Management Console and Managed Systems.
 | Notes
- In order to manage servers with POWER6 processors, an HMC must be running V7 machine code. That is, an HMC running V6 machine code and below can manage servers with POWER5 and POWER5+ processors, but can not manage servers with POWER6 processors.
- HMC hardware with machine type 7042 can only run V7 machine code. That is, HMC V6 machine code and below can not be installed on HMCs with machine type 7042.
|
For information regarding an HMC running V6 and V5 machine code, see the Hardware Management Console Version 6 and Version 5 web page in the IBM Systems Hardware Information Center. For information on using the HMC, follow links to Managing the HMC, to Managing your server using the HMC, and to HMC commands (command line commands).
For information regarding an HMC running V4 machine code, see the Model 7048 Hardware Management Console for pSeries web page in the IBM Systems Hardware Information Center. For information on using the HMC, follow the link to the eServer Hardware Management Console for pSeries Installation and Operations Guide .
See the HMC Support (for UNIX servers and Midrange servers) web site. Among many other things, the command line specifications for versions prior to V6.1 can be found on the Related documentation web page here. The HMC Recovery DVD V5 R1.0 can be downloaded from here, as well.
See the other Hardware Management Console web page on the Virtualization Wiki. 
Hint: Be sure to follow links from there to other pages. For example, for help discovering the physical locations of the various HMC ports (eth0, eth1, etc), follow the link to HMC and System Setup (in the More HMC Pages in this WIKI section of the other Hardware Management Console web page) and scroll down to the HMC - identifying the network ports section of the HMC and System Setup web page.
See the Effective System Management Using the IBM Hardware Management Console for pSeries Redbook.
See the IBM Hardware Management Console (HMC) Best Practices Whitepaper.
See the Hardware Management Console External Connectivity Security for IBM POWER Processor-based Systems Whitepaper.
Reliable communication between the HMC and managed p5 servers
An HMC connects to managed POWER5 servers using Ethernet. As stated in the Types of HMC network connections article in the POWER5 Managing the Hardware Management Console manual, an HMC has several network connections. The discussion below will focus on the network connection used by the HMC to communicate with Flexible Service Processors (FSPs) in managed servers. The discussion below is intended to supplement (not replace) information provided in the Cabling the HMC article in the POWER5 Managing the Hardware Management Console manual.
If only one p5 server is being managed, use an Ethernet cable to directly connect the HMC to the HMC1 port on the managed server. A crossover cable is not required. An ordinary Ethernet cable will do.
If multiple p5 servers are being managed, connect the HMC to a Ethernet switch and connect the HMC1 port on each of the managed servers to the switch. If HMCs are configured as DHCP servers, there must be only one HMC connected to the switch! (If a redundant HMC is desired, connect it to a second switch and connect the HMC2 port on each of the managed servers to the second switch. If the HMCs are configured as DHCP servers, make sure the second HMC is configured to use a different DHCP IP address range than the first one!)
A switch can be partitioned to create a VLAN dedicated to HMC to managed server communication. If HMCs are configured as DHCP servers, there must be only one HMC on each VLAN! If dual HMCs are attached for redundancy, it is unwise to connect the HMCs to two VLANs in the same switch, because if the switch fails both HMCs lose connectivty, thereby defeating the HMC redundancy.
As stated in the Types of HMC network connections article, the physical Ethernet network by which the HMC connects to managed servers should be used exclusively for that purpose, meaning that only an HMC's network interface and managed systems' HMC ports are on that network. If an application failure on an LPAR creates a network storm, it is very important that the storm not affect HMC communication with managed servers. That's because the HMC must communicate with a managed server to access the AIX system console of an LPAR running on the server. If a network storm is being generated by an LPAR, accessing the LPAR via the AIX system console is the cleanest way to halt the storm. But if the storm spreads onto the network by which the HMC communicates with the managed server, it won't be possible to access the LPAR's system console. So connect only an HMC's network interface and managed systems' HMC ports to the network which connects HMCs and managed servers.
If an HMC can not see a managed server, make sure there is network connectivity. Pull the Ethernet cable from the HMC1 (or HMC2, as applicable) port of the managed server and plug the cable into a laptop configured for DHCP. Make sure the laptop gets an IP address in the range which the HMC is configured to serve. Make sure the HMC's Ethernet interface can be pinged. (On the HMC GUI, use HMC Management -> HMC Configuration -> Customize Network Settings -> LAN Adapters. to determine the IP addresses that each of the HMC's interfaces are configured to use. Use the Details... button to determine what IP address range the HMC is configured to serve. See the Types of HMC network connections article in the POWER5 Managing the Hardware Management Console manual to understand for what the HMC's network interfaces are used.) (When an HMC's DHCP server gives out an IP address, the IP address (and the MAC address to which it was issued) is cached in a leases file. Provided only a few different laptops are used to check HMC connectivity, only a few IP addresses will be consumed from the IP address range with which the HMC's DHCP server is configured.)
If a laptop takes a while to acquire an IP address from the DHCP server on the HMC, then the Flexible Service Processor (FSP) in the p5 may not be able to acquire an IP address quickly enough and will go to its default IP address. If a switch uses the Spanning Tree protocol, heed the admonition in the Troubleshooting HMC setup article in the POWER5 Managing the Hardware Management Console manual and enable PortFast on every port destined (or used) for p5 managed servers. For more information regarding PortFast, please see the Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays article.
In p59x servers, each HMC port is connected to an internal Ethernet hub, which is in turn connected to Flexible Service Processors and Bulk Power Controllers within the p59x. Because each FSP and BPC connected to the hub has its own MAC address, implementing Port Security will cause problems. Do not implement Port Security on switch ports to which p59x HMC ports are connected. There are likely other Ethernet switch security measures that will also cause problems if they are enabled on switch ports connected to HMC ports on p59x servers.
Configuring a switch port for 100 Mbps full duplex can create a duplex mismatch, according to the Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues web page. As noted on the web page, "A duplex mismatch may result in performance issues, intermittent connectivity, and loss of communication." Since there is no way to configure an FSP for anything other than autonegotiate, Ethernet switch ports used for FSPs (and used for an HMC, if the HMC's network interface is configured for autonegotiate) must be configured for autonegotiate to avoid a duplex mismatch.
Hint: Issue the command lsrsrc IBM.ManagementServer on an AIX LPAR to determine which HMC(s) are managing DLPAR operations for that LPAR.
If HMC performance is sluggish
If HMC performance is sluggish, the first step is to close all resolved serviceable events using Service Applications -> Service Focal Point -> Manage Serviceable Events on the HMC graphical user interface.
If there are lots of b3xx (eg, B3030001) serviceable events, a prime suspect is the duplex mismatch issue described above.
AIX LPARs will sometimes erroneously send duplicate serviceable events to the HMC. AIX V5.3 APAR IY91467 ("535 TOO MANY #2601902 ERRORS SENT TO SFP") documents the defect. A fix for the APAR is available in TL05. An Interim Fix can be built on TL04 if required. A circumvention is documented in APAR IY91467's Local Fix section which can be used rather than installing a fix. Keep in mind that a fix, to be effective, must be implemented on all LPARs which communicate with the HMC.
If SCAN_ERROR_CHRP errors are found in AIX errpt and the entries refer to Maintainence Procedure FSPSP33 ("A problem has been detected in the connection with the HMC"), a prime suspect is the duplex mismatch issue described above.
Some known performance problems in earlier versions are fixed in HMC V6.1. Open a software problem with the IBM Support Center if HMC performance is still poor after taking the steps documented above.
Hint: VNC can be used to improve performance of WebSM when accessing an HMC remotely. See Improving remote HMC performance, one of Bruce Spencer's AIX Tips. (This advice is not applicable for HMC V7 and above, since a web browser is used for remote access rather than WebSM.)
The postings on this site solely reflect the personal views of the authors and do not necessarily represent the views, positions, strategies or opinions of IBM or IBM management.
Doing without an HMC
Only p5 Models 590 and 595 and p6 Model 570 require an HMC to successfully power up. (A p5 Model 590 or 595 is usually connected to two HMCs, so it can power up even if one HMC is down. An HMC which manages a p5 Model 590 or 595 must be configured as a DHCP server.) An HMC is also required for:
If there is no HMC, the Integrated Virtualization Manager (IVM) is required to configure LPARs. The IVM imposes significant restrictions. See the Do I really need an HMC? post in the pSeries Tech Talk Forums for more discussion regarding IVM limitations.
Unless an HMC is required as described above, a server can be managed without an HMC. A terminal server can be connected to a System p system port to permit most remote management functions to be performed. As stated in the Requirements needed by service personnel article, in order to deliver service and support of System p server hardware under an IBM maintenance contract, an IBM Systems Service Representative (SSR) must have access to a system console which is in the same room and within 8 meters (26 feet) of the system being serviced. If a server is managed by an HMC, the requirement can be satisfied by a portable device with a web browser which can be operated (by the IBM SSR) within 8 meters of the managed server and which can connect to the HMC over a network. 
To allow a hung system to be reset remotely, see the Enabling serial port snoop article.
Please note that System p system ports are not serial ports. System ports work properly only with approved call-home modems, async terminals, and certain UPSs. System ports are disabled when a Hardware Management Console (HMC) port is connected to an HMC. Either the HMC ports can be used or the system ports can be used, but not both. A Flexible Service Processor (FSP) monitors the system port if there is no HMC connected. The FSP has power and is active if the line cord is plugged into a power receptacle, even before the System p server powers up. The FSP is intended for use by an IBM CE/SSR. It detects every ASCII character sent to the system port and may react in unexpected ways to system port input. It is, therefore, crucial that a terminal server be tailored so that it never automatically sends anything to a System p system port. A terminal server must be tailored to send characters to System p system ports only when a user logs in to the terminal server, connects to a system port, and types something after the connection to the system port has been established. For example, on CISCO terminal concentrators, the settings for the port connected to a System p system port should look like:
CISCO-TC#sh line 68
Tty Line Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int
1/2 68 TTY 19200/19200 - - - - - 22 0 0/0 -
Line 1/2, Location: "", Type: "VT100"
Length: 24 lines, Width: 80 columns
Baud rate (TX/RX) is 19200/19200, no parity, 2 stopbits, 8 databits
Status: Ready
Capabilities: EXEC Suppressed, MOTD Banner Suppressed
Modem state: Ready
Modem hardware state: CTS* DSR* DTR RTS
Special Chars: Escape Hold Stop Start Disconnect Activation
^^x none - - none any
Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch
00:10:00 never none not set
Idle Session Disconnect Warning
never
Login-sequence User Response
00:00:30
Autoselect Initial Wait
not set
Modem type is unknown.
Session limit is not set.
Time since activation: 00:00:00
Editing is enabled.
History is enabled, history size is 20.
DNS resolution in show commands is enabled
Full user help is disabled
Allowed input transports are telnet.
Allowed output transports are none.
Preferred transport is telnet.
No output characters are padded
No special data dispatching characters
CISCO-TC#
Note: For documentation of terminal emulation settings required by a System p system port, see the Accessing the ASMI using an ASCII terminal article in the Managing the Advanced System Management Interface (ASMI) manual.
Note: When managing a System p server without an HMC, it may be beneficial in many cases to connect the HMC ports of the server to a network and to manage the server using the Advanced System Management Interface (ASMI) via a web browser as well as an ASCII terminal.
Warning: If a System p server is able to power up successfully with a terminal concentrator/server attached to a system port and if the concentrator/server is not tailored to suppress output to the system port, then errors might occur on the system port, in which case entries may be seen in AIX errpt which are similar to:
If those errors are not resolved and continue to occur, they can lead to an AIX console hang, which can in turn lead to a complete AIX/server hang!
| Please help!
There are very likely a number of procedures (in addition to configuring LPARs) which are more difficult (or impossible) when managing a server using the ASMI rather than an HMC. If such procedures are not identified here, please use the  Add Comment link at the bottom of the page to identify them. Thanks!
(Note: Until you sign up and log in (using links in the upper right corner of this web page), you will not see the Add Comment link and you can not add a comment. |
How to setup AIX SSH to communicate with HMC
1. Download and install SSL and openSSH on AIX client
Note: After the SSL and OpenSSH have been installed it will create a directory called "/.ssh"
2. Generate the priv/pub keys on AIX client
Note: This will create id_rsa and id_rsa.pub files
3. From AIX client add public key to HMC