Tag: servers

Dell OpenManage Server Administrator (OMSA) is Dell’s on-host hardware management and monitoring framework for PowerEdge servers. 

It runs inside the operating system and provides direct visibility into system hardware such as RAID controllers, physical and virtual disks, power supplies, fans, temperatures, memory, processors, and chassis health. 

OMSA communicates with the server’s iDRAC and hardware controllers to retrieve real-time status and exposes this information through command-line tools like omreport, optional web interfaces, and SNMP for monitoring systems.

 It is primarily used for hardware diagnostics, RAID and storage monitoring, fault detection, and health reporting, allowing administrators to verify system integrity and troubleshoot hardware issues without leaving the operating system.

So now that we have an idea of what it is, lets install it.

Note: Our system under test is a Dell R720. I probably should have lead with that.

Installation

First you will need to download the bootstrap script as shown below.

curl -O https://linux.dell.com/repo/hardware/dsu/bootstrap.cgi

Now we will make it executable.

chmod +x bootstrap.cgi

And then we run it.

sudo ./bootstrap.cgi

Now we have completed the following.

• Added Dell’s official repo
• Installed Dell signing keys
• Configured OMSA package sources

Now Install OpenManage (omreport)

sudo dnf install srvadmin*

This installs:

• omreport
• omconfig
• Storage monitoring
• RAID tools
• CIM providers

Starting and Enabling Services

Apparently, service names can vary from OS to OS, so run the command below to verify the correct service names

systemctl list-unit-files | grep -Ei 'dsm|omsa|srvadmin'
dsm_om_connsvc.service                     enabled         disabled
dsm_om_shrsvc.service                      disabled        disabled
dsm_sa_datamgrd.service                    enabled         disabled
dsm_sa_eventmgrd.service                   enabled         disabled
dsm_sa_snmpd.service                       enabled         disabled

Now that we have the names of the services we can start and enable them as shown below

# sudo systemctl enable --now dsm_om_connsvc dsm_sa_datamgrd dsm_sa_eventmgrd dsm_sa_snmpd dsm_om_shrsvc

Service Review

Now let’s review each service in detail, and see how we can leverage each one.

dsm_om_connsvc

First we need to ensure our Firewall allows this traffic. So run the commands below (RHEL), ubuntu may use ufw.

# firewall-cmd --permanent --add-port=1311/tcp
# firewall-cmd --reload

Now in your web browser, navigate to https://viper.lab:1311/ (Note https, and change host name accordingly).

Similar in appearance to the Idrac – you can find system information here, some of which does not appear in the Idrac itself. Everything is read-only.

dsm_om_shrsvc

(OMSA Shared Services) is a supporting service, not a management interface or monitoring agent.

It provides:

• Shared libraries
• Inter-process communication
• Authentication helpers
• Common backend utilities

These are required by other OMSA components to function correctly. So nothing really to see here.

dsm_sa_datamgrd.service

This is the service that collects all the data that is displayed in the WebUI (port 1311)

dsm_sa_eventmgrd.service

dsm_sa_snmpd.service is the OMSA component responsible for exposing Dell hardware monitoring data to external systems using the SNMP protocol. 

This service does not collect or analyze hardware information itself; instead, it serves as the communication layer that allows remote systems to query or receive notifications about server health. When enabled, it allows OMSA to participate in centralized monitoring environments and enterprise alerting workflows, making it essential in environments where hardware status must be visible outside the server itself.

This service relies entirely on the existing system SNMP configuration, so no need to modify anything if you already have snmp configured and running with your specfic community string.

dsm_sa_snmpd.service

dsm_sa_snmpd.service is the OMSA component responsible for exposing Dell hardware monitoring data to external systems using the SNMP protocol. 

It acts as the interface between the data collected internally by OMSA and third-party monitoring platforms such as LibreNMS, Zabbix, or Nagios. 

This service does not collect or analyze hardware information itself; instead, it serves as the communication layer that allows remote systems to query or receive notifications about server health. When enabled, it allows OMSA to participate in centralized monitoring environments and enterprise alerting workflows, making it essential in environments where hardware status must be visible outside the server itself.

dsm_sa_snmpd.service acts as the Dell OMSA integration layer between the server’s hardware telemetry and the system’s SNMP stack, allowing Dell-specific health, storage, and sensor data to be exposed through standard SNMP queries. 

It does not replace or conflict with existing monitoring agents such as Zabbix or LibreNMS (which I am using) Instead, it complements them by extending the SNMP data they can read

dsm_sa_snmpd provides access to Dell-specific MIBs that Zabbix Agent and LibreNMS Agent (or any other agent you may use) can query via the system’s SNMP daemon. 

Basically, dsm_sa_snmpd is the bridge that exposes OMSA’s hardware awareness to your existing monitoring stack.
Note that if you are using Zabbix you will need to install additional templates. For example, this one, note that I have not tried it yet.

Ompreport

Omreport is the command-line interface (CLI) frontend for OMSA. It queries the OMSA backend services and formats the results for humans or scripts

Note we have to use the absolute path to run this as the working dir is not in our $PATH.

/opt/dell/srvadmin/sbin/omreport system summary

If you want to add to your $PATH, run the command below

echo 'export PATH=$PATH:/opt/dell/srvadmin/sbin' | sudo tee /etc/profile.d/dell-omsa.sh
source /etc/profile

Example usage below.

omreport system summary
omreport chassis temps
omreport chassis fans
omreport chassis power

Here is an example I found useful. For some reason my raid controller keeps throwing these errors which do not seem to go away despite the fact that both SAS cables are connected (tried switching them) and all disks are healthy.

# omreport system esmlog
Severity      : Critical
Date and Time : Sat Jan 31 21:15:18 2026
Description   : The storage BP1 SAS B cable is not connected, or is improperly connected.
Severity      : Ok
Date and Time : Sat Jan 31 21:15:20 2026
Description   : The chassis is closed while the power is off.
Severity      : Critical
Date and Time : Sat Jan 31 21:15:21 2026
Description   : The storage BP1 SAS A cable is not connected, or is improperly connected.

Enter omconfig.

omconfig

omconfig is the configuration and control interface for Dell OpenManage Server Administrator (OMSA). 

Unlike omreport, which is strictly read-only, omconfig is used to change system and OMSA behavior—including alerting, storage actions, and certain hardware-related settings exposed by OMSA. 

Omconfig It operates by issuing commands to the OMSA backend services (primarily dsm_sa_datamgrd and dsm_sa_eventmgrd) and applying those changes at the software management layer, not directly to hardware firmware. 

Common uses include enabling or disabling alert actions, configuring storage-related behavior, managing notification settings, and triggering maintenance operations such as consistency checks. 
Because omconfig can modify system behavior and suppress alerts, it should be used carefully—especially on production systems—and is best suited for controlled configuration changes rather than routine monitoring.

Because omconfig can modify system behavior and suppress alerts, it should be used carefully—especially on production systems—and is best suited for controlled configuration changes rather than routine monitoring.

So back to my two SAS cable alerts. Lets leverage omreport and omconfig to diagnose and hopefully ether determine that there is an actual issue, or suppress the alerts.

OMCONFIG and OMREPORT – Real world Usage

First lets take a sneaky-peak at my raid controller.

omreport storage controller
 Controller  PERC H730 Adapter(Slot 4)
Controller
ID                                            : 0
Status                                        : Ok
Name                                          : PERC H730 Adapter
Slot ID                                       : PCIe Slot 4
State                                         : Ready
Firmware Version                              : 25.5.9.0001
-----truncated---

According to chatgpt I am getting these errors because the system expects that I have an external enclosure connected. I do not think that is the case, as that seems dumb. More than likely this alert is due to the fact that I am using an H730 (a 13G controller) (and its cables) in an R720 (a 12G server) in Slot 4, which is a PCIe Adapter and not the integrated “mini” version.

So let’s look at the disks and make sure all is well

Here we can see that the PERC H730 adapter does not “See” the connector states as connected, rather just ready

omreport storage connector controller=0
List of Connector(s) on Controller PERC H730 Adapter (Slot 4)
ID             : 0
Status         : Ok
Name           : Connector 0
State          : Ready
Connector Type : SAS Port RAID Mode
Termination    : Not Applicable
SCSI Rate      : Not Applicable
ID             : 1
Status         : Ok
Name           : Connector 1
State          : Ready
Connector Type : SAS Port RAID Mode
Termination    : Not Applicable
SCSI Rate      : Not Applicable

In order to use this 13th gen raid controller in a 12th gen Dell Server I could not use the original SAS cables. Rather I used SFF-8087 to SFF-8643 cables Which can cause the sideband signals (SGPIO / SES) which tell the iDRAC everything is okay which is why we are seeing the errors.

As stated above this is not actually a problem as I can see my disks. Lets do that below.

omreport storage pdisk controller=0 | awk '
/^ID[[:space:]]*:/     {id=$3; state=""; status=""}
/^State[[:space:]]*:/  {state=$3}
/^Status[[:space:]]*:/ {status=$3}
(state!="" && status!="" && id!="") {print id, state, status; id=""; state=""; status=""}
'
0:0 Online Non-Critical
0:1 Online Non-Critical
0:2 Online Non-Critical
0:3 Online Non-Critical
0:4 Online Non-Critical
0:5 Online Non-Critical
0:6 Online Non-Critical
0:7 Online Non-Critical

Here we can see we have 8 disks, no critical errors

First lets clear the esmlog with omconfig – this will clear the error till we reboot

omconfig system esmlog action=clear

Sadly there is not a permanent fix. I would need to get a different raid controller that uses the original cables.