What is SLURM?

The scheduler's responsibility covers the whole job lifecycle:

• Partitions and nodes - which queues exist, what hardware sits in them, and who may submit to each.
• Job state - pending, running, completed, failed and cancelled, including dependencies between jobs.
• Policy - fairshare, quality-of-service levels, reservations and priority weights.
• Isolation - CPU, memory and accelerator allocation per job, typically enforced with cgroups.
• Accounting - who ran what, for how long, against which allocation.

That last item is why research facilities and national laboratories standardise on it: the component enforcing the rules and the component producing the billback report are the same component.

SLURM won by being open, portable across hardware generations, and specific enough for batch work: users submit with familiar commands, a controller daemon assigns work, and daemons on the nodes execute it. Alternatives exist - PBS variants, LSF, MOAB - and remain in place at sites that have invested in them, often behind portals such as Open OnDemand that present the queue through a browser.

Accelerators entered the model as allocatable resources rather than as a separate world, so a job can request GPUs alongside cores and memory and land on nodes that have them. Sites configure authentication to suit their own identity infrastructure, with munge the customary choice on clusters and token-based authentication used where a service talks to the controller.

Users work with SLURM through submission commands: a batch script is handed over with the resources it needs, an interactive allocation is taken when a shell is wanted, and a step command launches work on the nodes already assigned. From there a job is pending until policy and capacity permit it, running while its steps execute, and finally completed or failed with output and exit status recorded where the submission asked for them.

Two features make a queue usable at site scale. Arrays let one script stand for a family of related jobs, so a parameter sweep is scheduled as a group instead of as hundreds of separate submissions. Dependencies let one job wait on another, turning a pipeline of stages into a chain the scheduler holds together. Neither changes what an outside buyer sees: a job either receives its resources and runs, or it waits its turn.

Supercomputing does not buy like cloud. Work arrives as jobs with resource requirements, walltime limits and partition targets, scheduled against allocation policies that encode years of institutional decisions. A long-running service lease, priced by the hour with an open-ended duration, is the wrong shape for that - and forcing batch work into it loses the accounting, the queueing fairness and the backfill that make a cluster efficient. For the wider category see HPC.

The mismatch runs both ways. A cluster operator asked to sell capacity does not want a tenant's container orchestrating over the top of the queue and bypassing policy, and a tenant does not want to hand a workload to a scheduler whose queue they cannot see. Both concerns point at the same design: expose the job, not the node.

The HPC on VirtEngine guide describes the bridge: the x/hpc module models a batch job on-chain with resource, walltime and partition requirements, and the provider daemon polls those jobs and dispatches them through a native SLURM adapter configured with the site's own authentication and partition names. Concurrency limits and timeouts are set by the operator, and job state is recovered crash-safely if a component restarts mid-run.

What does not change is who owns scheduling. The cluster's controller still decides what runs where, so the marketplace becomes another source of authorized work rather than a second scheduler fighting it for the nodes. Usage from those jobs flows into the same signed reporting and settlement path as any other lease, and facilities able to sell spare cycles find them listed under HPC clusters rather than quoted per customer.