[Question]: How to specifiy /nvidia-fabricmanager/socket for device plugin

[shan100github]

Kubernetes version: v1.34.9

GPU-Operator & Device plugin version:
nvcr.io/nvidia/k8s-device-plugin:v0.19.3
nvcr.io/nvidia/gpu-operator:v26.3.3

on the nvidia-device-plugin-daemonset came across following message msg="Could not locate /nvidia-fabricmanager/socket: /nvidia-fabricmanager/socket: not found"

can you please share on the node, how we can see /run/nvidia-fabricmanager/fm_sm_ipc.socket file, how to override /nvidia-fabricmanager/socket location to /run/nvidia-fabricmanager/fm_sm_ipc.socket through gpu-operator?

I came across #1336

[tariq1890]

@shan100github Thanks for creating the issue. Can you share more details about your use case?

[shan100github]

We are using nvidia B300 systems. On nvidia driver and fabircmanager services are running in hostos,

We were facing such messages on all the nvidia-device-plugin-daemonset container logs.

[kvnloo]

I think there are two different deployment contracts mixed together here:

1. Fabric Manager managed inside the NVIDIA/operator stack.
2. Fabric Manager already running on the host OS.

The operator already has host integration around /run/nvidia-fabricmanager in the driver path, while this device-plugin deployment is looking for its expected Fabric Manager socket inside the container.

For the host-managed FM case, I think the useful contract would be:

host FM socket directory -> explicit device-plugin mount -> canonical in-container socket path

rather than making every consumer independently configurable for arbitrary host socket paths.

Could we document or expose the intended mount for a host-managed Fabric Manager?

A regression could run with a fake host socket under /run/nvidia-fabricmanager, render the device-plugin DaemonSet, and verify the socket is reachable at the path the plugin expects.

That would also make it clear whether the current warning is expected/harmless on this topology or indicates a missing operator mount.