Doca Dms

DOCA Management Service (DMS)

> ⚠️ 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 TASKS.md and start at

## configure. If the question is *what shape

of service is DMS and what protocols does it speak*, start at

CAPABILITIES.md. If DOCA is not installed on the

management endpoint yet, route to

doca-setup first.

Example questions this skill answers well

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

CAPABILITIES.md ## Capabilities and modes

+ TASKS.md ## configure.

• **"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

CAPABILITIES.md ## Safety policy

+ the auth-wiring step in

TASKS.md ## configure.

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

worked example: *"set /interfaces/interface/config/mtu on a remote

interface"*. Answered by the gNMI/gNOI surface in

CAPABILITIES.md ## Capabilities and modes

+ the request-shape workflow in

TASKS.md ## run.

• **"How do I run a gNOI operation (reboot, OS install, file

transfer)?"** — worked example: *"trigger a clean reboot of the

target via gNOI"*. Answered by the gNOI catalog in

CAPABILITIES.md ## Capabilities and modes

+ the run workflow in TASKS.md ## run.

• **"My DMS request returned an error — was it the frontend or the

backend?"** — worked example: *"mlxconfig failed under DMS but

works on the shell"*. Answered by the frontend-vs-backend split in

CAPABILITIES.md ## Error taxonomy

+ the layered ladder in

TASKS.md ## debug.

• "Where do I read DMS logs and how do I rotate them?" — worked

example: *"persistent log directory + journald + log-rotation

policy"*. Answered by the logging surface in

CAPABILITIES.md ## Observability

+ the log-rotation step in

TASKS.md ## configure.

Audience

This skill serves **external operators and platform teams who deploy and

operate DMS** to manage NVIDIA® BlueField® networking platforms or

NVIDIA® ConnectX® SmartNICs from a centralized control plane. Concretely:

people running dmsd, integrating gNMI/gNOI clients against it, choosing

an authentication mode, or wiring DMS into a Kubernetes deployment.

It is not for NVIDIA developers contributing to DMS itself, and it

is not a programming guide for *building applications on top of*

DOCA libraries (that is doca-programming-guide plus the matching

library skill under libs/). DMS is a service, not a library: the

user invokes it as a daemon and talks to it over gRPC; they do not link

against libdms.so to write their own program.

Status note. Per the public DMS guide, DMS is currently in beta,

with General Availability scoped to SPC-X use cases. The skill reflects

the public guide's posture: prescribe the documented launch / auth /

deployment paths, follow the documented security best practices, and

defer roadmap and GA-scope questions to the live public guide rather

than guessing.

When to load this skill

Load this skill when the user is doing hands-on DMS operation work

against a BlueField or ConnectX target where DOCA is already installed

on the management endpoint (host, DPU, or pod). Concretely:

• Deciding *where* DMS should run (host non-DPU / BlueField Arm /

Kubernetes pod) for a given target topology.

• Bringing up the dmsd daemon — choosing SystemD vs manual launch,

selecting an authentication mode, wiring -allowed_users (the gRPC

client authorization boundary) and, if needed, dmsgroup (the

dmspe backend-helper Unix group).

• Issuing gNMI Get / Set requests against modeled paths

(e.g. /interfaces/interface/config/mtu).

• Issuing gNOI operations: OS install, reboot, file transfer,

factory-reset, mlxconfig, containerz.

• Choosing an authentication mode (localhost / PAM / credentials / mTLS)

and understanding the security trade-offs the public guide calls out.

• Reading or rotating DMS logs, configuring config persistency, or

recovering from a crashed daemon.

• Debugging a DMS request that returned an error — separating

"frontend rejected before reaching backend" from "backend executed and

the underlying tool (e.g. mlxconfig) failed".

Do not load this skill for general DOCA orientation, install of

DOCA itself, or library-API questions. For those, route via

doca-public-knowledge-map,

doca-setup, or the matching

libs/<library> skill.

What this skill provides

This is a thin loader. Substantive material lives in two companion

files:

• CAPABILITIES.md — DMS architecture (frontend dmsd / privileged

backend dmspe), management protocols (gNMI, gNOI), the YANG-based

unified configuration dictionary, deployment shapes, authentication

modes with their security trade-offs, the configuration-persistency

model, the logging surface, and DMS's documented security posture.

• TASKS.md — step-by-step workflows for the in-scope DMS verbs:

configure, build, modify, run, test, debug, plus a

Deferred task verbs block routing out-of-scope questions.

The skill assumes a host where DOCA is already installed and the

operator has root / sudo access where the public guide says it is

required. It does not cover installing DOCA — that path goes through

doca-setup.

What this skill deliberately does not ship

This skill is agent guidance, not a templates or sample-config

bundle. To keep the boundary clean, it deliberately does not contain —

and pull requests should not add:

• Pre-baked DMS configuration files (YANG instance documents,

full-stack example configs, ready-to-run dmsd flag bundles)

intended to be copy-pasted into production. Configs are deployment-

specific and the safe answer for an external operator is to derive

them from the public guide against their own target. The agent's

job is to prescribe the *procedure* and quote the documented flags

and paths, not to ship a config the user might run unmodified.

• Pre-written gNMI / gNOI client programs in any language. The

client surface is standard gNMI / gNOI (publicly documented); the

skill describes which paths and operations DMS supports, not how to

build a gRPC client in language X.

• TLS material, credentials, or PAM stanzas. These are

user-environment artifacts; the skill points at the documented

configuration knobs and the documented security best practices and

stops there.

• A samples/, templates/, or reference/ subtree of any

kind. A mock or incomplete artifact in this skill's tree, even one

labeled "reference", is misleading: operators will read it as

production-ready.

Loading order

• Read this SKILL.md first to confirm the user's question is in scope.
• **For the DMS architecture, deployment shapes, auth modes,

protocol/path inventory, persistency, logging, and security

posture, see CAPABILITIES.md.**

• **For step-by-step workflows — configure, build, modify, run, test,

debug — see TASKS.md.**

• Apply the destructive-operation gate in every phase. Before any

gNOI OS install, reboot, factory reset, or managed-file deletion —

including a test or debug action — verify the exact target and obtain explicit

confirmation for that specific operation using the interactive or

approved-system mechanism defined in the warning above. No earlier

confirmation or workflow phase carries authorization forward.

Related skills

• doca-public-knowledge-map

— the routing table to the public DMS guide and the rest of the

public DOCA documentation set.

• doca-setup — env preparation and

install verification on the host where dmsd will run, including

the *I have no install yet* path via the public NGC DOCA container.

This skill assumes its preconditions are satisfied at the management

endpoint.

• doca-programming-guide —

general DOCA patterns. DMS is service-shaped not library-shaped, so

the build / modify / first-app pattern there does not apply directly,

but the cross-library DOCA_ERROR_* taxonomy and the

layered-debug order remain useful when DMS reports errors that

originated in a DOCA library it called.