Skip to content

Known Limitations

Review this page before planning your deployment to understand the current limitations and constraints of Omnia v2.2.

General limitations

  • Omnia supports only diskless provisioning of servers.
  • Dell Technologies provides support only for Dell-developed Omnia components. Third-party software deployed by Omnia is not covered under Dell support.
  • Containerized benchmark jobs are not supported on Slurm clusters.
  • All iDRACs must be configured with the same username and password.

InfiniBand restrictions

As described in the Red Hat documentation for InfiniBand and RDMA networking, Mellanox ConnectX-4 and newer adapters running RHEL 8 or later use Enhanced IPoIB mode by default. Enhanced IPoIB supports only datagram mode; connected mode is not supported.

Local repository GPG validation

The local_repo.yml playbook completes successfully even when an invalid GPG key is provided during repository configuration. GPG key validation is currently not enforced during Pulp remote creation. Although local repositories support GPG keys, this functionality is not yet enabled in Pulp.

For tracking, see: pulp_rpm issue #4241

BuildStream limitations

  • BuildStream does not support customization of catalog_rhel.json.
  • BuildStream does not support installation of additional packages through the catalog.
  • BuildStream does not support automatic retry of failed pipeline jobs.

GPU software deployment limitations

  • DCGM and CUDA Toolkit are deployed only on Slurm compute nodes where NVIDIA GPUs are detected during provisioning.
  • Nodes provisioned without GPUs will not have DCGM or CUDA configured and cannot be converted into GPU-enabled nodes without reprovisioning.
  • DCGM installation depends on successful detection of the CUDA major version from an initialized NVIDIA driver. If driver initialization is incomplete during provisioning, DCGM deployment is deferred and must be completed manually.

Upgrade and rollback limitations

  • Omnia supports in-place upgrades only from v2.1.0.0 to v2.2.0.0. Direct upgrades that skip releases (for example, v2.0.0.0 to v2.2.0.0) are not supported. Upgrade one version at a time.

  • Rollback is intended for recovery from failed or partially completed upgrades. Rolling back a successfully completed upgrade is not recommended and is blocked by default. It can be forced using:

    Run on: omnia_core container
    ansible-playbook rollback.yml -e force_rollback=true

    However, consistency across all components cannot be guaranteed.

  • New VAST storage mounts added after an upgrade are not retained during rollback.

  • Slurm and Kubernetes upgrade or rollback operations reboot all affected nodes simultaneously, resulting in temporary cluster downtime. Schedule these operations during a maintenance window.

BuildStream upgrade restrictions

When BuildStream is enabled during an upgrade:

  • Kubernetes, Slurm, Telemetry, and related components are redeployed as new clusters through the GitLab CI/CD pipeline.
  • Existing cluster state, jobs, and custom configurations are not preserved.
  • The GitLab pipeline must be triggered manually after the upgrade.
  • BuildStream is intended primarily for test-bed environments.

Additionally:

  • Disabling BuildStream during upgrade is not supported if it was enabled in Omnia 2.1.0.0.
  • Selective execution using --tags is not supported for upgrade or rollback operations. The complete playbook must be executed. On reruns, previously completed components are automatically skipped.

Telemetry and GitLab rollback restrictions

  • Telemetry data stored in VictoriaMetrics and Kafka is not preserved during rollback. Any telemetry collected after the upgrade is lost when the telemetry stack is reverted.
  • GitLab project rollback requires the upgrade commit to be the latest commit in the repository. If additional commits exist after the upgrade, automatic rollback will not restore GitLab content. In such cases, manually revert GitLab repository changes before performing the rollback.

BMC discovery limitations

OS NIC MAC address retrieval on Belton platforms

Affected configurations:

  • Dell Belton platforms
  • Shared LOM (LAN on Motherboard) configurations
  • Mellanox ConnectX-6 and ConnectX-7 network adapters
  • Systems in a bare-metal state (no operating system installed)

Issue:

When the system is in a bare-metal state, the host operating system NIC MAC address cannot be retrieved using standard management interfaces, including:

  • iDRAC GUI
  • OpenManage Enterprise (OME)
  • Redfish APIs
  • RACADM CLI
  • Lifecycle Controller inventory

Note

The iDRAC MAC address remains visible and is reported correctly through iDRAC and OME. NIC devices are detected, but their host MAC address fields remain empty or unavailable.

Workarounds:

To obtain the host NIC MAC address, use one of the following methods:

  • Monitor DHCP or PXE boot traffic
  • Check network switch MAC address tables
  • Use factory-provided MAC address inventories
  • Review PXE boot logs

Capture DHCP discovery traffic to identify the host NIC MAC address:

Run on: OIM host
tcpdump -i <interface> -nne port 67 or port 68
Expected output
DHCPDISCOVER from 3c:ec:ef:12:34:56

In this example, 3c:ec:ef:12:34:56 is the host operating system NIC MAC address.

PXE mapping file GROUP_NAME and PARENT_SERVICE_TAG values from OME discovery

Affected configurations:

  • Dell Omnia deployments integrated with OpenManage Enterprise (OME) discovery.

Issue:

Server identification and mapping during PXE boot rely on information retrieved from OME and iDRAC inventory. Depending on the DNS environment, the DnsName value may match the intended iDRAC hostname, or may return a reverse DNS name (for example, pool-<IP-based>), which may not align with naming conventions required for cluster configuration. This can result in incorrect GROUP_NAME and PARENT_SERVICE_TAG values in the generated BMC PXE mapping file.

Note

Due to differences between iDRAC configuration and OME-reported hostnames, you must explicitly define GROUP_NAME and PARENT_SERVICE_TAG in the pxe_mapping_file to ensure accurate PXE provisioning and cluster setup in Omnia.

ADMIN_IP and BMC_IP correlation in single-subnet /24 environments

Affected configurations:

  • Deployments using OME discovery to auto-generate pxe_mapping_file.csv.
  • Single-subnet /24 environments where the BMC and Admin networks differ only at the 3rd octet.

Issue:

When Omnia generates pxe_mapping_file.csv via OME discovery, it derives Admin (PXE) and InfiniBand IP addresses from the BMC (iDRAC) IP using a fixed octet-substitution algorithm. The first two octets are taken from the configured admin/IB subnet, and the last two octets (3rd and 4th) are copied from the BMC IP address:

Octet-substitution algorithm
ADMIN_IP = <admin_subnet octet 1>.<admin_subnet octet 2>.<BMC octet 3>.<BMC octet 4>
IB_IP = <ib_subnet octet 1>.<ib_subnet octet 2>.<BMC octet 3>.<BMC octet 4>

This correlation works correctly only when the BMC and Admin networks differ in the first two octets (that is, an effective /16 boundary differentiation).

Example -- Working (networks differ at 2nd octet):

  • BMC: 10.10.43.0/24
  • Admin: 10.20.43.0/24
  • BMC IP 10.10.43.100 -> Admin IP 10.20.43.100

Example -- Failing (networks differ only at 3rd octet):

  • BMC: 172.20.43.0/24
  • Admin: 172.20.44.0/24
  • BMC IP 172.20.43.100 -> Admin IP 172.20.43.100 (same as BMC IP -- 3rd octet 43 is copied from BMC instead of using 44 from the admin subnet)

In network environments where the BMC and Admin subnets share the same first two octets and differ only at the 3rd octet (common in /24 deployments), the generated ADMIN_IP will be identical to the BMC_IP. The same issue applies to IB IP generation.

Note

This is by-design behavior for the current Omnia 2.2 release. The correlation is designed for /16 subnet environments or multi-subnet topologies where multiple /24 subnets fall within the same /16 range, and differentiation is based on the 3rd and 4th octets. In single-subnet /24 environments where BMC and Admin networks differ only at the 3rd octet, the auto-generated mapping file will produce incorrect Admin and IB IP addresses.

Workaround:

Manually edit the generated pxe_mapping_file.csv to correct the ADMIN_IP and IB_IP columns before running provision.yml.

Documentation feedback

For feedback on Omnia documentation, contact: omnia.readme@dell.com

Info