/doca-dms

license: Apache-2.0
name: doca-dms
description: >
  Operate NVIDIA DOCA Management Service on a BlueField, Arm/x86 host,
  or Kubernetes pod: from DOCA 3.5 the local `dms-cli` (one command per
  YANG path, no server), and the `dmsd` + `dmspe` service: choose deployment and
  authentication, configure `-allowed_users` and `dmsgroup`, use gNMI
  Get/Set, run supported gNOI workflows, and debug
  frontend/backend failures. Trigger even without "DMS" for "manage a
  remote BlueField over gRPC", "gNOI reboot from orchestrator", or
  fleet-management requests. SAFETY: reboot, OS install, factory-reset,
  and managed-file deletion are destructive and require target-bound
  explicit confirmation; never invoke them speculatively. Route
  installation and library/API build questions elsewhere, and route
  telemetry streaming and aggregation to doca-dts (DOCA Telemetry
  Service).
metadata:
  author: NVIDIA <doca-feedback@nvidia.com>
  kind: service
  doca_version: "3.5"
  tags:
    - doca
    - dms
    - gnmi
compatibility: >
  DOCA service shipped with the DOCA install at /opt/mellanox/doca on
  the management endpoint (x86 host (non-DPU), BlueField Arm, or
  Kubernetes pod) on Linux (Ubuntu 22.04/24.04 or RHEL/SLES); `dmsd` +
  `dmspe` run there, and DMS is also pulled as an NGC container image.
  Verify the public DMS guide version matches the installed DOCA release
  before quoting flags or YANG paths. The validation steps require a
  live DOCA install.

DOCA Management Service (DMS)

Examples

• **"Read or change a BlueField setting locally."** — use

`dms-cli` (DOCA 3.5+); explore the path with `--tree` first.

• **"Manage a remote BlueField over gRPC."** — this is in

scope. Use `dmsd` + `dmspe` with the chosen auth; do not drop to ad-hoc SSH for the management plane.

• **"gNOI reboot from orchestrator."** — treat reboot / OS

install / factory-reset as destructive: require target-bound explicit confirmation first.

Instructions

Follow Loading order below. Open the tasks companion for configure / gNMI / debug. Open the capabilities companion for auth and gNOI scope. Do not open every companion file.

> **⚠️ Destructive operations.** The gNOI `reboot`, `OS install`, > `factory-reset`, and managed-file deletion operations are > **irreversible** and **service-impacting** > — they can take a production BlueField or ConnectX offline or wipe its > configuration. Before issuing any of them the agent MUST: (1) verify the > target device identity, and (2) obtain explicit confirmation bound to > that target and action. In an interactive session this is an explicit > user reply naming/accepting both; in unattended execution it must be an > approved-system authorization artifact bound to both. Otherwise stop > with `confirmation_required`. Never invoke them speculatively or as > a side effect of another task. See the public DMS guide's safety > guidance for these operations.

**Where to start:** This skill is for *operating* DMS, not for *linking against* a library. If the user wants to *deploy* or *run* the daemon, open the tasks companion and start at `## configure`. If the question is *what shape of service is DMS and what protocols does it speak*, start at the capabilities companion. If DOCA is not installed on the management endpoint yet, route to `doca-setup/SKILL.md` first.

**How to use this skill.** Read this file, then search the companion file for the `## <name>` heading the question needs and read that whole section. Answer completely from it, quoting only its symbols and commands. Do not browse docs; use the entry points in `doca-public-knowledge-map`. Give environment checks as commands for the user's DOCA host. For out-of-scope requests, name the skill that owns them and stop.

**DOCA 3.5 and later: start with `dms-cli`.** The DMS guide now centres on `/opt/mellanox/doca/services/dms/dms-cli`, run directly on the host or BlueField Arm with no server or daemon. One syntax per YANG path: `dms-cli -t pci/<BDF> /nvidia/mode/operating-mode` reads a value, the same path plus a value sets it, and action paths run operations. Explore before writing: `--tree /nvidia`, `--describe <path>` and `list-xpaths <path>`; script with `--json`; validate with `--dry-run`. VFs and SFs take `-t pci/<BDF>,pf<N>vf<M>` or `pf<N>sf<M>`. On DOCA 3.5: as a normal user it fails with `backend fork/exec .../dmspe: permission denied` — run it with `sudo` or add the user to `dmsgroup`; some example paths do not exist on every device (for example congestion-control slots are under `/nvidia/cc/algo/slot` there), so confirm every path with `--tree` / `list-xpaths` before using it. Firmware or BFB installs (`/nvidia/provisioning/install`), resets and mode changes are hardware-state changes: follow `doca-hardware-safety`. The `dmsd` + `dmspe` gRPC (gNMI / gNOI) service below remains for remote and fleet management.

Example questions this skill answers well

> **Never invent the image tag.** It comes from the NGC catalog's DOCA > org or the DMS page on `docs.nvidia.com`, not from memory — a > plausible tag reads as authoritative and mismatches the installed > DOCA. Cite where it came from, or send the user to look it up.

The CLASSES of DMS questions this skill is built to answer, each with one worked example. The class is the load-bearing piece; the worked example is one instance.

• **"Where should DMS run for my target topology?"** — worked example:

*"I have a host without a DPU; can I still manage a remote ConnectX?"*. Answered by the deployment-shape decision in the capabilities companion

• the tasks companion.
• **"Which authentication mode should I pick for my security

posture?"** — worked example: *"a multi-tenant production env vs a single-tenant lab"*. Answered by the auth-mode trade-off table in the capabilities companion

• the auth-wiring step in

the tasks companion.

• **"How do I issue a gNMI `Get` / `Set` against a modeled path?"** —

worked example: *"set `/interfac