The Slurm appliance set provides a rapidly deployable, self-configuring cluster environment. The Slurm Controller manages resources and job queues, while Slurm Workers dynamically join the cluster to execute workloads.

The appliances use Slurm configless mode:

• Centralized configuration: The Controller owns the Slurm configuration.
• Automatic worker configuration: Workers start slurmd with --conf-server slurm-one-controller:6817 and retrieve configuration from the Controller.
• Dynamic nodes: Workers register with -Z and report their current CPU and memory resources automatically.
• GPU resources: Workers detect available NVIDIA GPUs with nvidia-smi and advertise them as Slurm GRES resources.

The default controller configuration includes:

• ClusterName=one
• SlurmctldHost=slurm-one-controller
• AuthType=auth/munge
• SlurmctldParameters=enable_configless
• SelectType=select/cons_tres
• GresTypes=gpu
• PartitionName=all Nodes=ALL Default=yes

Workers resolve slurm-one-controller through a local /etc/hosts entry that maps the Controller IP discovered from OneGate.

The cluster uses Munge for Slurm authentication. The Controller generates the Munge key, verifies the local Munge service, and publishes the base64-encoded key to OneGate as SLURM_MUNGE_KEY.

Workers receive the Munge key through OneGate. They discover the Controller role, wait for READY=YES, read the Controller network address and SLURM_MUNGE_KEY, install the key locally, and verify Munge before starting slurmd.

The Marketplace OneFlow service uses ready_status_gate. OneFlow does not deploy Worker VMs until the Controller has published READY=YES. The Controller appliance publishes that attribute when configuration succeeds, and the imported Controller and Worker templates include REPORT_READY=YES so one-context can also report readiness after bootstrap.

Each Worker publishes its Slurm node name to OneGate as SLURM_NODENAME. This gives the Controller a reliable mapping between OneFlow Worker VMs and Slurm dynamic nodes.

Workers also install a best-effort shutdown hook. During graceful shutdown, the hook marks the node down and attempts to delete it from the Controller.

The Controller runs a periodic reconciler through oneslurm-reconcile.timer. It compares live Worker VMs from OneGate with registered Slurm nodes and only treats a node as stale when all of the following are true:

• The node is registered in Slurm.
• No matching live Worker publishes that SLURM_NODENAME through OneGate.
• The Slurm node state matches DOWN or NOT_RESPONDING.

For those stale nodes:

• Nodes with no running jobs are deleted.
• Nodes with running jobs are drained with reason removed from OneFlow service.

If OneGate service data is unavailable or no live SLURM_NODENAME values can be resolved, the reconciler exits without changing Slurm state.

The OneFlow service template exposes a mandatory Service network input and Slurm-specific user inputs for LDAP identity. Select the Service network when instantiating the service; OneFlow attaches it to the Controller and Worker roles. CPU, memory, disk size, and GPU PCI devices are VM template settings and should be reviewed on the imported Controller and Worker VM templates before instantiating the service when you need non-default sizing or GPUs.

The Controller is the authority for LDAP-related cluster metadata. Workers consume the LDAP settings published by the Controller through OneGate (LDAP_URL, LDAP_DOMAIN, LDAP_ADMIN_USER, LDAP_BIND_USER, and LDAP_BIND_PASSWORD when set).

The Controller supports three identity modes:

• Disabled: LDAP_URL is cleared from OneGate and sssd is stopped.
• Local LDAP: Set ONEAPP_LDAP_ENABLE=YES to configure local OpenLDAP on the Controller and SSSD clients on the Controller and Workers.
• External LDAP: Set ONEAPP_LDAP_URL and ONEAPP_LDAP_DOMAIN to configure the Controller and Workers as SSSD clients of an external LDAP service.

Service input parameters include:

When local LDAP is enabled, the Controller creates the LDAP base DN plus ou=People and ou=Groups. Add POSIX users and groups under those organizational units, then verify identity resolution through SSSD:

getent passwd <user>
getent group <group>
srun -N1 -n1 getent passwd <user>

For NFS-backed home directories, create the user's home directory on /home after the LDAP user exists and set ownership to the LDAP UID/GID. For scratch workloads, create a user-owned directory under /scratch, for example /scratch/<user>.

The Controller and Worker images include the NFS client packages needed to mount shared home and scratch exports. During network contextualization, the net-12-mount-nfs script reads the NFS service inputs and mounts:

• ONEAPP_SLURM_NFS_HOME at /home
• ONEAPP_SLURM_NFS_SCRATCH at /scratch

The values must use host:/export format. Empty values skip the mount. The default mount options are sec=sys,_netdev, and the filesystem type is nfs4. The script adds an idempotent /etc/fstab entry after a successful mount.

Service inputs:

The NFS server and exports must be prepared outside the appliance and reachable from both Controller and Worker VMs. Do not attach another filesystem at /home or /scratch when the corresponding NFS input is set.

Validate NFS mounts from the Controller:

findmnt /home
findmnt /scratch

Validate from a Worker through Slurm:

srun -N1 -n1 findmnt /home
srun -N1 -n1 findmnt /scratch

The Slurm Worker image ships with NVIDIA driver packages. The Marketplace Worker VM template does not automatically select a GPU. To run GPU jobs, attach a GPU PCI device or GPU PCI profile to the Worker VM template before instantiating or scaling the service. For an NVIDIA H100 PCIe device, a generic PCI request can look like:

PCI = [
  VENDOR = "10de",
  DEVICE = "2331",
  CLASS  = "0302" ]

For other NVIDIA GPUs, use the device ID or PCI profile exposed by the OpenNebula host. The Worker detects the GPU with nvidia-smi and starts slurmd with Gres=gpu:<count>.

Validate GPU scheduling from the Controller with:

srun -N1 -n1 --gres=gpu:1 nvidia-smi -L

The Slurm Worker image includes the RDMA userspace stack, NVIDIA UCX from the Canonical DOCA PPA, Open MPI runtime packages, and the Slurm PMIx plugins needed for MPI jobs. The Controller image includes Open MPI development packages so users can compile MPI programs on the login/controller node and run them on Workers.

InfiniBand configuration is disabled by default at deployment time. Enable it only for clusters whose Worker VMs have a passthrough InfiniBand HCA and whose fabric already has a subnet manager.

Service inputs:

When enabled, each Worker derives its IPoIB address from the supplied subnet and its Ethernet address. The subnet prefix determines how many octets are copied from Ethernet:

Only /8, /16, and /24 prefixes are supported. Make sure the copied Ethernet octets are unique across Workers, otherwise two Workers can derive the same IPoIB address.

The Slurm control path remains on the regular Ethernet network: Controller discovery, Munge, LDAP, and slurmd registration do not use IPoIB. MPI and RDMA traffic can use the IPoIB/verbs path when jobs request it.

For Slurm-launched MPI jobs, the Controller sets MpiDefault=pmix when InfiniBand is enabled, so srun and sbatch can use PMIx without adding --mpi=pmix to every job.

Basic validation from a Worker:

ibstat
ibv_devinfo
ip addr show ib0
ucx_info -d | grep mlx5

Basic validation from the Controller:

mpicc --version
srun -N2 hostname
scontrol show config | grep -E 'MpiDefault|PropagateResourceLimitsExcept'

Access the Slurm Controller VM.

onevm ssh <controller_id>

Then use standard Slurm commands to inspect the cluster. For example:

scontrol show nodes

sinfo

For OneGate discovery, a Controller or Worker VM should also be able to return the service document:

onegate service show

If onegate service show returns Service <id> not found, verify that OneGate can reach the active OneFlow endpoint. The :oneflow_server: setting in /etc/one/onegate-server.conf must match the running OneFlow server.

• The appliance does not include slurmdbd; job accounting, history, and usage statistics are not persisted through SlurmDB.
• Munge is the only configured Slurm authentication mechanism.
• Workers depend on OneGate service discovery, a working OneGate-to-OneFlow configuration, the selected Service network, and network access to the Controller on TCP port 6817.