Hardware profile format

The following table lists the JSON keys required to create a custom hardware profile:

Key	Mandatory (Yes/No)
`profile_name`	Yes
`bios_mode`	Yes
`restore_default_bios`	No
`bios_settings`	Yes
`nic_settings`	No
`networkboot_settings`	No
`boot_order`	No
`raid_details`	Yes

The description and syntax along with values for each key is listed as follows:

profile_name

This is a mandatory parameter. This parameter indicates the name of the hardware profile. When customizing the hardware profile, you must enter this value in the hw_profile parameter in the Infra/server section of the Input JSON file. This must be different from the already existing profile names.

For example,

"profile_name":"custom_controller_profile"

bios_mode

This is a mandatory parameter. This parameter is a BIOS mode in which server needs to boot. Provide Redfish value.

The allowed values are as follows:

Supported values are "Uefi" and "LegacyBios" for DL and EL8000 servers.
Supported value is "Uefi" for EL4000 servers.

For example,

"bios_mode":"Uefi"

restore_default_bios

This is an optional parameter. This parameter restores the default BIOS settings.

The allowed values are as follows:

Supported values are "Yes" and "No".
Default value is "No".
Provide "Yes" to restore default BIOS in the server before applying the BIOS settings provided in the hardware profile.

For example,

"restore_default_bios": "Yes"

NOTE:

This is an optional field. Remove the entry from the custom hardware profile or provide "No" to "restore_default_bios" (that is, "restore_default_bios": "No") to avoid restoring default BIOS settings.

bios_settings

This is a mandatory parameter.

The following syntax provides the details to apply BIOS settings on the server:

"bios_settings":[
{
"parameter_key": <Redfish equivalent parameter key>,
"parameter_value": <Redfish equivalent parameter value>,
"description": <description of BIOS settings>
},
{
"parameter_key": <Redfish equivalent parameter key>,
"parameter_value": <Redfish equivalent parameter value>,
"description": <description of BIOS settings >
}
]

where,

parameter_key: Provides Redfish equivalent parameter key for the corresponding BIOS settings.
parameter_value: Provides Redfish equivalent parameter value for the corresponding BIOS settings.
description: Provides description for the corresponding BIOS settings.

Allowed Redfish key and values

To get the BIOS parameters Redfish equivalent keys and their equivalent values, run the following command:

nps get-biosparams -sl <iLO IP> --username <iLO username> --password <iLO password>

where,

-sl: Server iLO IP
--username: Username of the iLO server
--password: Password of the iLO server

The output displays all the BIOS parameters (what we see in iLO) available in the registries with Redfish equivalent Key and Redfish equivalent allowed values for each parameter. The output is based on the BIOS version (System ROM) in the iLO server. So, the output is the same for all servers that has the same System ROM.

NOTE:

Apart from the BIOS settings shown in the above CLI, there may be service BIOS settings based on the server model. To get the service BIOS settings and all the Redfish keys, run the following command:

nps get-servicebios -sl <iLO IP> --username <iLO username> --password <iLO password>

where,

-sl: Server iLO IP
--username: Username of the iLO server
--password: Password of the iLO server

The output displays all the service key parameters and the values that are currently set in the server. To know all the allowed values for any key, contact the HPE Services team.

For example,

"bios_settings":[
{
"parameter_key": "SubNumaClustering",
"parameter_value": "Disabled",
"description": "Sub-NUMA Clustering"
},
{
"parameter_key": "ProcTurbo",
"parameter_value": "Disabled",
"description": "Intel Turbo Boost Technology"
}
]

NOTE:

On specific "WorkloadProfile", some BIOS settings are not allowed to change. In such case, to change/apply those settings, change "WorkloadProfile" to "Custom". "Custom" is the workload profile option provided by iLO to customize the specific "WorkloadProfile".
For example,
```
"bios_settings":[
{
"parameter_key": "ProcTurbo",
"parameter_value": "Disabled",
"description": "Intel Turbo Boost Technology"
},
{
"parameter_key": "WorkloadProfile",
"parameter_value": "Virtualization-MaxPerformance",
"description": "Workload Profile"
}
]
```
In the above example, "ProcTurbo" cannot be set to "Disabled" with "WorkloadProfile" as "Virtualization-MaxPerformance". For "Virtualization-MaxPerformance", "ProcTurbo" is always "Enabled" and not allowed to change. In this case, after applying the "Virtualization-MaxPerformance" workload profile, it will be changed to "Custom" (this allows users to edit all the parameters) and then "ProcTurbo" will be "Disabled". So after applying BIOS settings through hardware preparation, the server will have "WorkloadProfile": "Custom" (that is, customized "Virtualization-MaxPerformance" workload profile with "ProcTurbo": "Disabled").
This is a mandatory parameter so provide an empty list if there is no BIOS setting to be set. For example, "bios_settings":[].

nic_settings

This is an optional parameter.

The following syntax provides the details to apply NIC settings (enabling/disabling the NICs) on the server:

"nic_settings":[
{
"parameter_key": <Redfish equivalent parameter key>,
"parameter_value": <Redfish equivalent parameter value>,
"description": <description of NIC settings >
},
{
"parameter_key": <Redfish equivalent parameter key>,
"parameter_value": <Redfish equivalent parameter value>,
"description": <description of NIC settings >
}
]

where,

parameter_key: Provides Redfish equivalent parameter key for the corresponding NIC settings.
For example,
- "FlexLom1Enable" is the parameter key for FLR NIC.
- "EmbNicEnable" is the parameter key for embedded 1G NIC.
- "PciSlot#Enable" is the parameter key for PCIe NIC, where # is a integer (Slot number), in which PCIe NIC is connected.
parameter_value: Provides Redfish equivalent parameter value for the corresponding NIC settings.
Supported values are:
- "Auto" for enabling NIC in iLO5 servers.
- "Enabled" for enabling NIC in iLO4 servers.
- "Disabled" for disabling NIC in iLO4 or iLO5 servers.
description: Provides description for the corresponding NIC settings.

For more information about the allowed keys and values of NIC settings, see Allowed Redfish key and values of NIC settings based on server model.

For example,

"nic_settings":[
{
"parameter_key": "EmbNicEnable",
"parameter_value": "Disabled",
"description": "Embedded 1G NIC"
},
{
"parameter_key": "FlexLom1Enable",
"parameter_value": "Auto",
"description": "FLR NIC"
},
{
"parameter_key": "PciSlot1Enable",
"parameter_value": "Auto",
"description": "PCIe slot's"
}
]

NOTE:

"*" is allowed for PCI slots in case all PCI NICs need to be configured as same.
For example,
```
"nic_settings":[
{
"parameter_key": "PciSlot*Enable",
"parameter_value": "Auto",
"description": "PCIe slot's"
}
]
```
In the above example, all PCI NICs are enabled irrespective of slot numbers.
This is an optional field. Remove the entry from the custom hardware profile or provide an empty list (that is, "nic_settings":[]) to skip the NIC setting in the server during hardware preparation action "nic".

networkboot_settings

This is an optional parameter.

The following syntax provides the details to enable/disable the networkboot in the port of data/management NIC in the server:

"networkboot_settings":{
"<location> <instance>:Port <port number>": "NetworkBoot/Disabled",
"<location> <instance>:Port <port number>": "NetworkBoot/Disabled"
}

Where,

Location and instance section together describes the location of the device.
Port and port number together describes the port number of the NIC card where "Port" is a constant variable.
Allowed values are "NetworkBoot" and "Disabled".

The allowed strings for location are as follows:

FlexLOM for FLR NIC
LOM for embedded 1G NIC
Slot for PCI slots

For more information about the allowed location, instance and port number based on server model, see Allowed Location, Instance, port number and values for network boot settings based on server model.

For example,

"networkboot_settings":{
"FlexLOM 1:Port 1": "NetworkBoot",
"FlexLOM 1:Port 2": "Disabled",
"LOM 1:Port 1": "Disabled",
"LOM 1:Port 2": "Disabled",
"LOM 1:Port 3": "Disabled",
"LOM 1:Port 4": "Disabled",
"Slot 1:Port 1": "NetworkBoot",
"Slot 1:Port 2": "Disabled"
}

NOTE:

This is an optional field. Remove the entry from the custom hardware profile or provide an empty dict (that is, "networkboot_settings":{}) to skip the networkboot settings in the server during hardware preparation action "nic".

boot_order

This is a mandatory parameter.

The following syntax provides the details to set boot order in the server:

"boot_order":[“boot_order1”,”boot_order2”,”boot_order3”,etc.,]

When bios_mode is LegacyBIOS

iLO REST APIs are used to set boot order in LegacyBIOS.

The supported values are Cd, Disk, Floppy, UsbKey, Network<integer>.

For example,

"boot_order":[“Cd”,”Disk”,”UsbKey”,”Network1”]

When bios_mode is Uefi

Provide value in the following format (structured boot string): <Devicetype>.<Location>.<Instance>.<Sub-Instance>.<Qualifier>

DeviceType: The first section describes the device type (for example, “HD”, “CD”, “NIC”, “PCI”, and so on). See Allowed values of DeviceType in the structured boot string.
Location: The second and the third section together describes the location of the device (for example, “Slot.7” or “Emb.4”). See Allowed values of Location in the structured boot string.
Instance: The third section is used with the Location to describe the device location (for example, the Slot # or Embedded instance number).
Sub-instance: The fourth section is optional, and is used as a sub-instance number in case of multiple boot options using the same instance. For instance, this can be the port number for NIC card (in case of a multi-port NIC).
Qualifier: The fifth section is optional, and describes the logical protocol (for example, IPv4, IPv6, iSCSIIpv4, and so on). See Allowed values of Qualifier in the structured boot string.

See Examples of structured boot strings to see examples for boot_order (structured boot string) in Uefi bios_mode and also to get all the allowed values of DeviceType, Location, Instance, Sub-Instance and Qualifier.
For example,
```
"boot_order":[HD.EmbRAID.1.2","HD.EmbRAID.1.3",
"Generic.USB.1.1","HD.RearUSB.1.1","NIC.FlexLOM.1.1.IPv4"]
```
NOTE:
- Instance and Sub-instance supports "*" in case the exact number mapping the location is non predictable, in that case it will take all the values matching other parameter irrespective of instance and sub-instance. For example,
```
"boot_order":["HD.EmbRAID.*.*","NIC.FlexLOM.1.1.IPv4"]
```
  In the above example, it will take all the value matching "HD.EmbRAID" (for example, HD.EmbRaid.1.2, HD.EmbRaid.1.4, HD.EmbRaid.1.3) and it will be placed in the first three places of the server boot order and fourth will be "NIC.FlexLOM.1.1.IPv4".
- This is an optional field. Remove the entry from the custom hardware profile or provide an empty list (that is, "boot_order":[]) to skip setting the server boot order during hardware preparation action "nic".

raid_details

This is a mandatory parameter.

The following syntax provides the details to create a logical drive in the server:

"raid_details":[
  {
    "LogicalDriveName": "<logical drive name>",
    "Raid": "<type of RAID>",
    "DataDrives": {
       "DataDriveCount": <physical drive count>,
       "DataDriveMediaType": "<Media type>",
       "DataDriveInterfaceType": "<inteface type>",
       "DataDriveMinimumSizeGiB": <minimum required size of the physical drives>
    }
  },
  {
    "LogicalDriveName": "<logical drive name>",
    "Raid": "<type of RAID>",
    "DataDrives": {
       "DataDriveCount": <physical drive count>,
       "DataDriveMediaType": "<Media type>",
       "DataDriveInterfaceType": "<inteface type>",
       "DataDriveMinimumSizeGiB": <minimum required size of the physical drives>
    }
  }
]

The allowed values are as follows:

"Raid" (type of RAID): "Raid1", "Raid10", "Raid0", and "Raid5".
"DataDriveMediaType" (media type): HDD and SSD.
"DataDriveInterfaceType" (interface type): SAS.

For example,

"raid_details":[
  {
    "LogicalDriveName": "LD1",
    "Raid": "RAID0",
    "DataDrives": {
       "DataDriveCount": 1,
       "DataDriveMediaType": “HDD",
       "DataDriveInterfaceType": "SAS",
       "DataDriveMinimumSizeGiB": 0
    }
  },
  {
    "LogicalDriveName": "LD2",
    "Raid": "RAID1",
    "DataDrives": {
       "DataDriveCount": 2,
       "DataDriveMediaType": "SSD",
       "DataDriveInterfaceType": "SAS",
       "DataDriveMinimumSizeGiB": 0
    }
  }
]

NOTE:

A list of logical drives is created in the same sequence as defined in the JSON file.
Multiple RAID entries (dictionaries) are allowed to create multiple logical drives.
This is a mandatory parameter. Provide an empty list, if RAID is not supported or to skip the logical drive creation, that is, "raid_details":[].