Skip to main content
Launch a managed Slurm cluster on your reserved Ornn GPUs, connect over SSH with your account keys, and submit your first GPU job. A managed Slurm cluster turns the GPU nodes you already reserved into a Slurm scheduler you reach over SSH. Ornn runs the scheduler and login node; you submit batch and distributed jobs with the standard Slurm tools. Logins use the SSH keys saved on your account.

​
When to use Slurm

  • You run batch jobs or distributed training and want a queue and scheduler.
  • Your team shares a pool of GPUs and needs fair scheduling across jobs.
  • You already have sbatch job scripts.
Prefer containers and orchestration? Use Kubernetes access instead. Want a single host you SSH into? See VM or Bare Metal.

​
Prerequisites

  • The bid is promoted to a confirmed reservation that is visible in My GPUs.
  • Checkout and payment for the reservation are complete.
  • Your account has at least one active SSH public key registered — Slurm logins use your account keys. See Manage SSH keys.

​
Launch the cluster

1

Open Orchestration

From the console, go to Orchestration (/controllers) and start a new Slurm cluster. Cluster launch is not on the reservation access-mode toggle in My GPUs.
2

Choose Slurm and a network mode

Pick Slurm, then a network mode:
  • Public — the SSH login is reachable over the internet.
  • Private — the SSH login is reachable only over your reservation’s WireGuard VPN.
3

Launch

Launch the cluster. The first launch after an enrollment takes a few extra minutes while the GPU images download. The scheduler starts once every node is GPU-ready; your SSH login details appear on the manage page when it’s ready.
CLI equivalent:

​
Connect over SSH

When the scheduler is ready, the cluster panel shows your SSH login host and port, a ready-to-run Connect command, and the login host key so you can verify it on first connect. Copy those values and connect:

​
Submit a job

On the login node, inspect the cluster and claim GPUs with the standard Slurm tools:
A minimal GPU sbatch script:

​
Use attached object storage

If you deploy a bucket-backed Ornn storage volume to the reservation, wait for its placement to show Ready. Slurm then exposes it on the login node and every worker at:
You do not need to tear down the cluster. The active cluster picks up an attached or detached volume during its normal status reconciliation; the Slurm pods may restart briefly while the mount changes.
Attaching or detaching storage can restart the login and worker pods, which can interrupt running jobs. Save a checkpoint before changing the attachment.This path is backed by object storage, not NFS. It is useful for datasets, checkpoints, and artifacts, but it does not provide full POSIX locking or safe concurrent writes to the same object. Coordinate writers in your job.

​
Private clusters: bring up WireGuard first

Private clusters expose nothing publicly — the SSH login is reachable only over your reservation’s WireGuard tunnel. Set it up once:
Once the tunnel is up, the SSH login above works unchanged. Your existing WireGuard config is preserved when the cluster toggles between Public and Private — you don’t need to regenerate it after switching modes.

​
Replace or remove a WireGuard config

Each WireGuard public key is registered once per gateway. To rotate the key or move the tunnel to a different machine, remove the existing peer from the Connect section first, then paste the new public key and generate a fresh config. If you paste a key that another reservation on the same gateway already owns, the console returns a WireGuard public key already in use error — generate a new keypair with wg genkey and try again, or remove the key from the reservation that currently owns it.

​
Tear down

Tearing down stops the scheduler, revokes SSH login access, drains the workers, and returns the GPU nodes to your reservation. A torn-down or failed cluster relaunches in place.
Teardown interrupts running jobs and can’t be undone. Persist checkpoints and data to attached or external object storage first.

​
Troubleshooting

Slurm logins use your account SSH keys. Confirm the private key your SSH client uses matches a key registered on your account, and that the cluster has finished issuing login access (the panel shows the SSH login once it’s ready).
The scheduler starts after every node reports GPU-ready. Wait for the manage page to show the SSH login host and port; the first launch is paced by the GPU image pull.
If you reconnect after a relaunch, remove the old entry and reconnect: ssh-keygen -R <login-host>. Verify the new key against the host key shown on the cluster panel.
Make sure the WireGuard tunnel is up (sudo wg show) before connecting. Re-generate the peer config from the Connect section if your public key changed.

​
What’s next

access

Kubernetes access

Prefer container orchestration? Run a managed Kubernetes cluster on your reserved GPUs instead.
ssh-keys

Manage SSH keys

Register the account SSH keys your Slurm logins use.