Hardware pre-check profile format
The following table lists the JSON keys required to create a custom hardware pre-check profile:
Key | Mandatory (Yes/No) |
---|---|
profile_name |
Yes |
cpu |
No |
memory |
No |
storage |
No |
nic |
No |
At least one resource section (cpu
/memory
/storage
/nic
) must be provided. Each resource section must have
"optimum"
and
"minimum"
keys.
"minimum"
is mandatory and
"optimum"
is optional.
The description and syntax along with values for each key (resource section) is listed as follows:
profile_name
This parameter indicates the name of the hardware pre-check profile. This must be different from the already existing profile names.
"profile_name":"custom_controller_precheck_profile"
cpu
"cpu"
resource section in the hardware pre-check profile:
Resource section key | Allowed keys | Section mandatory (Yes/No) | Sub section keys | Sub section mandatory (Yes/No)
Note: If the section is available |
---|---|---|---|---|
cpu |
optimum | No | total_cores | Yes |
"cpu": {
"optimum": {
"total_cores": <optimal number of CPU cores>
},
"minimum": {
"total_cores": <minimal number of CPU cores>
}
}
where,
"total_cores"
is the total number of CPU cores. This is an integer value.
"cpu": {
"optimum": {
"total_cores": 20
},
"minimum": {
"total_cores": 10
}
}
"minimum"
parameter details are mandatory and
"optimum"
is an optional. Hence, the profile can be created by providing only the
"minimum"
details as shown in the following example:
"cpu": {
"minimum": {
"total_cores": 10
}
}
memory
"memory"
resource section in the hardware pre-check profile:
Resource section key | Allowed keys | Section mandatory (Yes/No) | Sub section keys | Sub section mandatory (Yes/No)
Note: If the section is available |
---|---|---|---|---|
memory |
optimum |
No | DIMM_count |
No |
each_DIMM_GB |
No | |||
total_memory_GB |
Yes | |||
rank_count |
No | |||
minimum |
Yes | DIMM_count |
No | |
each_DIMM_GB |
No | |||
total_memory_GB |
Yes | |||
rank_count |
No |
"memory": {
"optimum": {
"DIMM_count": <optimal number of DIMM count>,
"each_DIMM_GB": <optimal size of DIMM in GB>,
"total_memory_GB": <optimal total memory in GB>,
"rank_count": <optimal rank count>
},
"minimum": {
"DIMM_count": <minimal number of DIMM count>,
"each_DIMM_GB": <minimal size of DIMM in GB>,
"total_memory_GB": <minimal total memory in GB>,
"rank_count": <minimal rank count>
}
}
where,
DIMM_count
: Number of DIMM count is expected in the server. This is an integer value.each_DIMM_GB
: Size/capacity of DIMM expected in the server. Provide value in GB. This is an integer value.total_memory_GB
: Total memory expected in the server. Provide value in GB. This is an integer value.rank_count
: Rank count expected in the server. Either single rank or dual rank. This is an integer value.
"memory":{
"optimum":{
"DIMM_count": 16,
"each_DIMM_GB": 32,
"total_memory_GB": 512,
"rank_count": 2
},
"minimum":{
"total_memory_GB": 6
}
}
In the above syntax, the "minimum" parameter details are mandatory and "optimum" is an optional. Hence, the profile can be created by providing only "minimum" details as follows:
"memory":{
"minimum":{
"total_memory_GB": 6
}
}
storage
Resource key | Allowed keys (section) | Mandatory (Yes/No) | Sub section (A) Keys | Sub section (A) mandatory (Yes/No)
Note: If the section is available |
Sub section (B) Keys | Sub section (B) mandatory (Yes/No)
Note: If the section is available |
---|---|---|---|---|---|---|
storage |
optimum |
No | datadrive_count |
Yes | ||
datadrive_details |
Yes | media_type |
No | |||
interface_type |
No | |||||
capacity_GB |
Yes | |||||
rotational_speed |
No | |||||
interface_speed |
No | |||||
minimum |
Yes | datadrive_count |
Yes | |||
datadrive_details |
Yes | media_type |
No | |||
interface_type |
No | |||||
capacity_GB |
Yes | |||||
rotational_speed |
No | |||||
interface_speed |
No |
"storage": {
"optimum": [
{
"datadrive_count": <optimal number of storage disk>,
"datadrive_details": {
"media_type": "<Media type>",
"interface_type": "<Interface type>",
"capacity_GB": <capacity/size of the storage disk>,
"rotational_speed": <Rotational speed in rpm>,
"interface_speed": <Interface speed in mbps>
}
}
],
"minimum": [
{
"datadrive_count": <minimal number of storage disk>,
"datadrive_details": {
"media_type": "<Media type>",
"interface_type": "<Interface type>",
"capacity_GB": <capacity/size of the storage disk>,
"rotational_speed": <Rotational speed in rpm>,
"interface_speed": <Interface speed in mbps>
}
}
]
}
where,
datadrive_count
: Number of disk expected in the server. This is an integer value.datadrive_details
: This will have sub section with datadrive details like media type, interface type, disk capacity, rotational speed and interface speed.media_type
: Media type of the disk. Allowed media type is "HDD" and "SSD". This is a string value.interface_type
: Interface type of the disk. Allowed interface type is "SAS". This is a string value.capacity_GB
: Capacity or size of the disk. This is an integer value.rotational_speed
: Rotation speed of disk. Provide value in rpm. This parameter is not applicable for "SSD" media type. This is an integer value.interface_speed
: Interface speed. Provide value in mbps. This is an integer value.
Here, "optimum" or "minimum" section is a list of dictionary. If any value like (media_type, interface_type, capacity_GB, rotational_speed and interface_speed) varies in the "datadrive_details", it can be provided as a separate dictionary as shown in the example.
"storage":{
"optimum":[
{
"datadrive_count": 14,
"datadrive_details":{
"media_type":"HDD",
"interface_type":"SAS",
"capacity_GB": 2400,
"rotational_speed": 10000,
"interface_speed": 12000
}
},
{
"datadrive_count": 2,
"datadrive_details":{
"media_type":"SSD",
"interface_type":"SAS",
"capacity_GB": 400,
"interface_speed": 12000
}
}
],
"minimum":[
{
"datadrive_count": 1,
"datadrive_details":{
"capacity_GB": 40
}
}
]
}
In above syntax, "minimum" parameter details are mandatory and "optimum" is an optional. Hence profile can be created by providing only "minimum" details as follows.
"storage":{
"minimum":[
{
"datadrive_count": 1,
"datadrive_details":{
"capacity_GB": 40
}
}
]
}
nic
Resource key | Allowed keys (section) | Mandatory (Yes/No) | Sub section (A) Keys | Sub section (A) mandatory (Yes/No)
Note: If the section is available |
Sub section (B) Keys | Sub section (B) mandatory (Yes/No)
Note: If the section is available |
---|---|---|---|---|---|---|
nic |
optimum |
No | nic_details |
Yes | model |
Yes |
no_of_ports |
Yes | |||||
nic_location |
No | |||||
minimum |
Yes | nic_details |
Yes | model |
Yes | |
no_of_ports |
Yes | |||||
nic_location |
No |
"nic": {
"optimum": [
{
"nic_details": [
{
"model": "<Network adapter model>",
"no_of_ports": <Number of ports>
}
],
"nic_location": <Location of the NIC>
}
],
"minimum": [
{
"nic_details": [
{
"model": "<Network adapter model>",
"no_of_ports": <Number of ports>
}
],
"nic_location": <Location of the NIC>
}
]
}
}
where,
nic_details
: This will have sub section with model and no of ports.model
: Model of the NIC. This is string value.no_of_ports
: Number of ports in the NIC. This is an integer value.nic_location
: Location of the NIC. For example, in case of PCIe NIC, in which slot NIC has to be located. This is an integer value.
Here, "optimum" or "minimum" section is a list of dictionary. Each dictionary represents one NIC with different model or location. Also, "nic_details" is a list of dictionary, if user have different NIC model options to select in the server, it can be provided in list of dictionary with different model as shown in the example.
"nic": {
"optimum": [
{
"nic_details": [
{
"model": "534",
"no_of_ports": 2
}
]
},
{
"nic_details": [
{
"model": "661",
"no_of_ports": 2
},
{
"model": "640",
"no_of_ports": 2
}
],
"nic_location": 1
}
],
"minimum": [
{
"nic_details": [
{
"model": "534",
"no_of_ports": 2
}
]
}
]
}
In above syntax, "minimum" parameter details are mandatory and "optimum" is an optional. Hence profile can be created by providing only "minimum" details as follows.
"nic": {
"minimum": [
{
"nic_details": [
{
"model": "534",
"no_of_ports": 2
}
]
}
]
}