NVIDIA Docs Hub NVIDIA Networking Networking Software NVLink Management Software NMX Manager (NMX-M) Documentation v85.1.0009: PS Level Partitions Management

Partitions Management

In NMX-M, network partitions refer to logical groupings of GPUs that exist within the same network domain. Partitions can be created based on one of two member types:

GPU-ID-Based: A list of GPU identifiers.
Location-Based: A set of objects describing the physical location, including attributes such as domain, chassis, slot, and host.

The partition’s member type is established at creation and cannot be changed later. All subsequent operations (updates or reads) should match the originally defined type. For example, a partition created using location-based members cannot be updated using GPU IDs; such an attempt will result in a 409 Conflict error.

API Endpoints

All asynchronous requests (Create, Update, and Delete) return a 202 Accepted response immediately. This response includes:

A JSON body:

Copy
Copied!

            
            {
  "operationId": "551137c2f9e1fac808a5f572"
}

A Location header pointing to the operations endpoint:

Copy
Copied!

            
            /nmx/v1/operations/<op-id>

For resource creation, once the operation completes, the new partition can be retrieved by following the Location header or using a GET request at:

Copy
Copied!

            
            /nmx/v1/partitions/<p-id>

Both GET and GET-all endpoints return a 200 OK response with the partition details.

Partition Management Endpoints

Partition Action	Endpoint	Description
Create	`POST /nmx/v1/partitions`	Initiates the creation of a new network partition. The request body must include a partition name and a members object, which is either GPU-ID-based or location-based (mixing types is not supported).
Update	`PUT /nmx/v1/partitions/<p-id>`	Updates an existing partition. Note that currently the partition name cannot be changed. Instead, it is possible to update the list of members. When using PUT, the `members` parameter lists all GPUs that should be part of the partition. The system will determine which members to add or remove to match the desired configuration. Note The member type in the update must match the partition’s original type. A mismatch will result in a 409 Conflict error.
Delete	`DELETE /nmx/v1/partitions/<p-id>`	Deletes an existing partition. The deletion process returns an operation and follows the same asynchronous pattern as creation and update.
Retrieve	`GET /nmx/v1/partitions/<p-id>`	Retrieves details of a specific partition, including its health and other metada.
Retrieve	`GET /nmx/v1/partitions`	Retrieves a list of all partitions.

Partition Lifecycle and Types

Lifecycle Stage	Description
Creation	When a partition is created via a POST request, the API determines its type based on the provided members. The assigned type is permanent.
Update	Subsequent updates must maintain the same member type. Attempts to use a different member type (e.g., using GPU IDs on a location-based partition) will be rejected with a 409 Conflict error.
Deletion	Deletion of a partition is performed asynchronously and returns an operation. The partition is removed once the operation completes.
Retrieval	After an operation completes (e.g., partition creation), the partition can be accessed by following the Location header in the operation response or by using the partition ID in a GET request.
Health	Each partition includes a health metric that reflects the status of the underlying managed network.

Operational Considerations

Asynchronous Processing

All operations (create, update, delete) return a 202 Accepted response with an operationId and a Location header pointing to /nmx/v1/operations/<op-id>.
Operations continue until they reach a terminal state—failed, completed, or cancelled.

Cancellation

Operations can be canceled only if they have not started processing and no critical actions have been taken.
The cancellation process generates its own non-cancellable operation.

Constraints

Member Exclusivity

A GPU cannot belong to more than one partition.

Domain Consistency

All GPUs in a partition must belong to the same network domain.
Mixing GPUs from different domains is not possible.

Operation Results

The asynchronous operations created during partition management are used to track progress.
The operation should complete before acting on the partition.
The response includes a Location header pointing to the newly created resource.

Error Handling

The following error codes may be returned by the Partitions API:

Error Code	Description
400 Bad Request	The request is malformed or contains an improperly structured ID.
404 Not Found	The specified partition ID does not exist.
409 Conflict	Request contains unsupported arguments, such as: Updating with an incorrect member type. Mixing member types during creation. Assigning a GPU to multiple partitions. Including GPUs from different domains. Deleting or canceling a partition in an invalid state.
500 Internal Server Error	Unexpected server error.

On This Page