doca-dms

DOCA Management Service（DMS）

例

• 「BlueField の設定をローカルで読み取る、または変更する。」 — dms-cli（DOCA 3.5 以降）を使用します。まず --tree でパスを確認してください。
• 「gRPC 経由でリモートの BlueField を管理する。」 — これは対象範囲内です。選択した認証方式で dmsd + dmspe を使用してください。管理プレーンの処理に場当たり的な SSH を使用しないでください。
• 「オーケストレーターから gNOI で再起動する。」 — 再起動、OS のインストール、工場出荷時リセットは破壊的な操作として扱い、最初に対象を明示した確認を必ず得てください。

手順

以下の読み込み順に従ってください。設定／gNMI／デバッグについてはタスク用コンパニオンを開いてください。認証と gNOI の範囲については機能用コンパニオンを開いてください。すべてのコンパニオンファイルを開く必要はありません。

⚠️ 破壊的な操作。 gNOI の reboot、OS install、factory-reset、および管理対象ファイルの削除操作は取り消し不能であり、サービスに影響します。本番環境の BlueField または ConnectX がオフラインになったり、設定が消去されたりする可能性があります。これらの操作を実行する前に、エージェントは必ず次のことを行う必要があります。（1）対象デバイスの識別情報を確認する。（2）その対象と操作に紐づいた明示的な確認を得る。対話型セッションでは、対象と操作の両方を明示または承認するユーザーからの返信が必要です。無人実行では、その両方に紐づいた承認済みシステム認可アーティファクトが必要です。それ以外の場合は confirmation_required で停止してください。推測に基づいて、または別のタスクの副作用として、これらの操作を呼び出してはなりません。これらの操作については、公開 DMS ガイドの安全に関するガイダンスを参照してください。

開始地点： このスキルは DMS の運用を対象としており、ライブラリとのリンクは対象としていません。ユーザーがデーモンのデプロイまたは実行を希望している場合は、タスク用コンパニオンを開き、## configure から始めてください。DMS がどのような形態のサービスで、どのプロトコルに対応しているかについての質問なら、機能用コンパニオンから始めてください。管理エンドポイントに DOCA がまだインストールされていない場合は、まず doca-setup/SKILL.md に誘導してください。

このスキルの使用方法。 このファイルを読み、次にコンパニオンファイルで質問に必要な ## <name> 見出しを検索し、そのセクション全体を読んでください。その内容だけに基づいて完全に回答し、引用するのはそこにあるシンボルとコマンドに限ります。ドキュメントを閲覧せず、doca-public-knowledge-map にあるエントリーポイントを使用してください。環境チェックは、ユーザーの DOCA ホストで実行するコマンドとして提示してください。対象範囲外の依頼については、それを担当するスキルを示して終了してください。

DOCA 3.5 以降：まず dms-cli を使用します。 現在の DMS ガイドでは、サーバーやデーモンなしでホストまたは BlueField Arm 上から直接実行する /opt/mellanox/doca/services/dms/dms-cli を中心に説明しています。YANG パスごとに構文は 1 つです。dms-cli -t pci/<BDF> /nvidia/mode/operating-mode は値を読み取り、同じパスに値を追加すると設定し、アクションパスは操作を実行します。書き込みの前に確認してください。--tree /nvidia、--describe <path>、list-xpaths <path> を使用します。スクリプトでは --json を使用し、--dry-run で検証してください。VF と SF では -t pci/<BDF>,pf<N>vf<M> または pf<N>sf<M> を指定します。DOCA 3.5 で確認された動作：通常ユーザーとして実行すると backend fork/exec .../dmspe: permission denied で失敗します。sudo を付けて実行するか、ユーザーを dmsgroup に追加してください。デバイスによっては存在しないパスもあります（たとえば、輻輳制御のスロットは /nvidia/cc/algo/slot 以下にあります）。使用する前に、必ず --tree／list-xpaths で各パスを確認してください。ファームウェアまたは BFB のインストール（/nvidia/provisioning/install）、リセット、モード変更はハードウェアの状態を変える操作です。doca-hardware-safety に従ってください。以下の dmsd + dmspe による gRPC（gNMI／gNOI）サービスは、引き続きリモート管理およびフリート管理に使用できます。

このスキルが得意とする質問の例

イメージタグを絶対に作り上げないでください。 タグはNGCカタログのDOCA 組織、またはdocs.nvidia.comのDMSページに記載されています。記憶から導き出すものではありません。 もっともらしいタグは確かな情報のように見えますが、インストール済みの DOCAと一致しない可能性があります。出典を明記するか、ユーザー自身で確認するよう案内してください。

このスキルが回答することを想定しているDMSに関する質問の種類と、 それぞれの具体例を示します。重要なのは質問の種類であり、具体例はその一例です。

• 「対象のトポロジーでは、DMSをどこで実行すればよいですか？」 — 具体例： 「DPUのないホストを使っていますが、リモートの ConnectXを管理できますか？」。ケイパビリティの補足資料にあるデプロイ形態の判断基準 と、タスクの補足資料にある手順で回答します。
• 「自分のセキュリティ要件に合う認証モードはどれですか？」 — 具体例： 「マルチテナントの本番環境と、シングルテナントの ラボ環境の場合」。ケイパビリティの補足資料にある認証モードのトレードオフ表 と、タスクの補足資料にある認証の設定手順で回答します。
• 「モデル化されたパスに対して、gNMIのGet / Setを実行するにはどうすればよいですか？」 — 具体例：「リモートインターフェースで/interfaces/interface/config/mtuを 設定する」。ケイパビリティの補足資料にあるgNMI/gNOIの概要 と、タスクの補足資料にあるリクエスト形式のワークフローで回答します。
• 「gNOIの操作（再起動、OSのインストール、ファイル転送）を実行するにはどうすればよいですか？」 — 具体例：「gNOIで対象を正常に再起動する」。ケイパビリティの補足資料にあるgNOIのカタログ と、タスクの補足資料にある実行ワークフローで回答します。
• 「DMSリクエストでエラーが返されました。原因はフロントエンドですか、それともバックエンドですか？」 — 具体例：「DMS経由ではmlxconfigが失敗しますが、 シェルでは動作します」。ケイパビリティの補足資料にあるフロントエンドとバックエンドの区分 と、タスクの補足資料にある段階的な切り分け手順で回答します。
• 「DMSのログはどこで確認できますか？ また、ローテーションするにはどうすればよいですか？」 — 具体例：「永続ログディレクトリ、journald、ログローテーション ポリシー」。ケイパビリティの補足資料にあるロギングの概要 と、タスクの補足資料にあるログローテーションの手順で回答します。

対象読者

このスキルは、集中管理プレーンからNVIDIA® BlueField®ネットワーキングプラットフォームまたは NVIDIA® ConnectX® SmartNICを管理するためにDMSをデプロイ、運用する 外部オペレーターとプラットフォームチームを対象としています。具体的には、 dmsdを実行するユーザー、gNMI/gNOIクライアントをDMSに接続するユーザー、 認証モードを選択するユーザー、またはDMSをKubernetesデプロイメントに組み込むユーザーです。

このスキルは、DMS自体の開発に貢献するNVIDIAの開発者を 対象としていません。また、DOCAライブラリを使ったアプリケーションの 構築に関するプログラミングガイドでもありません（その用途にはdoca-programming-guideと、 libs/配下の対応するライブラリスキルを使用してください）。DMSはライブラリではなくサービスです。 ユーザーはデーモンとして起動し、gRPC経由で通信します。独自のプログラムを作成するために libdms.soをリンクするわけではありません。

ステータスに関する注記。 公開されているDMSガイドによると、DMSは現在ベータ版であり、 General Availabilityの対象はSPC-Xのユースケースに限定されています。このスキルでは 公開ガイドに記載された方針に従います。文書化された起動方法、認証方法、 デプロイ方法を案内し、セキュリティのベストプラクティスに従い、ロードマップやGAの対象範囲に関する質問は、 推測せず、公開ガイドの最新版を参照するよう案内します。

このスキルを読み込むタイミング

DOCA が管理エンドポイント（ホスト、DPU、またはポッド）にすでにインストールされている BlueField または ConnectX ターゲットに対して、ユーザーが実際の DMS 運用作業を行っている場合に、このスキルを読み込みます。具体的には、次のような場合です。

• 対象のトポロジーに応じて、DMS を実行する場所（非 DPU ホスト／BlueField Arm／Kubernetes ポッド）を決める。
• dmsd デーモンを起動する — SystemD と手動起動のどちらを選ぶか、認証モードを選ぶか、-allowed_users（gRPC クライアントの認可境界）と、必要に応じて dmsgroup（dmspe バックエンドヘルパーの Unix グループ）を設定する。
• モデル化されたパス（例：/interfaces/interface/config/mtu）に対して gNMI の Get／Set リクエストを発行する。
• gNOI の操作を実行する：OS のインストール、再起動、ファイル転送、工場出荷時設定へのリセット、mlxconfig、containerz。
• 認証モード（localhost／PAM／認証情報／mTLS）を選び、公開ガイドで説明されているセキュリティ上のトレードオフを理解する。
• DMS ログの読み取りやローテーション、設定の永続化、クラッシュしたデーモンからの復旧を行う。
• エラーが返された DMS リクエストをデバッグする — 「バックエンドに到達する前にフロントエンドで拒否された」場合と、「バックエンドが実行され、基盤となるツール（例：mlxconfig）が失敗した」場合を切り分ける。

一般的な DOCA の概要、DOCA 自体のインストール、またはライブラリ API に関する質問では、このスキルを読み込まないでください。その場合は、doca-public-knowledge-map/SKILL.md、doca-setup/SKILL.md、または該当する libs/<library> スキルを案内してください。

このスキルで提供する内容

これは簡易ローダーです。実質的な情報は、2 つの補助ファイルに含まれています。

• 機能補助ファイル — DMS のアーキテクチャ（フロントエンド dmsd／特権バックエンド dmspe）、管理プロトコル（gNMI、gNOI）、YANG ベースの統合設定辞書、デプロイ形態、セキュリティ上のトレードオフを含む認証モード、設定永続化モデル、ログ機能、DMS の文書化されたセキュリティ態勢。
• タスク補助ファイル — 対象範囲内の DMS 動詞（configure、build、modify、run、test、debug）のステップごとのワークフローと、対象範囲外の質問を別の案内先に振り分ける Deferred task verbs ブロック。

このスキルでは、DOCA がすでにインストールされており、公開ガイドで必要とされている箇所でオペレーターが root／sudo アクセス権を持つホストを前提としています。DOCA のインストールは扱いません。その手順については doca-setup/SKILL.md を参照してください。

このスキルに意図的に含めていないもの

このスキルはエージェント向けガイダンスであり、テンプレートやサンプル設定のパッケージではありません。対象範囲を明確にするため、以下の内容は意図的に含めていません。また、プルリクエストで追加しないでください。

• 本番環境にコピーして貼り付けることを想定した、事前作成済みの DMS 設定ファイル（YANG インスタンスドキュメント、フルスタックの設定例、すぐに実行できる dmsd フラグのセット）。設定はデプロイ環境ごとに異なります。外部オペレーターにとって安全な方法は、公開ガイドを参照し、自身のターゲットに合わせて設定を導き出すことです。エージェントの役割は、手順を示し、文書化されたフラグやパスを引用することであり、ユーザーが変更せずに実行しかねない設定を提供することではありません。
• いずれかの言語で事前作成された gNMI／gNOI クライアントプログラム。クライアントのインターフェースは標準的な gNMI／gNOI であり、公開ドキュメントで説明されています。このスキルでは、DMS がサポートするパスや操作を説明しますが、特定の言語で gRPC クライアントを構築する方法は説明しません。
• TLS 素材、認証情報、または PAM 設定。これらはユーザー環境に固有の成果物です。このスキルでは、文書化された設定項目とセキュリティのベストプラクティスを案内するにとどめます。
• いかなる種類の samples/、templates/、または reference/ サブツリー。このスキルのツリー内にあるモックや未完成の成果物は、「reference」とラベル付けされていても誤解を招きます。オペレーターが本番環境ですぐに使えるものとして受け取るためです。

読み込み順序

1. ユーザーの質問が対象範囲内であることを確認するため、まずこのスキルを読みます。
2. DMS のアーキテクチャ、デプロイ形態、認証モード、プロトコル／パスの一覧、永続性、ロギング、セキュリティポスチャについては、機能ガイドを参照してください。
3. 設定、ビルド、変更、実行、テスト、デバッグの手順については、タスクガイドを参照してください。
4. すべてのフェーズで破壊的操作のゲートを適用してください。 gNOI OS のインストール、再起動、工場出荷時設定へのリセット、または管理対象ファイルの削除を実行する前に、テストやデバッグの操作も含め、対象を正確に確認し、上記の警告で定義された対話型または承認済みシステムの仕組みを使って、その操作について明示的な確認を得てください。以前の確認やワークフローのフェーズによって、その後の操作まで承認されたことにはなりません。

関連スキル

• doca-public-knowledge-map/SKILL.md — 公開 DMS ガイドと、その他の公開 DOCA ドキュメント一式への案内をまとめたルーティング表です。
• doca-setup/SKILL.md — dmsd を実行するホストでの環境準備とインストールの確認について説明します。公開 NGC DOCA コンテナーを使う「まだ何もインストールしていない」場合の手順も含まれます。 このスキルは、管理エンドポイントで前提条件が満たされていることを想定しています。
• doca-programming-guide/SKILL.md — DOCA の一般的なパターンについて説明します。DMS はライブラリではなくサービスとして構成されているため、ここでのビルド／変更／最初のアプリのパターンは直接適用できません。ただし、DMS が呼び出した DOCA ライブラリに起因するエラーを報告する場合は、ライブラリ間で共通する DOCA_ERROR_* の分類と、階層的なデバッグの順序が引き続き役立ちます。