View Only

Redfish in Blue waters

By Ratan Gupta posted Thu June 11, 2020 11:53 PM


Yet Another fish in the sea?

What drives the need for yet another platform management protocol you may ask. And it's quite natural since a majority of the servers already support CIM, IPMI/DCMI and perhaps a vendor defined RESTful API.  Each of these interfaces have their relative strengths and weaknesses in meeting common customer demands such as:

  • Is it supported by all systems of the vendor?
  • Is it supported across multi-vendor systems?
  • Does it scale well across low end and high end systems?
  • Is the tooling ecosystem well supported by the community?
  • Does it require specialized skills to develop and maintain?
  • Does it weaken the security of my installations?

Redfish motivation & Overview

One critical requirement for management scripts is that they be written once and exercised across different type of servers from the vendor, preferably across different generations of systems as well. IPMI had been the defacto management interface for more than a decade.  Fragmentation crept in as vendor extensions became necessary for the protocol to be even usable. Hence multi-vendor system management implied complex vendor specific customization to the management tools/scripts. While IPMI fits the bill for an efficient embedded management interface, it lacks the scalability to support enterprise class systems. The abstraction of 8-bit Sensor ID for the managed resources is a limitation for supporting IPMI on multi-node enterprise class servers. DCMI attempted to address the fragmentation but scalability is a core protocol limitation with no backward compatible resolution. The binary encoding of IPMI imposed the need for deep protocol skills for creating the management client scripts. CIM did not gain the expected adoption in spite of the scalability and extensibility improvements over IPMI, primarily due to the complexity of the protocol and the tool chain. To compound matters, numerous security vulnerabilities in the core IPMI protocol and its implementations are widely available on the internet. IPMI and CIM both open up additional network ports on the system which increases the attack surface.

DMTF Redfish is a platform management API standardized by the SPMF working group (http://www.dmtf.org/standards/redfish). Redfish ecosystem consists of many server and silicon manufactures providing leadership and enjoys support from many hardware and software companies including IBM. Furthermore, Redfish is expected to replace IPMI in the OpenCompute project as the interface of choice for platform management. Swordfish is an extension to Redfish to enable management of storage appliances and services in the data center. TGG and ASHRAE are adopting Redfish for power and thermal management in the data center.
Redfish Figure 1

Redfish builds on a RESTful architecture and defines the managed resources for platform management which are accessed through hypermedia API. Redfish protocol (RESTful hypermedia API) is defined independent of the data model (schema for managed resources) allowing them to evolve independent of each other. The protocol itself is expected to evolve slowly, while the data model is expected to go through revisions to support various management features. System, Chassis and Managers are top level collection resources modeled in Redfish (see image below). Apart from resources, Redfish defines key services such as Sessions, Events and Tasks. Sessions service help in creating a secure, authenticated user session. The X-Auth-Token generated during session creation must be used in further client/server messages. Events service provide a publish/subscribe framework for clients to subscribe to interesting events on the system. Servers can asynchronously publish events to subscribers (push model). Tasks model "long running" transactions on the system, such as a firmware upgrade, whose progress needs to be tracked.
Redfish Figure 2

Motivation & scope for Redfish in IBM POWER8 Systems

More often, the workloads on IBM Power systems need to deliver maximum performance. Since performance has significant impact on the energy footprint, it is necessary to exercise the power management controls on these systems to strike the right balance. The EnergyScale provisioning controls on Power systems are distributed across the IPMI/CIM, HMC & ASMI; i.e. the low level controls are available only through ASMI which limits the automation capability. The decision to implement power management capability over Redfish was to address the current and future requirements of client deployments having a mix of enterprise class and OpenPOWER systems. Implementing the same over an HMC interface or over IPMI would have limited the benefit to a subset of the system types.

The scope of Redfish API support on P8 servers is predominantly to enable provisioning of Power Management tunables (EnergyScale) parameters and monitoring power and thermal data. Redfish interface is enabled on firmware level FW860.20 and the service is automatically available on HTTPS (443) port. i.e no specific configuration is necessary to enable the Redfish service on the FSP.

Managing IBM POWER8 Systems using Redfish

IBM Power server supports DMTF Redfish API (DSP0266, version 1.0.3 published 2016-06-17) for systems management. The firmware on the P8 systems must be upgraded to FW860.20 or above to manage them using Redfish. There are no user configurable controls to enable/disable Redfish service on POWER8 systems. Redfish service runs on HTTPS port (443) ensuring that there are no additional security vulnerabilities or exposures. Simple management tasks can be achieved using command line tools such as cURL. However python is the preferred scripting language since it provides a variety of helper modules upon which complex management logic can be built. DMTF has published redfishtool (https://github.com/DMTF/Redfishtool), a CLI based tool to interface with the Redfish service on servers.

Depending on the current firmware level and network deployment, you may need to do the following:
  •   Upgrade the server firmware level to FW860.20
  •   Install python on the *client* system (typically a Linux host)
  •   Download/Install the DMTF redfishtool
  •   Identify the IP address of the FSP (e.g. from the connected HMC)
  •   Setup ssh tunnel to the FSP through the HMC
  •   Run redfishtool with suitable arguments

ssh tunnel setup to the FSP through the HMC

So you have the FSP deployed behind an HMC and the Linux host where you intend to run the redfishtool can't directly reach the FSP?  You can setup an ssh tunnel between the Linux host and the FSP through the HMC. Here is how.

Example commands for setting up ssh tunnel (local port forwarding) from the
Linux host Argus( to the FSP( via the HMC(
Argus$ ssh -L 9000: hscpe@
hscpe@'s password:
Last login: Wed Feb 08 11:29:20 2017 from
Traffic flow: Argus ( : 9000) <---> HMC ( <---> FSP
( : 443 )
For additional info/help on scripting commands over an ssh tunnel refer https://gist.github.com/scy/6781836

Instead of targeting the Redfish requests to the IP address of the FSP, setup the ssh tunnel as above and send the Request to the mapped port (9000) on the client ( i.e. the domain of the URI for the requests must be for this example. 

Interacting with the Redfish service

To interact with the Redfish service, complete the following steps.
  1. Create an authenticated login session (POST method on the /redfish/v1/SessionService/Sessions resource).
  2. Extract and save the following details:
    • Authentication token (found in the X-Auth-Token header of the response)
    • Session URI (found in the Location header of the response)
  3. To read the properties of a resource, send a GET request with the X-Auth-Token header for the URI of the resource
  4. To set a property of a resource, send a PATCH request with the X-Auth-Token header for the URI of the resource, the property name, type, and value encoded as a JSON body
  5. Extract and parse the response from the Redfish service containing the JSON body

Redfish service home-page

The *home page* URI for the Redfish service (a.k.a  Service ROOT) can be accessed by retrieving the URI: https://<ip:port>/redfish/v1. The ip:port corresponds to the IP address of the FSP and port number (typically 443) where the Redfish service is running on the FSP.

The response to a GET request to this URI provides a high level *site map* to enable a traversal of the service using a hypermedia API paradigm.

Validating the data returned by the Redfish service

The format and structure of  the data is defined in the  *schema* files. Schema files define the type and properties of resources defined in Redfish. Schema files are JSON files which help in:
  1.   Structuring the data for POST/PATCH requests
  2.   Parsing the data sent by the Redfish service
  3.   Validating the response body sent by the Redfish service
i.e. Schema files *describe* the data sent by the Redfish service.

Resource returned by the Redfish service contain the @odata.type property. The value of the property @odata.type in the response is a string of the format *#<namespace>.<type>, where the <namespace> is of the format <name>.<ver>

When the namespace contains the prefix "IBMEnterprise", it is an OEM type defined by IBM and its schema file can be downloaded from the IBM schema repository. 

When the namespace does not contain the "IBMEnterprise" prefix, it is a standard type defined by DMTF and its schema file can be downloaded from the DMTF schema repository.

Locating Schema files

DMTF publishes the schema files for the *standard* data used in Redfish. The Redfish schema files, in JSON format, are hosted in the DMTF schema repository at: http://redfish.dmtf.org/schemas/v1/

IBM publishes the schema files for the *OEM extensions* to the Redfish schema (e.g. the EnergyScale extension for Power Management).

The OEM schema files published by IBM are identified by "IBMEnterprise" in the namespace of the schema. These schema files have a file name prefix of "IBMEnterprise". e.g. IBMEnterpriseEnergyScale.v1_0_0.json.

OEM schema files published by IBM can be downloaded from the IBM Schema repository at: http://public.dhe.ibm.com/systems/power/redfish/schemas/v1/

A copy of the the Redfish schema files in JSON format published by the DMTF (http://redfish.dmtf.org/schemas/v1/) are packaged in the firmware image.

The schema files are distributed on chip to enable proper functioning in deployments with no WAN connectivity.

Redfish resources in POWER8 servers

System, Chassis, Processor, Core and BMC are the resources modeled in the Redfish implementation in FW860.20. FW860.30 adds capability to read the Power and Thermal resources of the Chassis. Session Service is the only service currently supported. Support for Event service will follow in the future firmware releases.

Service Root : https://<ip:port>/redfish/v1
Session Service : https://<ip:port>/redfish/v1/SessionService
Session Collection: https://<ip:port>/redfish/v1/SessionService/Sessions
Session Resource: https://<ip:port>/redfish/v1/SessionService/Sessions/<id>

System Collection: https://<ip:port>/redfish/v1/Systems
System Resource : https://<ip:port>/redfish/v1/Systems/<server-id>
EnergyScale : https://<ip:port>/redfish/v1/Systems/<server-id>/EnergyScale
Processor Collection: https://<ip:port>/redfish/v1/Systems/<server-id>/Processors
Processor Resource: https://<ip:port>/redfish/v1/Systems/<server-id>/Processors/<proc-id>
Core Resource: https://<ip:port>/redfish/v1/Systems/<server-id>/Processors/<proc-id>/Cores/<core-id>

Chassis Collection: https://<ip:port>/redfish/v1/Chassis
Chassis Resource: https://<ip:port>/redfish/v1/Chassis/<chassis-id>

Power Resource: https://<ip:port>/redfish/v1/Chassis/<chassis-id>/Power
Thermal Resource: https://<ip:port>/redfish/v1/Chassis/<chassis-id>/Thermal

Manager Collection: https://<ip:port>/redfish/v1/Managers
FSP Resource: https://<ip:port>/redfish/v1/Managers/BMC
FSP eth0 Interface: https://<ip:port>/redfish/v1/Managers/BMC/EthernetInterfaces/ETH_0

Automating Common tasks using cURL command

The following examples illustrate the cURL commands that can be used to access the common functions that are supported by the FSP.

1) To log in and create a secure connection with the Redfish service, run the following command:
curl -k -X POST -D headers.txt https:// <ip:port> /redfish/v1/SessionService/Sessions -d '{"UserName":"admin", "Password":"admin"}'
where ip is the IP address of the FSP and port is the default port of the ASMI.

The response headers will be dumped into the file headers.txt.  After the user logs in, value of the X-Auth-Token header from headers.txt must be saved for all further requests for authentication, and the value Location header must  be saved because it is the unique URI for the session. Location header is required to logoff from the session.

2) To read the Service Root document, run the following command:
curl -k -H "X-Auth-Token: <authtoken>" -X GET https://<ip:port>/redfish/v1/

3) To read the collection of System ID at this instance, run the following command:
curl -k -H "X-Auth-Token: <authtoken>" -X GET https://<ip:port>/redfish/v1/Systems
The server will return the Systems collection in the json body of the response. Following is an example response from the server:
    "@odata.context": "/redfish/v1/$metadata#ComputerSystemCollection.ComputerSystemCollection",
    "@odata.id": "/redfish/v1/Systems",
    "@odata.type": "#ComputerSystemCollection.ComputerSystemCollection",
    "Members": [
            "@odata.id": "/redfish/v1/Systems/Server-8286-42A-217FD6V"
    "Members@odata.count": 1,
    "Name": "System Collection"

4) To read the System information, run the following command:
curl -k -H "X-Auth-Token: <authtoken>" -X GET https://<ip:port>/redfish/v1/Systems/<system-id>
where system-id is the machine type and model (MTM) of the system and the serial number obtained from the response to the Systems collection (step 3 above).

The  format for system-id is Server-<MTM>-<SerialNumber>. Following is an example response from the server:
    "@odata.context": "/redfish/v1/$metadata#ComputerSystem.ComputerSystem",
    "@odata.id": "/redfish/v1/Systems/Server-8286-42A-217FD6V",
    "@odata.type": "#ComputerSystem.v1_0_2.ComputerSystem",
    "Actions": {
        "#ComputerSystem.Reset": {
            "ResetType@Redfish.AllowableValues": [
            "target": "/redfish/v1/Systems/Server-8286-42A-217FD6V/Actions/ComputerSystem.Reset"
    "Description": "IBM POWER Server",
    "Id": "Server-8286-42A-217FD6V",
    "Links": {
        "ManagedBy": [
                "@odata.id": "/redfish/v1/Managers/7042CR8*21FDB1C"
                "@odata.id": "/redfish/v1/Managers/7042CR8*840832D"
                "@odata.id": "/redfish/v1/Managers/BMC"
    "Manufacturer": "IBM",
    "Model": "8286-42A",
    "Name": "Server-8286-42A-SN217FD6V",
    "Oem": {
        "IBMEnterpriseComputerSystem": {
            "@odata.context": "/redfish/v1/$metadata#IBMEnterpriseComputerSystem.IBMEnterpriseComputerSystem",
            "@odata.type": "#IBMEnterpriseComputerSystem.v1_0_0.IBMEnterpriseComputerSystem",
            "AutoPowerRestart": "Disabled",
            "IBMEnterpriseEnergyScale": {
                "@odata.id": "/redfish/v1/Systems/Server-8286-42A-217FD6V/EnergyScale"
            "PowerRestartControl": {
                "BootMode": "BootToOpenFirmwarePrompt",
                "BootSide": "Permanent",
                "FirmwareStartPolicy": "Running",
                "OperatingMode": "Normal",
                "PartitionMode": "B",
                "PowerOffPolicy": "StayOn"
            "PredictiveDynamicMemoryDeallocation": "Enabled"
    "Processors": {
        "@odata.id": "/redfish/v1/Systems/Server-8286-42A-217FD6V/Processors"
    "SerialNumber": "217FD6V",
    "Status": {
        "Health": "OK",
        "HealthRollUp": "OK",
        "State": "Enabled"
    "UUID": "0004AC1AD660"

5) To read the Chassis collection resource, run the following command:
curl -k -H "X-Auth-Token: <authtoken>" -X GET https://<ip:port>/redfish/v1/Chassis

Following is an example response from the server:
    "@odata.context": "/redfish/v1/$metadata#ChassisCollection.ChassisCollection",
    "@odata.id": "/redfish/v1/Chassis",
    "@odata.type": "#ChassisCollection.ChassisCollection",
    "Members": [
            "@odata.id": "/redfish/v1/Chassis/YL10UF4B7018"
    "Members@odata.count": 1,
    "Name": "Chassis Collection"

6) To read the Chassis resource, run the following command:
curl -k -H "X-Auth-Token: <authtoken>" -X GET https://<ip:port>/redfish/v1/Chassis/<chassis-id>
where chassis-id is the serial number of the CEC enclosure obtained from the response to the Chassis collection resource (step 5 above).

Following is an example response from the server:
    "@odata.context": "/redfish/v1/$metadata#Chassis.Chassis",
    "@odata.id": "/redfish/v1/Chassis/YL10UF4B7018",
    "@odata.type": "#Chassis.v1_1_2.Chassis",
    "Description": "IBM POWER Server Chassis",
    "Id": "YL10UF4B7018",
    "Links": {
        "ManagedBy": [
                "@odata.id": "/redfish/v1/Managers/BMC"
    "Manufacturer": "IBM",
    "Name": "System Chassis",
    "Oem": {
        "IBMEnterpriseChassis": {
            "@odata.type": "#IBMEnterpriseChassis.v1_0_0.IBMEnterpriseChassis",
            "CCIN": "2CD4",
            "HugeDynamicDMAWindowSlotCount": 4,
            "LocationCode": "U78C9.001.WZS047T"
    "PartNumber": "74Y4568",
    "PowerState": "On",
    "SKU": "74Y4680",
    "SerialNumber": "YL10UF4B7018"

7) To modify the number of slots that are enabled for Enlarged  Capacity  I/O  in the node or chassis, run the following command:
curl -k -H "X-Auth-Token: <authtoken>" -X PATCH https://<ip:port>/redfish/v1/Chassis/<chassis-id>; -d {"Oem" : {"IBMEnterpriseChassis" : {"HugeDynamicDMAWindowSlotCount" : "9"}}}

8) To modify the power saver parameters for CPU that is in idle state, run the following command:
curl -k -H "X-Auth-Token: <authtoken>" -X PATCH https://<ip>/redfish/v1/Systems/ <system-id> /EnergyScale -d { "CPUIdlePowerSaver": { "DelayTimeEnter": 150, "DelayTimeExit": 5, "State": "Enabled", "UtilizationThresholdEnter": 22, "UtilizationThresholdExit": 30 }}

9) To power on the system, run the following command:
curl -k -H "X-Auth-Token: <authtoken>" -X POST https://<ip:port>/redfish/v1/Systems/<system-id>/Actions/Reset -d {"ResetType":"On"}

10) To power off the system, run the following command:
curl -k -H "X-Auth-Token: <authtoken>" -X POST https://<ip:port>/redfish/v1/Systems/ <system -id> /Actions/Reset -d {"ResetType":"ForceOff"}

11) To log off or terminate the Redfish session, run the following command:
curl -k -H "X-Auth-Token: <authtoken>" -X DELETE https://<ip:port>/redfish/v1/SessionService/Sessions/<id>
where the URI of the session resource is the Location header returned by the Redfish server for the Session creation request (step 1 above).


Documents: http://www.dmtf.org/standards/redfish (spec, mockup, whitepapers)
Schemas: http://redfish.dmtf.org/schemas/v1
Resource Explorer:  http://redfish.dmtf.org/redfish/v1
Feedback: http://www.dmtf.org/standards/feedback
Webinars: http://www.dmtf.org/education/webinars
The SPM Forum: http://www.dmtf.org/standards/spmf
DMTF Alliance Partners: http://www.dmtf.org/about/registers
Redfish Specification Forum: http://redfishforum.com/
DMTF github: https://github.com/DMTF
DMTF redfishtool: https://github.com/DMTF/Redfishtool
python-redfish project: https://github.com/uggla/python-redfish

Contacting the PowerVM Team

Have questions for the PowerVM team or want to learn more?  Follow our discussion group on LinkedIn IBM PowerVM or IBM Community Discussions