SUSE Trento Agent: relaying on dmidecode when Guest OS is a ppc64le SLES 15 SP5 on IBM Power's LPAR

SUSE Linux Enterprise Server
1

On a SLES 15 SP5 (for SAP Application) deployed on a x86_64 physical or virtualized system the SUSE Trento Agent relies on the dmidecode to read low level system information and gather system information, vice-versa, as far as I know, on a IBM Power server the DMI table concept doesn’t exist so the dmidecode not only will not be useful at all but also is not available (on the other hand a device tree structure exists - see /proc/device-tree/ as example - and also the lshw command can be used to collect low level system information).

How SUSE Trento Agent deals with the above difference when it is deployed on a SLES 15 SP5 (for SAP Applications) running over a IBM Power’s LPAR instead of running over a more common physical/virtualized x86_64 operating system for which dmidecode is available?

We see (one of) our SUSE Trento Agent, registered on our SUSE Trento Server, logging errors related to the fact that the dmidecode package is not available (that particular SLES 15 SP5 for SAP Application running a SAP HANA database is installed over an IBM Power 9’s LPAR), example (errors grep from journalctl of trento-agent unit):

...
Oct 21 13:03:30 <hostname-redacted> trento-agent[1518607]: time="2024-10-21 13:03:30" level=error msg="Unable to convert CPU socket count: strconv.Atoi: parsing \"\": invalid syntax"
Oct 21 13:03:36 <hostname-redacted> trento-agent[1518607]: time="2024-10-21 13:03:36" level=warning msg="Error running python_support command: exit status 10"
Oct 21 13:03:36 <hostname-redacted> trento-agent[1518607]: time="2024-10-21 13:03:36" level=warning msg="Error running python_support command: exit status 4"
Oct 21 13:03:40 <hostname-redacted> trento-agent[1518607]: time="2024-10-21 13:03:40" level=error msg="Error while running discovery 'cloud_discovery': exec: \"dmidecode\": executable file not found in $PATH"
Oct 21 13:03:40 <hostname-redacted> trento-agent[1518607]: time="2024-10-21 13:03:40" level=info msg="cloud_discovery discovery tick output: Error while running discovery 'cloud_discovery': exec: \"dmidecode\": executable file not found in $PATH"
...

Any idea how to overcome the above limitation?

Cheers!

2

Hey there, thanks for reporting this.
Please, consider using Issues or Discussions in the project GitHub next time, so that we can promptly react. We didn’t expect Trento issue reports in Rancher forums, to be honest. :slight_smile:

Anyway, we’ll look into how the Trento Agent should better interact with an IBM Power host to correctly discover it. I must admit we never actually tested this scenario, since we never had any early adopter reporting the intent to use the application on IBM Power.

1 Like
3

Ciao/Hi Stefano! OK noted for the suggestion about reporting on GitHub. Well, in the end the agent is working (as far as I can report) even if not all HW related information can be gathered as expected by the code. Cheers, Davide.

P.S. In our environment we use mostly IBM Power 9 and Power 10 servers to run our SAP (P/A) Application Servers (on AIX 7.2/7.3) and SAP HANA DB Servers (on SLES 15 SP5) so, well, maybe we can be considered a sort of “corner case” for who is used to think that that workloads would normally run on Intel (Big Endian) based servers.