Browse Prior Art Database

Method for Hardware Console Surveillance in a pSeries eServer

IP.com Disclosure Number: IPCOM000014099D
Original Publication Date: 2001-Jul-23
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 40K

Publishing Venue

IBM

Abstract

A LPAR (Logical PARtition) system (in this case, a pSeries eServer) is managed by a separate standalone PC (aka Platform Management Console (PMC)). The PMC performs its tasks by sending commands to the CSP (Converged Service Processor) in the eServer system. The system administrator can configure the machine in LPAR or non-LPAR mode using the PMC. Via the PMC, he can assign system resources to partitions, handle events related to changes in partition state/status, etc.. The PMC can also run different applications other than LPAR System Mgmt. It can run applications that can be used to help service the LPARable system. For example, some service applications that run on the PMC communicate to the different partitions on the eServer system via the customer LAN. It is wanted that the CSP will know when the PMC stops communicating with the CSP so that the CSP can log an event to the partitions informing them that the PMC is no longer functioning.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Method for Hardware Console Surveillance in a pSeries eServer

A LPAR (Logical PARtition) system (in this case, a pSeries eServer) is managed by a separate standalone PC (aka Platform Management Console (PMC)). The PMC performs its tasks by sending commands to the CSP (Converged Service Processor) in the eServer system. The system administrator can configure the machine in LPAR or non-LPAR mode using the PMC. Via the PMC, he can assign system resources to partitions, handle events related to changes in partition state/status, etc.. The PMC can also run different applications other than LPAR System Mgmt. It can run applications that can be used to help service the LPARable system. For example, some service applications that run on the PMC communicate to the different partitions on the eServer system via the customer LAN. It is wanted that the CSP will know when the PMC stops communicating with the CSP so that the CSP can log an event to the partitions informing them that the PMC is no longer functioning.

This type of function is called PMC surveillance. The CSP in the eServer system can monitor presence/performance of PMC by looking for "life-signs" or "heartbeat" from PMC. The PMC heartbeat can be an explicit PMC surveillance-command or any other valid PMC command to CSP. Receipt of a PMC heartbeat by CSP will reset and restart the PMC surveillance timer. If PMC fails to send CSP its heartbeat within a default or user-defined time limit, CSP will log an error, and will report it to the operating system and the user. This approach allows PMC to be disconnected from the LPAR system temporarily (for service, etc.), so long as it is re-connected before the next PMC heartbeat is due.

The heartbeat frequency is determined by the PMC. The PMC will send down a command to the CSP indicating its heartbeat frequ...