Power state management

[vpenso]

Proposal

Add power $action sub-command for managing the power state of a system:

bmctl power {on|off|reset|...} $target

The command should monitor the system and block until a the target state has been reached.

Action	ResetType	Description
on	on	Turn on
off	ForceOff	Non-graceful power off
shutdown	GracefullShutdown	Graceful power off
reset	ForceRestart	Non-graceful reset
reboot	GracefulRestart	Graceful restart
cycle	PowerCycle	Power removal & restore
fullcycle	FullPowerCycle	Like above + Remove utility lines

RedFish REST API

Following an example how to reset a system ...uses ResetType¹

curl ... -X POST "https://${bmc_fqdn}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset" \
      -H "Content-Type: application/json" \
      -d '{"ResetType": "ForceRestart"}'

Redfish presents the PowerState² at

curl ... -X GET "https://${bmc_fqdn}/redfish/v1/Systems/1" | jq .PowerState
"On" # or Off, PoweringOn, PoweringOff

Nice To Have

Consider monitoring of the Oem.*.PostState³

At the moment it is unclear to me how to understand intermediate boot states, for example a system that is in the process of a reboot, but can not properly halt the OS. Another example would be a PXE boot that hangs (for whatever reason).

Vendor specific implementation of PostState may help to determine intermediate states (for example Pre-OS Tasks (POST), Operating System (OS) running).

# example of an xFusion node
>>> curl ... -X GET https://${bmc_fqdn}/redfish/v1/Systems/1 | jq '.PowerState, .Oem.xFusion.PostState'
"On" 
"FinishedPost" # may be PowerOff InPost InPostDiscoveryComplete FinishedPost

Investigate useful information from the LogEntry⁴ related to booting.

Sensor type to which the log entry pertains

SensorType	Description
BaseOSBoot/InstallationStatus	A sensor for a base OS boot or installation status event.
Boot Error	A sensor for a boot error event.
OS Stop/Shutdown	A sensor for an OS stop or shutdown event
System ACPI PowerState	A sensor for an ACPI power state event.
System Firmware Progress	A sensor for a system firmware progress event.
SystemBoot/Restart	A sensor for a system boot or restart event.

curl ... -X GET https://${bmc_fqdn}/redfish/v1/Systems/1/LogServices/Log1/Entries | jq
# OEM specific
curl ... -X GET https://${bmc_fqdn}/redfish/v1/Systems/1/LogServices/Log1/ | jq '.Oem.xFusion'

Footnotes

1. RedFish ResetType Definition, DMTF
   https://redfish.dmtf.org/schemas/v1/Resource.json#/definitions/ResetType ↩

2. RedFish PowerState Definition, DMTF
   https://redfish.dmtf.org/schemas/v1/Resource.json#/definitions/PowerState ↩

3. PostState HPE Example
   https://sourceforge.net/p/redfish-lab/wiki/Master-the-Redfish-Server-States ↩

4. RedFish LogEntry Definition, DMTF
   https://redfish.dmtf.org/schemas/DSP2046_2022.2.html#logentry-1130 ↩

[dennisklein]

As an alternative to polling (which is expensive and may suffer from aliasing), there is also https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2025.2.html#eventservice-1110. The hope would be that one could

1. subscribe to events
2. trigger system reset
3. listen to events until desired state after server reset has been reached

[dennisklein]

Sending the reset signal via gofish seems straightforward: https://pkg.go.dev/github.com/stmcginnis/gofish@v0.20.0/redfish#ComputerSystem.Reset

[vpenso]

As an alternative to polling (which is expensive and may suffer from aliasing), there is also https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2025.2.html#eventservice-1110. The hope would be that one could

1. subscribe to events

2. trigger system reset

3. listen to events until desired state after server reset has been reached

Handling of events would be based on an HTTP POST operation to a listener URL... for the moment I would like to investigate if we can come up with a simpler approach without such a reqirement