User-Configurable Lightpath Policy via Systems Management
Permalink
Bookmark
Share
Twitter
Digg
Reddit
Facebook
Stumbleupon
Del.icio.us| IP.com Number | IPCOM000176603D |
|
|
|---|---|---|---|
| Dated | Nov 18, 2008 UTC | ||
| Size | 1 page(s) (21.9 KB) | ||
| Disclosed by |
|
||
Publication Summary
Different computer users interpret light-path diagnostics differently in terms of urgency, however, different hardware vendors implement different light-path schemes that often fail to meet a broad set of customer expectations. What is needed is a policy-driven approach to enable configurable light-path indications, such that a light-path can be in a verbose mode, a quiet mode, or anything in between, in accordance with customer requirements.| Country | |
|---|---|
| Language | English (United States) |
About this Publication
This document was submitted to IP.com's Prior Art Database and this preview is designed to provide you with information regarding the contents of this document by displaying up to the first four pages of the document as scaled page renderings and displaying a limited amount of text which was extracted from the document on the Text Preview Tab.
To find out more on how to obtain the entire document, click the Download tab. There is a charge for downloading some Prior Art Database documents; please examine carefully whether you believe this document fills your needs before purchasing.
For more information about the Prior Art Database, visit the Learn section of this website. Thank you for visiting IP.com's Prior Art Database! You may wish to check out our Global Patent Search website before you leave.
User-Configurable Lightpath Policy via Systems Management
In one example, there would exist at least three light-path policies: verbose, quiet, and custom.
Under the verbose light-path policy, any of a set of non-nominal conditions would result in ignition of the light-path.
Under the quiet light-path policy, only critical faults would result in ignition of the light-path.
Under the custom light-path policy, the individual lights that are ignited due to a system condition would be completely configurable.
In the preferred embodiment, a systems management device would be responsible for storing and enforcing the light-path policy. In an alternate embodiment, the ability to switch between policies could be enabled by a button on the front panel.
It is envisioned that users would be able to use Systems Management Software to make light-path policy a part of all system configurations in order to maintain light-path consistency throughout the datacenter, even when hardware is provided by numerous different hardware vendors.
In establishing a completely custom light-path scheme, it is envisioned that light-path could be a part of configuring the alerting scheme of the systems management device. That is, when a user configures alerts to be sent for a particular system condition (such as a LAN alert upon encountering a memory PFA), there can be an additional parameter to indicate whether the user wishes for a light-path indication...