Browse Prior Art Database

Method For Retrieval and Persistent Storage of Managed System Dumps by HMC

IP.com Disclosure Number: IPCOM000012754D
Original Publication Date: 2003-May-27
Included in the Prior Art Database: 2003-May-27
Document File: 3 page(s) / 48K

Publishing Venue

IBM

Abstract

Disclosed is the method used by Hardware Management Console (HMC) for the retrieval and persistent storage of managed system dumps.

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

Page 1 of 3

Method For Retrieval and Persistent Storage of Managed System Dumps by HMC

Platform or partition dumps can be generated at any time by converged PowerPC* pSeries/iSeries. Platform dumps can be generated by system hardware, hypervisor, power subsystem, or Flexible Service Processor (FSP), while partition dumps can be generated by operating system images running on logical partitions (LPARs). One or more system can be managed by one or more Hardware Management Consoles (HMCs), whose role is that of management appliance. As such, a primary responsibility is service of managed systems. Hence the aforementioned dumps should be collected and brought to the attention of interested service entities for appropriate analyzation and support.

The essence of the problem can be reduced to 1) retrieval of the dump by the HMC from FSP storage, and 2) storage and exposed availability of said dumps after retrieval. An obvious solution would be for the HMC to open the dump file and read in the contents into an in-memory buffer, such as a byte array allocated on the execution space's heap. This solution is not robust, and too rigid. No accountancy is undertaken by the HMC dump consumer process for HMC <-> FSP communication channel bandwidth or data integrity. Current designs and implementations rely on an ethernet attachment between HMCs and FSPs. While this can support much more throughput than previous serial line attachments, no assumptions can be made of the number of established channels. Since multiple HMCs and FSPs can communicate over the same ethernet, bandwidth hogs are not desired, especially should the medium change. In addition, dumps can be of large sizes. Should TCP experience integrity or other transmission errors, it's unfair to discard the entire dump. Finally, in-memory storage is undesired as there should be little doubt as to accommodation capability for these large dumps. We don't want to cap the size of dumps that can be retrieved due to memory constraints. Even if memory capacity isn't an issue, what is the availability of the retrieved dump(s)? Is it only the consumer process? All service entities must be accepted clients with the consumer process. This doesn't allow for third party tools running independent of the consumer process to access the dump(s). A dump can be in a proprietary format such that only these third party tools can correctly interpret it. Also, the lifetime of availability of the dump is that of the consumer process, disallowing potential future references after the consumer process has expired.

This invention is that of a process that retrieves dumps from FSP persistent storage piecemeal-wise by fragmenting the dump. When a dump's existence is brought to an HMC's awareness by the hosting FSP, the HMC's dump retrieval process incrementally builds up the dump by reading in segments of the dump. The size of each segment is a predetermined agreed-upon value between the HMC and FSP. This value isn't static and...