HP Proliant DL360 Gen10 Storage information not returned
brad-marshall opened this issue · 12 comments
I'm testing a redfish exporter (https://github.com/jenningsloy318/redfish_exporter) against some Dell and HP kit, which is mostly working.
However, the problem is with the HP DL360 Gen10 server I'm testing against. It gets data seemingly correct, but storage seems to be in a different location than expected. To get information from a disk, I have to hit:
/redfish/v1/Systems/1/SmartStorage/ArrayControllers/0/DiskDrives/0
whereas the Dells seem to be under:
/redfish/v1/Systems/System.Embedded.1/SimpleStorage/Controllers/RAID.Integrated.1-1
I can follow the tree all the way down to it, I'm not sure why its not being picked up by the library functions.
I'm running a fairly recent version of the firmware for the ILO, from early 2022, the changelogs from the ones after it have nothing to do with Redfish and storage, and I doubt they'd make a major change in minor releases.
What further information can I provide about this issue?
Hi!
/redfish/v1/Systems/1/SmartStorage is not a part of Redfish specification; as far as I understand it's HP's "OEM" data model.
Can you post the output of /redfish/v1/Systems/1/Storage on HP?
Sure - its pretty much empty:
$ curl --header "X-Auth-Token: $token" -X GET -k https://redacted/redfish/v1/Systems/1/Storage | jq -r
{
"@odata.context": "/redfish/v1/$metadata#StorageCollection.StorageCollection",
"@odata.etag": "W/"blah"",
"@odata.id": "/redfish/v1/Systems/1/Storage",
"@odata.type": "#StorageCollection.StorageCollection",
"Description": "Storage subsystems known to this system",
"Name": "Storage",
"Members": [],
"Members@odata.count": 0
}
I can confirm that SmartStorage is part of HP's OEM data model, its under OEM:
$ curl -s --header "X-Auth-Token: $token" -X GET -k https://redacted/redfish/v1/Systems/1 | jq -r '.Oem.Hpe.Links'
{
"SUT": {
"@odata.id": "/redfish/v1/systems/1/hpsut"
},
"PCIDevices": {
"@odata.id": "/redfish/v1/Systems/1/PCIDevices"
},
"PCISlots": {
"@odata.id": "/redfish/v1/Systems/1/PCISlots"
},
"NetworkAdapters": {
"@odata.id": "/redfish/v1/Systems/1/BaseNetworkAdapters"
},
"SmartStorage": {
"@odata.id": "/redfish/v1/Systems/1/SmartStorage"
},
"USBPorts": {
"@odata.id": "/redfish/v1/Systems/1/USBPorts"
},
"USBDevices": {
"@odata.id": "/redfish/v1/Systems/1/USBDevices"
},
"EthernetInterfaces": {
"@odata.id": "/redfish/v1/Systems/1/EthernetInterfaces"
},
"WorkloadPerformanceAdvisor": {
"@odata.id": "/redfish/v1/Systems/1/WorkloadPerformanceAdvisor"
},
"SecureEraseReportService": {
"@odata.id": "/redfish/v1/Systems/1/SecureEraseReportService"
}
}
Thanks @brad-marshall. If they are not publishing any of the storage information via the standard location then there would need to be OEM handling added for that. Either here: https://github.com/stmcginnis/gofish/tree/main/oem/hpe or in the client application that is trying to consume that information.
Not sure if @jenningsloy318 would be open to adding conditional vendor handling to redfish_exporter or not.
Ideally, HPE should be publishing standard storage information using the redfish standard objects, with possibly extended information available via the OEM mechanism.
Right, I was just searching around after the mention of it being in OEM, and found a reference to the pull request that merged it, that looks like exactly what we need.
I suspect getting HP to change their Redfish implementation is beyond almost anyone, so either adding the OEM support into this library or conditional handling in redfish_exporter are the real options here. The OEM addition to this library is probably the easiest path - other than me not being a go coder. I'll have a look at it and a chat to some people internally at work and see what we can come up with.
Of course if someone else who knows how this works did it, I wouldn't be unhappy :)
or conditional handling in redfish_exporter
The trick here is it's "and" not "or". If OEM support was added here to gofish, redfish_exporter would need to use that to get the OEM data for the system.
If you have a support contract with HPE, it might be worth submitting a ticket letting them know you would like them to support the standard interface. I think they have been responsive in the past, though it's been quite awhile. :)
If you have a support contract with HPE, it might be worth submitting a ticket letting them know you would like them to support the standard interface. I think they have been responsive in the past, though it's been quite awhile. :)
Aha. We do have support contract with HPE I believe, I'm not directly been involved in that. I'll chase it up and see what we can do.
Is there any docs on how to add extra OEM data to gofish? I'm looking over the HPE thermal code, and it seems to rely on there being thermal in the base gofish? Or have I read this wrong?
Of course if someone else who knows how this works did it, I wouldn't be unhappy :)
I've actually considered using jenningsloy318's redfish_exporter, but I was not particually happy with its design and performance and decided to write my own exporter - it's not that difficult one you get the concepts (node_exporter and fortigate_exporter are great starting points).
I'll have a look at it and a chat to some people internally at work and see what we can come up with.
I second @stmcginnis , you'd need both a library-side OEM support and an exporter that uses that (or a modular exporter that would allow you to add your own collectors). I wasn't able to find anything on Github that would work for you, sorry.
HPE added DMTF Storage support to HPE ProLiant Gen10 and beyond hosted by iLO5 and iLO6. The storage controllers now support the DMTF/PMCI/PLDM for Redfish Device Enablement/ which allows the Smart Array, SR, MR, and NS controllers to host their own Redfish branch under the StorageCollection. OEM resources such as SmartStorage was deprecated and not available thru iLO6. For more details, check out www.hpe.com/info/scmo. Check out the storage controller firmware release notes for any new features that were released ahead of the white paper.
{
"@odata.context": "/redfish/v1/$metadata#StorageCollection.StorageCollection",
"@odata.etag": "W/"1E796226"",
"@odata.id": "/redfish/v1/Systems/1/Storage",
"@odata.type": "#StorageCollection.StorageCollection",
"Description": "Storage subsystems known to this system",
"Name": "Storage",
"Members": [
{
"@odata.id": "/redfish/v1/Systems/1/Storage/DA000000"
},
{
"@odata.id": "/redfish/v1/Systems/1/Storage/DA000001"
},
{
"@odata.id": "/redfish/v1/Systems/1/Storage/DA000002"
},
{
"@odata.id": "/redfish/v1/Systems/1/Storage/DA000003"
},
{
"@odata.id": "/redfish/v1/Systems/1/Storage/DE009000"
},
{
"@odata.id": "/redfish/v1/Systems/1/Storage/DE00B000"
},
{
"@odata.id": "/redfish/v1/Systems/1/Storage/DA00000B"
},
{
"@odata.id": "/redfish/v1/Systems/1/Storage/DE080000"
},
{
"@odata.id": "/redfish/v1/Systems/1/Storage/DE00A000"
}
],
"Members@odata.count": 9
}
Looks like the HPE update resolves the initial concern of this issue, so closing. Though anyone feel free to expand on the oem/hpe code to support more OEM-specific things - though noted with the caveat above that there would also need to be updates on the gofish consumer side to handle this oem approach as well, so sticking to non-OEM Redfish standard things is generally preferred.