Browse Prior Art Database

Mechanism for utilizing CIM industry standard to recover from failed / non-responsive storage device situations Disclosure Number: IPCOM000083338D
Original Publication Date: 2005-Mar-01
Included in the Prior Art Database: 2005-Mar-01
Document File: 2 page(s) / 67K

Publishing Venue



Recovering non-responsive storage devices via SMI-S

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Mechanism for utilizing CIM industry standard to recover from failed / non-responsive storage device situations

Main Idea

When a controller device (specifically virtualization device) loses contact with a storage controller there is no mechanism to attempt to recover the controller without user intervention. For example a bug in the controller firmware may result in the device hanging, where there is no specific issue with the connectivity of the device or its disk drives, but the using system (virtualization appliance or host) cannot perform IO operations.

    Today the only solution to such a problem is for an operator to physically reset (power cycle or soft reset) the controller device.

    The main players in the storage industry have recently produced and are actively coding to a new SNIA industry standard API for the management of SAN attached devices. This API is known as the Systems Management Interface Specification (SMI-S). Using the appropriate APIs from the SMI-S, a controller that supports the standard can recieve an out of band (usually ethernet based) request to attempt the reset or recovery of the device, allowing the device to return to a useful state and allow IO to continue to its storage devices, noteably without user intervention.

Figure 1 shows the various components involved :

[This page contains 1 picture or other non-text object]

Page 2 of 2

    In the system described, the Server (130), Virtualizer (100) and Storage Controller (110) are all connected to an Ethernet network (200). The Virtualizer (100), Server (130) and Storage Controller (110) are also connected to a SAN Fabric (usually Fibre Channel based fabric) via the SAN Switch (120)

    Each device in the SAN that conforms to the SMI-S standard contains a local (to the device) CIM provider which models the device specific attributes and functions into the SMI-S standard and exports an API over the ethernet. In general a CIMOM (Common Interface Model Object Manager) is required to manipulate, store and act upon the objects and functions exported via the API. Such a CIMOM can run in any suitable device (another host server or even one of the SAN devices itself, such as the virtualizer)

    In the scenario described above, the Storage Controller (110) firmware has encountered a problem tha...