Red Hat’s NVIDIA DSX Integration Turns AI Factory Operations Into a Managed Platform

Red Hat published a technical breakdown on August 7 explaining how its Red Hat AI platform and OpenShift now plug into NVIDIA’s DSX OS, the modular software stack NVIDIA introduced in May to run large, multi-tenant AI data centers. The post, written by Red Hat Director of Engineering Ami Zvieli, frames the integration as a response to a shift already underway across the industry: AI infrastructure has moved past one-off pilot deployments, and operators now need a shared platform that keeps costs predictable, tracks the latest chips, and updates itself without a stack of custom scripts holding it together.

That framing places the post inside a much larger, ongoing collaboration. Red Hat and NVIDIA outlined a broader partnership in January, when CEOs Matt Hicks and Jensen Huang committed to day-zero support for NVIDIA’s upcoming Vera Rubin platform across Red Hat Enterprise Linux, RHEL AI, and OpenShift AI. The August post is the engineering-level follow-through on that commitment: a look at the specific pieces of DSX OS that Red Hat now integrates with, and how they fit into an OpenShift-based operations model.

A Kernel Foundation Built in the Open

The integration starts below the application layer. Red Hat and NVIDIA co-engineer kernel-level support through the CentOS Accelerated Infrastructure Enablement (AIE) Special Interest Group, a CentOS Stream 10 initiative that gives NVIDIA’s in-flight kernel patches a fast lane into the community codebase, often months before those patches land upstream. That work feeds directly into Red Hat Enterprise Linux for NVIDIA, the RHEL variant built to support new silicon, including Grace Blackwell and the upcoming Vera Rubin platform, without waiting for a standard RHEL release cycle.

Four Pieces of the DSX Stack, Wired Into OpenShift

NVIDIA’s own description of DSX OS breaks it into named components that handle provisioning, configuration, health, and monitoring separately. Zvieli’s post walks through how four of them connect to OpenShift specifically.

Provisioning and Isolating Bare Metal

The NVIDIA Infra Controller, or NICo, is what NVIDIA describes as providing “API-driven bare-metal lifecycle management and hardware-enforced tenant isolation” through NVIDIA BlueField DPUs. Red Hat’s post describes an “end-to-end NVIDIA BlueField DPU provisioning and lifecycle management” integration between NICo and OpenShift, so bringing up a bare-metal node becomes a fully API-driven process rather than a manual one. Isolation between tenants is enforced specifically through NVIDIA BlueField-3: Zvieli’s post says it gives the joint architecture “secure, hardware-isolated, and multi-tenant IaaS boundaries” that are managed directly from the Red Hat OpenShift control plane, rather than something OpenShift has to police entirely in software.

Keeping Thousands of Nodes From Drifting

Large fleets tend to drift out of sync with whatever configuration they started with, one node at a time, until nobody can say for certain what is actually running. NVIDIA’s answer is the AI Cluster Runtime (AICR), which the company says captures a cluster’s configuration as “version-locked recipes, eliminating configuration drift,” rather than a set of scripts someone has to remember to rerun. Red Hat’s contribution is an in-tree set of Helm templates covering components like Node Feature Discovery and the NVIDIA GPU Operator, so those recipes deploy through the same OpenShift workflows teams already use for everything else, instead of a separate NVIDIA-specific toolchain.

Catching Failures Before They Cascade

At gigawatt scale, a GPU failure that goes unnoticed for even a few minutes can cascade into a much larger training job failure. NVSentinel, which NVIDIA says offers “automated remediation, cordoning unhealthy compute nodes and draining workloads in seconds,” runs as a validated, Kubernetes-native fault detector on OpenShift: Red Hat’s post says that upon detecting a critical hardware or driver event, it automatically isolates the compromised node and reassigns its workloads to healthy ones. Sitting above individual-cluster detection, NVIDIA’s Fleet Intelligence layer aggregates telemetry across every deployment for what the company calls “fleet-wide visibility, integrity verification, and health monitoring,” and Red Hat’s post says that data flows into the Grafana dashboards operators already use to watch the rest of their infrastructure.

Testing the Data Center Before It Exists

The least conventional piece is DSX Air, a cloud-hosted simulation service that lets a team model an entire AI factory, compute, networking, storage, security, and orchestration included, before a single server ships. NVIDIA positions it as a way to catch bottlenecks and configuration mistakes during planning instead of during a production rollout. Red Hat’s integration lets teams validate multi-tenant topologies and upgrade scripts inside DSX Air using lightweight Red Hat footprints, including Single Node OpenShift, so the environment they test against resembles the one they will actually run.

Agentic Operations, Guarded by RBAC

Zvieli’s post also lays out a security model for agentic operations. NVIDIA DSX OS surfaces data center telemetry and operational controls through domain-specific Model Context Protocol (MCP) servers, and Red Hat AI governs that layer with namespace-scoped access controls and zero-trust security boundaries inside OpenShift. Using OpenShift’s native RBAC, multi-tenancy, and audit logging, the post says validated MCP servers let autonomous agents safely query cluster metrics and inspect logs, rather than operate with standing access to the underlying infrastructure. It is Red Hat’s own description of that governance layer, not something independently documented elsewhere, but it fits a pattern already visible across the rest of the stack: wrap new agentic capability in the access controls that already exist, rather than inventing new ones.

Why the Wiring Work Matters

None of these pieces is new on its own. NICo, AICR, NVSentinel, Fleet Intelligence, and DSX Air are all NVIDIA components that predate this post, and Red Hat’s own OpenShift RBAC and Helm tooling are years old. What the August 7 post actually documents is integration work: connecting an existing enterprise Kubernetes platform to an existing AI-factory operating system so that the parts NVIDIA ships and the parts Red Hat ships behave like one system instead of two adjacent ones. For enterprises trying to run AI infrastructure as a shared, multi-tenant service rather than a collection of one-off GPU pools, that wiring work, unglamorous as it is, is what actually determines whether the platform holds up in production.