openbmc/docs/host-management.md

3 This document describes the host-management interfaces of the OpenBMC object
9 [REST-cheatsheet](https://github.com/openbmc/docs/blob/master/REST-cheatsheet.md#establish-rest-con…
15 …-k -H "Content-Type: application/json" -X POST https://${bmc}/login -d '{"username" :  "root", "pa…
16 curl -k -H "X-Auth-Token: $token" https://${bmc}/xyz/openbmc_project/...
21 The system inventory structure is under the `/xyz/openbmc_project/inventory`
25 physical system topology. Items in the inventory are referred to as inventory
26 items and are not necessarily FRUs (field-replaceable units). If the system
30 `inventory/system/chassis0/motherboard0/cpu0`
35 - `Version`: A code version associated with this item.
36 - `Present`: Indicates whether this item is present in the system (True/False).
37 - `Functional`: Indicates whether this item is functioning in the system
40 The usual `list` and `enumerate` REST queries allow the system inventory
45 curl -k -H "X-Auth-Token: $token" https://${bmc}/xyz/openbmc_project/inventory/enumerate
51 curl -k -H "X-Auth-Token: $token" https://${bmc}/xyz/openbmc_project/inventory/system/chassis/mothe…
56 The system sensor structure is under the `/xyz/openbmc_project/sensors`
59 This interface allows monitoring of system attributes like temperature or
61 the top-level `sensors` object name. The path categorizes the sensor and shows
63 topology of the system.
70 - `Value`: Current value of the sensor
71 - `Unit`: Unit of the value and "Critical" and "Warning" values
72 - `Scale`: The scale of the value and "Critical" and "Warning" values
73 - `CriticalHigh` & `CriticalLow`: Sensor device upper/lower critical threshold
75 - `CriticalAlarmHigh` & `CriticalAlarmLow`: True if the sensor has exceeded the
77 - `WarningHigh` & `WarningLow`: Sensor device upper/lower warning threshold
79 - `WarningAlarmHigh` & `WarningAlarmLow`: True if the sensor has exceeded the
85 …  curl -k -H "X-Auth-Token: $token" https://${bmc}/xyz/openbmc_project/sensors/temperature/ocp_zone
95         "Scale": -3,
108 Note the value of this sensor is 34.625C (34625 \* 10^-3).
113 To enumerate all sensors in the system:
116 curl -k -H "X-Auth-Token: $token" https://${bmc}/xyz/openbmc_project/sensors/enumerate
122 curl -k -H "X-Auth-Token: $token" https://${bmc}/xyz/openbmc_project/sensors/temperature/outlet
131 BMC and host firmware on POWER-based servers can report event logs to the BMC.
137 - `Message`: The type of event log (e.g.
139 - `Resolved` : Indicates whether the event has been resolved.
140 - `Severity`: The level of problem ("Info", "Error", etc.).
141 - `Timestamp`: The date of the event log in epoch time.
142 - `Associations`: A URI to the failing inventory part.
147     curl -k -H "X-Auth-Token: $token" https://${bmc}/xyz/openbmc_project/logging/entry
166     curl -k -H "X-Auth-Token: $token" https://${bmc}/xyz/openbmc_project/logging/entry/1
178         "Version": "2.8.0-dev-132-gd1c1b74-dirty",
190 curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X POST -d '{"data" : []}' ht…
193 To clear all event logs, call the top-level `DeleteAll` method:
196 curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X POST -d '{"data" : []}' ht…
201 With OpenBMC, the Host boot options are stored as D-Bus properties under the
202 `control/host0/boot` path. Properties include
203 …BootMode`](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_projec…
204 …otSource`](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_projec…
206 …BootType`](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_projec…
208 - Set boot mode:
211 …-k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PUT https://${bmc}/xyz/openbmc…
214 - Set boot source:
217 …-k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PUT https://${bmc}/xyz/openbmc…
220 - Set boot type (valid only if host is based on the x86 CPU):
223 …-k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PUT https://${bmc}/xyz/openbmc…
227 [`Enable`](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project…
228 properties that control if the boot source override is persistent or one-time,
231 - Set boot override one-time flag:
234 …l -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PUT https://${bmc}/xyz/openb…
237 - Enable boot override:
240 curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PUT https://${bmc}/xyz/ope…
243 ## Host State Control
252 curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -d '{"data": "xyz.openbmc_pro…
258 curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -d '{"data": "xyz.openbmc_pro…
264 curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PUT -d '{"data":"xyz.openb…
270 curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PUT -d '{"data":"xyz.openb…
274 <https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State>
278 On OpenPOWER systems, the host maintains a record of bad or non-working
285 - Method 1: From the BMC command line:
289     /org/open_power/control/gard \
293 - Method 2: Using the REST API:
296 curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X POST -d '{"data":[]}' http…
299 Implementation: <https://github.com/openbmc/openpower-pnor-code-mgmt>
308 target. System settings will then determine the recovery behavior from that
309 state, for example, attempting to reboot the system.
311 The host watchdog utilizes the generic [phosphor-watchdog][1] repository. The
313 phosphor-watchdog:
316     /lib/systemd/system/phosphor-watchdog@poweron.service.d/poweron.conf
322 information for phosphor-watchdog (more information on these can be found in the
323 [phosphor-watchdog][1] repository).
328     phosphor-watchdog@poweron.service
329     obmc-enable-host-watchdog@0.service
332 `phosphor-watchdog@poweron` starts the host watchdog service and
333 `obmc-enable-host-watchdog` starts the watchdog timer. Both are run as a part of
334 the `obmc-host-startmin@.target`. Service dependencies ensure the service is
342 [1]: https://github.com/openbmc/phosphor-watchdog
344 …https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/State/Wat…