UFM as an evidence source
Use topology, events, and telemetry with their timestamps and version context.
help for the full list, or solutions for reference procedures. Simulated outputs do not validate your environment.UFM provides a view of an InfiniBand fabric, but a dashboard is still an observation with a capture time. Correlate its topology and events with endpoint evidence and the workload timeline.
Ask a bounded question
| Question | Data to collect |
|---|---|
| Is this the expected peer? | Local/remote GUIDs and port identifiers |
| Did capacity change? | Negotiated width and speed over time |
| When did the problem begin? | Event history for the affected endpoints |
| Is the pattern local or shared? | Comparable neighboring ports |
| Is the view current? | Service health, last update, retention window |
Use the REST API documentation for the installed UFM release. Paths, filters, pagination, and response fields vary; copying an endpoint from another release can produce an incomplete or misleading result. NVIDIA's UFM manual links the release-specific operating documentation.
Keep port-state concepts separate
Physical state describes link behavior such as polling or training. Logical state describes subnet participation, such as Down, Init, Armed, or Active. A manager may also expose policy or health status.
Do not combine those into one universal state machine. An Active logical state does not prove full bandwidth. A non-active port needs physical, configuration, and subnet-manager context.
Build an event timeline
Fetch the complete relevant window, including pagination. Keep raw event identifiers, source timestamps, timezone information, and collection time. Several events can describe one underlying interruption.
A reboot hypothesis needs corroborating uptime or platform evidence; a single “up” event is insufficient. Likewise, a quiet event page does not rule out a fault outside the retained window.
See evidence collection, InfiniBand, and subnet management.