We are pleased to announce the release of Open Cluster Scheduler 9.1.5 and Gridware Cluster Scheduler 9.1.5. As always, both are based on the same foundation: All key improvements and bug fixes in the scheduler for this version are incorporated into the open-source Open Cluster Scheduler, and the Gridware Cluster Scheduler builds upon this solid foundation, supplementing it with enterprise features for specific use cases. In version 9.1.5, these enhancements deliver three major advancements: Resource Maps (RSMAPs) now describe and isolate the underlying devices; Qontrol evolves from a user interface for a single cluster to a central console for entire cluster fleets; and qtelemetry gains an execution host mode that makes observability scalable at the job level.

In short: If you’re using the Open Cluster Scheduler, version 9.1.5 offers a number of significant improvements in terms of reliability and core system functionality. If your environment requires hardware-based device isolation, centralized management of multiple clusters via Qontrol, or granular job telemetry, this is where the Gridware Cluster Scheduler comes into play.

RSMAP Characteristics and Device Isolation: Beyond Names, Beyond GPUs (Gridware Cluster Scheduler)

A resource map names the individual instances of a host resource — the GPUs in a node, its network interfaces, a pool of license seats — so the scheduler can both count them and record which one each job received. Until now, an instance was nothing more than a name: anything an administrator knew about the hardware behind it had to be encoded into the name itself and decoded again by a prolog script.

With 9.1.5, RSMAP instances can carry characteristics: typed metadata attached to one specific instance. A characteristic describes what sets an instance apart from its siblings — the device file it maps to, the memory on the card, its affinity to a CPU socket, the bandwidth of an interface:

gpu=2(gpu0[device=/dev/nvidia0] \
      gpu1[device=/dev/nvidia1])

Each attribute is based on a regular complex definition, ensuring that the values are correctly typed—memory as MEMORY, bandwidth as INT, device paths as strings. An instance’s attributes accompany it through the scheduler, so a job is informed which instance has been assigned to it, along with all the information the administrator has recorded about it.

Why this matters for your cluster:

Hardware-based device isolation. The first consumer of characteristics is the new devices characteristic. It lists the device files a job may use, with an access mode per device. When the job starts, the execution daemon hands that list to systemd as the DeviceAllow property of the job’s scope and sets DevicePolicy=closed. The result: a job requesting one GPU sees exactly the devices of the GPU it was granted — the other accelerators on the host are simply invisible to it. No shepherd wrapper scripts, no environment-variable conventions that well-behaved applications happen to respect: the kernel enforces the boundary.

Not just GPUs. Because RSMAPs are a generic mechanism, this works for any device-backed resource — NPUs and other AI accelerators, FPGAs, high-speed network interfaces, storage devices. If it has a device file and you want to hand out individual instances safely, RSMAP characteristics with device isolation cover it. This opens the door to a broad range of multi-tenant accelerator use cases that previously required custom scripting.

Configuration is a single qconf command per host, and the full grammar — including modeling shared devices — is documented in the sge_complex(5) and sge_host_conf(5) man pages and the “Systemd Integration” chapter of the Administration Guide.

Qontrol Goes Multi-Cluster (Gridware Cluster Scheduler)

Qontrol, our modern replacement for qmon, takes its biggest step yet in 9.1.5: it can now manage multiple remote clusters from one place.

The key to this is the new qontrol-agent. Instead of Qontrol having to reach into every cluster, the agent runs alongside a cluster and establishes a secure websocket connection outbound to the Qontrol console. That direction matters in practice: clusters behind firewalls or NAT, in different data centers or cloud regions, can all register themselves with a central console without any inbound connectivity to the clusters.

A setup pattern we expect to become popular: run Qontrol centrally on a Kubernetes cluster — 9.1.5 ships a Dockerfile and a helm chart for exactly this — and let your local clusters, wherever they are, connect in for centralized administration. Fittingly, Qontrol no longer requires a local cluster to be present at all; it can now be a pure console for remote fleets.

Beyond multi-cluster support, this release continues Qontrol’s quality-of-life march: a dark mode, load sensors and JSV scripts that can be configured and installed from templates, a live preview when editing calendars, and a series of smaller fixes — from the execd_params editor correctly handling boolean switches to version gating now asking the selected cluster rather than the central server.

qtelemetry: Per-Job Observability That Scales (Gridware Cluster Scheduler)

qtelemetry, our Prometheus/Grafana metrics exporter, gains different operating modes in 9.1.5 — most importantly an execution-host mode.

Running directly on the execution daemon hosts, qtelemetry now exports execution-host metrics and per-job on-host telemetry: memory, I/O, and CPU usage of individual jobs, tracked over time. Because the data is collected and exported where the jobs actually run, this scales with your cluster — there is no additional query load on the qmaster and the core scheduling system, no matter how many jobs you monitor. Previously, per-job metrics were only available centrally and recommended just for very small workloads; the execution-host mode removes that constraint.

The pre-built Grafana dashboards on Grafana Cloud have been updated to include the execution-host data, and a dedicated example dashboard for execution-host metrics is available, so visualizing the new data is a matter of minutes.

Reliability Across the Board — in Both Editions

As with every release, a long list of fixes benefits Open Cluster Scheduler and Gridware Cluster Scheduler alike. Highlights in 9.1.5 include:

• More flexible job submission. New communication_params settings in the bootstrap configuration allow more flexible ways of submitting jobs to clusters, accommodating environments where client hostnames and addresses don’t resolve the way a classic HPC network expects.
• Communication robustness under load. The commlib listen backlog is no longer hardcoded to 5, fixing failed qrsh -inherit task delivery during connection bursts in large parallel jobs.
• Execution daemon correctness. A fix ensures the execution daemon can no longer lose track of running jobs — which previously could mean missing wallclock usage and unenforced runtime limits.
• Accurate accounting. Several accounting and JSONL reporting fixes, including correct final usage records for long-running jobs, correct wallclock summation for parallel environments, and correct exit status recording for tightly integrated PE jobs without tasks.
• Cleaner shutdown and thread safety. Double-free issues at shutdown and a race in request-limit parsing between listener threads were resolved, and the build system gains thread-sanitizer support to keep it that way.
• Modern platforms. Builds on Ubuntu 26.04 with gcc 15 are fixed, and a known-issues chapter documents behavior of id and groups on distributions that switched to uutils coreutils, together with practical guidance for job scripts.

Backup and restore now also include the TLS certificates, so a restored cluster comes back with its encryption intact.

A Note on Upgrading

Two things are worth knowing before you upgrade — both covered in detail in the release notes:

• TLS private keys move below the cell. Daemon keys now live in a per-cell directory, fixing conflicts between side-by-side installations sharing a port. Nothing needs to be done — daemons recreate their certificates on first start — but the old key files can be cleaned up afterwards.
• File descriptor limits in systemd unit files. The qmaster unit file template now sets LimitNOFILE=65536, ensuring the full default number of dynamic event clients (used by qsub -sync and DRMAA) is available. Existing installations keep their old unit files until updated; the release notes describe both a manual edit and the inst_sge -upd-rc route.

Get Started

Open Cluster Scheduler 9.1.5 and Gridware Cluster Scheduler 9.1.5 are available now. Open Cluster Scheduler remains a fully capable, production-grade workload manager — and everything in it flows directly into Gridware Cluster Scheduler, which adds enterprise features like RSMAP device isolation, multi-cluster Qontrol, qtelemetry, and professional support for sites that need them. As always, the release notes contain the complete list of changes, and the Installation and Administration Guides cover the new features in depth.

If you’d like to talk about bringing hardware-enforced accelerator isolation or centralized multi-cluster administration to your environment — or about whether Open Cluster Scheduler or Gridware Cluster Scheduler is the better match for your site — get in touch; we’re happy to help.