[DISCUSSION] Drive-level power control support in phosphor-state-manager

[Andrew Geissler]

On Thu, Apr 9, 2026 at 3:50 AM Eric Yang <eric.yang.wiwynn at gmail.com> wrote:

> Hi all,
>
> I've been looking into how OpenBMC currently handles component-level
> power control for storage drives, and would appreciate some input on
> possible directions.
>
> On storage servers or compute servers with NVMe/SSD drive bays, there
> is a practical need to monitor drive power state and perform controlled
> power cycling or reset of individual drives.
>

Curious what the protocol looks like to monitor and perform the power
cycling to these drives from the BMC? Is it something simple like GPIO's or
is there something like MCTP to them?


>
> The State.Drive interface added in change 43155 [1] defines
> RequestedDriveTransition and CurrentDriveState, but I could not find
> any upstream consumer for the transition/state properties. Please
> correct me if I'm missing an existing implementation.
>

How is this managed externally into the BMC? Is there a Redfish API?


>
> If a platform wanted to support drive power control through
> phosphor-state-manager today, the options would be:
> - Map drives as additional chassis/host instances, which carries
>   incorrect semantics and breaks the Redfish model.
> - Write a platform-specific daemon outside of the state-manager
>   framework.
>
> phosphor-state-manager already has a well-established per-instance
> daemon pattern with systemd target orchestration. Following this
> pattern for drives seems like a natural fit.
>

PSM is a wrapper to systemd which starts/stops/monitors specific systemd
targets associated with the function. So would there still be a separate
application with the business logic on how to monitor and power cycle the
drives (like phosphor-power)?


>
> I'd appreciate any thoughts on the following:
> - Is there interest in drive power control as a first-class feature
>   in phosphor-state-manager?
>

I don't see a use case for my company for this function currently but I'm
not opposed to it in PSM if it makes sense. There would need to be some
synergy though. Does the general idea of monitoring and starting systemd
targets work for the use cases here?


> - Should it follow the existing host/chassis daemon pattern, or
>   should it be designed as a more generic component state manager
>   that could cover other device types in the future?
>

My preference is keep it targeted on the use case we know unless someone
has other use cases.


> - Drive instances may benefit from string identifiers (e.g. nvme0)
>   instead of numeric IDs to align with Redfish DriveId. Any concerns
>   with this approach?
>

Seems fine.


> - Should a drive's power state optionally be tied to a specific
>   host's power state (e.g. power off drives when the associated
>   host shuts down), or should drive power be fully independent?


Feels dependent on your system design. If powering off a chassis also
powers off the drives, then you can just put the systemd target responsible
for powering the drives off in the chassis-poweroff systemd target.


> [1] https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/43155
>
> Best Regards,
> Eric Yang
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20260410/b3dddd7c/attachment.htm>