# Setting Bios and Storage Controller Properties with Redfish François Donzé's profile photo François Donzé - Technical consultant, HPE July 2018 Updates: March 2024; November 2025 br The concept of deferred / pending settings in the Bios and `SmartStorageConfig` subsystems of HPE iLO 5 is briefly presented in the HPE Reference API documentation. With two examples, this document illustrates what is happening when properties are modified in those subsystems using the Redfish REST API against HPE servers. Notes - The `SmartStorageConfig` data type is deprecated in HPE iLO 6 (and later) based servers. - The latest versions of iLO 5 firmware support both the HPE `SmartStorageConfig` and the DMTF standard storage models. Volume management with controllers implementing the DMTF storage model is described in the HPE server management portal. This blog post assumes that the reader is familiar with REST APIs in general and Redfish in particular. A good entry point for developers to grasp the power of Redfish is the iLO RESTful API Ecosystem. ## Foreword For didactic purposes, direct URIs to targets are used instead of relying on crawling the Redfish tree to discover the target URIs, as explained in the Getting Started with the Redfish® API Part 2 blog post. Note that in the following paragraphs, `{{Subsystem-URI}}` refers to an URI like `https:///redfish/v1//` where `` represents either `Bios` or `SmartStorageConfig`. These subsystems contain the currently used properties. Each of them has a pending sub-zone called `Settings/` and are explained in the next paragraph. ## Deferred / pending high-level concept description 1. Modifications in these subsystems are performed using HTTP `PATCH` or HTTP `PUT` against `{{Subsystem-URI}}/`**`Settings/`**. 2. Upon a successful transaction, the HTTP return code is `200 OK` with the associated message: `One or more properties were changed and will not take effect until the system is reset`. 3. During the next system reset, the content of `{{Subsystem-URI}}/Settings/` is transferred one level up, in `{{Subsystem-URI}}/`. The return status of this transfer is present in `{{Subsystem-URI}}` with an associated message. The important thing to note in this flow is that the final status code and associated message of a property setting is visible **after the system reset**. ## Successful example In this example, a Raid1 storage array of two physical disks has been created using Postman. To achieve this goal, one needs to issue a `PUT` to `{{iloURI}}/redfish/v1/Systems/1/SmartStorageConfig/Settings/` with a body (aka payload) similar to the example shown below: ![Figure 1: Body to PUT to .../SmartStorageConfig/Settings/](/assets/1-putbody.580497c63ac1072dd08fa018605cce42a6f2628067ae3ce8f3be04f3a4ddb30d.163b50df.png) Figure 1: Body to PUT to .../SmartStorageConfig/Settings/ br Upon successful completion of this `PUT` request, the HTTP status return code is `200 OK`, which means that the remote Web server understood what to do with this well-formed payload. The Body of the HTTP response contains an `error` property with a `SystemResetRequired` message. This property is a Redfish object sent by the Redfish server. It is there to provide details concerning the next step required to complete the modification process. ![Figure 2: PUT Return Status](/assets/2-putseturnstatus.fc0011eee7c4e2c82dd2d1cb4a12194bafdd0d8c49073cae8d2de7ca224c639f.163b50df.png) Figure 2: PUT Return Status At this stage of the process, only the staging / "pending zone" of the Smart Array has changed and contains the `PUT` payload. To verify this assertion, one can compare the content of `{{Subsystem-URI}}/Settings/` with the content of `{{Subsystem-URI/}}`. In the pending zone (`.../SmartStorageConfig/Settings/`) note the payload sent to the Redfish server. As you can see, however, in the "running zone" (`.../SmartStorageConfig/`) the `LogicalDrives` array is still empty: ![Figure 3: GET Pending and Current LogicalDrives](/assets/3-getpendinglogicaldrives.85b498992041f0f2013a7fe9f7403121c0a91b83be00119d55755161f21faf72.163b50df.png) Figure 3: GET Pending and Current LogicalDrives br It is now time to reset the server and perform a `GET` of the running zone. In the response body of this operation, the first Redfish object is a `@Redfish.Settings` collection containing a single `MessageID` mentioning `Success`. This single message is synonym of a successful transfer of the "pending zone" into the "running zone". We will see later in this document what we get in case of an un-successful transfer. ![Figure 5: GET Running zone after server reset](/assets/5-getafterreset.c30e0ffe5a2347986a52c7cf252499f483d953ca52bd8169a4009d8acc58303d.163b50df.png) Figure 5: GET Running zone after server reset br Further down in this response you will find the `LogicalDrives` array containing the Raid1 disk array: ![Figure 6: GET LogicalDrives from running zone](/assets/6-getafterreset-2.4d1d69cc727967b7fdf58f6a071fb7dc65d72cf4f09f54ea571c70fc04b1683e.163b50df.png) ## Unsuccessful example In order to emphasize the fact that the modification status of properties in the `Bios` and `SmartStorage` subsystems must be done after a system reset, note the case study below where the JSON `PUT` payload is syntactically correct but embeds a value typo (`Raid` instead of `Raid1`) and is missing a required key-value (`DataGuard=Disabled`): ![Figures 7: PUT of a bad payload](/assets/7-badpayload.b0a79495158b1b3b8b8df808b29023a0d38a29a81127a118ca97985c38101ac6.163b50df.png) Figures 7: PUT of a bad payload br Sending this request returns an HTTP `200 OK` status and a `SystemResetRequired` Redfish message just like in the previous example: ![Figure 8: PUT return status of bad Redfish request](/assets/8-putreturnstatusof-badrequest.27c66c12a8447e2bc25b98405ca848d30918d2c9f70a4bdaf927eca81e924e11.163b50df.png) Figure 8: PUT return status of bad Redfish request The pending zone contains the faulty payload: ![Figure 9: Faulty payload in pending zone](/assets/9-pendingzonewithbadrequest.93a74c71c3f46126e354522cd7e81993eebbb174f1624765c24620915a329383.163b50df.png) Figure 9: Faulty payload in pending zone br After the server reset, a `GET` of the running zone responds with a `MessageArgs=[DataGuard]` object and two `MessageID`keys. The first one mentions `DataGuard` as a missing property and the second one (`Success`) means that the analysis of the transfer from the pending zone to the running zone has successfully ended. This `Success` message does not mean that the transfer has occurred. Moreover, note that there is nothing that mentions the `Raid` typo. It means that analysis of the payload to transfer stops at the first error found. ![Figure 10: DataGuard Property Missing](/assets/10-dataguardpropertymissing.79621d42cd2a992028179d24efd165fe141ca51f64d3698e851b06c2ad5e680f.163b50df.png) Figure 10: DataGuard Property Missing br If you drill down to the `LogicalDrives` array you will notice that it is still empty. Hence the transfer did not occur. ![Figure 11: Empty LogicalDrives array](/assets/11-emptylogicaldrivessrray.86d47c010918f021715e96e616d4b27ddb91c3a402d3f700ba7f1c4c05d8a644.163b50df.png) Figure 11: Empty LogicalDrives array br If you `PUT` a new payload with the `DataGuard=Disabled` property but still without correct Raid level and reset the server, you will notice an `InvalidRAIDLevel` message explaining the problem. ![Figure 12: Wrong Raid Level error](/assets/12-wrongraidlevel.ce0919255c899c0a6a7ac57752f5157f571d628626809d0f6a719f6f3fa4e86e.163b50df.png) Figure 12: Wrong Raid Level error br ## Conclusion Understanding the pending / deferred process when modifying Bios and SmartStorage properties using the Redfish API as well as the different types of return codes (HTTP, MessageID...) should ease program development and troubleshooting sessions. Don't forget to check out other [blog posts](/docs/references_and_material/blogposts/) to learn more about Redfish tips and tricks.