Reservations
The DGX Cloud Lepton Reservation feature enables you to carve out a fixed number of nodes within a node group for exclusive use by selected users in a workspace. Reservations guarantee capacity, ensuring critical workloads have access to dedicated compute resources when needed.
Overview
A reservation is tied to a specific node group and workspace. Once created and approved, users included in the reservation can launch workloads—batch jobs, dev pods, or inference endpoints—directly against it. Reservations ensure predictable scheduling and isolation from other workloads.
If a reservation has available capacity, eligible workloads are placed there. Otherwise, DGX Cloud Lepton falls back to scheduling on unreserved nodes in the node group.
Creating a Reservation
To create a reservation:
- Navigate to Workspace > Nodes > Config > Reservations.
- Click Create Reservation.
- Provide the reservation name, select users (either specific users or all users in the workspace), and enter the desired number of nodes.
- Submit the request for admin approval.
Figure 1. User view of submitting a new reservation request.
Admin View of Reservations
Admins can view all active reservation requests, node assignments, and status under:
Workspace > Nodes > Config > Reservations
Figure 2. Admin dashboard showing list of reservations with status and actions.
Approval Workflows
- Manual Approval: Admins can review and approve/deny requests.
- Auto-Approval: Admins can define auto-approval thresholds based on node count. Requests within the limit are automatically granted.
Figure 3. Admin configuration screen showing auto-approval threshold settings.
Users can monitor approval status in the dashboard. Notification support is not yet available.
Deleting Reservations
- Reservations do not expire automatically and must be deleted manually.
- Deletion can be performed by:
- Workspace Admins
- Users who are part of the reservation
Scheduling Workloads with Reservations
Users can target a reservation when launching workloads. DGX Cloud Lepton attempts to place the workload on the reservation's nodes first. If insufficient capacity is available:
- Without preemption: The job waits.
- With preemption enabled: The job may evict lower-priority workloads—even on other reservations or unreserved nodes.
Figure 4. Selecting a reservation when launching a workload and choosing the option to burst into other reservations if available.
Workloads from other users not in the reservation cannot use the reserved nodes unless preemption rules allow it.
Preemption Behavior
DGX Cloud Lepton supports workload preemption to manage contention:
- Preemption occurs only within the same reservation or for higher-priority workloads targeting overlapping resources.
- If enabled, a running job may be preempted when:
- A higher-priority workload from the same reservation arrives.
- The job is scheduled on permissible capacity and a reservation owner submits a workload.
For training workloads, checkpointing is the user's responsibility. If a job is preempted and not checkpointed properly, progress may be lost.
User Roles and Permissions
| Role | View Reservation | Create Reservation | Approve Reservation | Delete Reservation |
|---|---|---|---|---|
| Workspace Admin | ✅ All reservations | ✅ | ✅ | ✅ All reservations |
| Workspace User (in reservation) | ✅ Own reservations | ✅ (with rules) | ❌ | ✅ Own reservations |
| Workspace User (not in reservation) | ❌ | ✅ (with rules) | ❌ | ❌ |
-
Create: Any workspace user can create a reservation, but the request must either:
- Include themselves in the reservation, or
- Be made for all users in the workspace
Otherwise, the request will be rejected with the error:
"Reservations created by non-admin users must contain themselves or allow all users."
-
View: Only users included in the reservation (and all admins) can view or select it when launching workloads.
-
Approve/Delete: Only Workspace Admins can approve or delete any reservation. Users may delete only those they are part of.
Best Practices
- Reserve only as many nodes as needed to avoid idle capacity.
- Use auto-approval for self-service team workflows.
- Enable preemption thoughtfully to maintain fairness and responsiveness.
Frequently Asked Questions
Q: Can users outside a reservation see or use it?
A: No. Only admins and users within the reservation can view or launch workloads against it.
Q: Can reservations span different GPU types (e.g., H100 + B200)?
A: No. Reservations inherit the homogeneity constraint of the node group they are created in.
Q: Can I create a reservation on partially used nodes?
A: No. A node must be fully idle—no CPU or GPU workload—before it can be added to a reservation.
Q: What happens if I request more nodes than are available?
A: The system will reject the request with an error message. No partial reservation is created.
Q: Do reservations expire?
A: No. Reservations persist until explicitly deleted by an admin or a user who is part of the reservation.
Q: Can I increase the size of an existing reservation?
A: Not at this time. To change node count, delete and re-create the reservation.
Q: Can I include all users in the workspace in a reservation?
A: Yes. You can select either specific users or all users in the workspace when creating a reservation.
Q: How do I know if my workload is scheduled from a reservation?
A: The workload detail view in the dashboard shows the reservation ID used for scheduling, if applicable.
Q: What does preemption look like in practice?
A: If a job enables "Allow burst to other reservation nodes", it can use the free resources of nodes reserved by another reservation. Once a reservation-bound job is created, it will likely evict the former job. The evicted job may restart if checkpointing is supported.