arXiv CSopen access

Examining QRMI as a Unified Interface for Quantum-HPC Integration

Examining QRMI as a Unified Interface for Quantum-HPC Integration x

Thomas Badts†† Tim Boyle ∥ Claudio Carvalho§ Antonio Córcoles§ Andrew Damin Vadim Elisseev§ Jonathan Frassineti† Daniel Gruber‡ Hiroshi Horii§ Eun-Kyung Lee§ James Machin∗ Sara Marzella† xii Mateusz Meller Daniel Milroy¶ Matthieu Moreau†† Munetaka Ohtani§ Elisabeth Ortega-Carrasco‡‡ xiii xi xii Doug Oucharek∗∗ Yoonho Park§ Adarsh Patil Emre M. Sahin Gábor Samu§ Seetharami Seelam§ xii Amir Shehata∗∗ Vanessa Sochat¶ James Thorne∥ Oscar Wallis Aleksander Wennersteen†† ∗ Alice & Bob † CINECA ‡ HPC Gridware § IBM ¶ Lawrence Livermore National Laboratory ∥ National Quantum Computing Centre ∗∗ Oak Ridge National Laboratory †† Pasqal

‡‡ Qilimanjaro Quantum Tech x Rensselaer Polytechnic Institute xi Siemens xii STFC Hartree Centre

arXiv:2607.19591v1 [cs.ET] 21 Jul 2026

xiii

Corresponding Author: [email protected]

Abstract—The efficient and scalable integration of quantum resources into high-performance computing (HPC) environments requires standardized mechanisms for resource management, scheduling, and workflow orchestration across diverse and heterogeneous infrastructures. The Quantum Resource Management Interface (QRMI) addresses this challenge through a thin, vendor-agnostic middleware layer that provides standardized APIs for scheduling, executing, and monitoring quantum workloads while exposing quantum resources as first-class schedulable resources alongside CPUs and GPUs. Although previous work demonstrated QRMI integration with the Slurm workload manager, its applicability across other workload managers remained unexamined. This paper extends the validation of QRMI to a broad range of workload managers, including PBS, LSF, Grid Engine, Kubernetes, and the Flux Framework, encompassing traditional batch schedulers, a cloud-native orchestration platform, and a graph-based scheduler. We examine the integration patterns, implementation requirements, and scheduler-specific considerations associated with each environment and compare QRMI with alternative approaches to quantum resource integration. We demonstrate that QRMI provides a portable and flexible abstraction layer that minimizes scheduler-specific modifications while enabling consistent access to heterogeneous quantum resources across both on-premises and cloud environments. Index Terms—Quantum Resources, HPC, Job Management, Resource Management, Workload Managers, QRMI, Integration

I. I NTRODUCTION The convergence of quantum and HPC presents unique challenges in integrating quantum systems into existing HPC infrastructure. There is a critical need for standardized interfaces for quantum resource management, particularly as workflow orchestration becomes increasingly important in quantum-HPC integration. Current approaches suffer from fragmentation, making it difficult to deploy quantum computing capabilities across diverse HPC environments. The Quantum Resource Management Interface (QRMI) introduces a thin and vendor-agnostic middleware layer that abstracts the control and management of quantum resources [1]. It exposes standardized APIs for accessing, scheduling, exe-

cuting, and monitoring quantum workloads, decoupling application logic and resource management from hardware-specific implementations. By treating quantum resources as first-class schedulable resources—alongside CPUs and GPUs—QRMI enables unified visibility and control across heterogeneous systems, while simplifying integration of quantum resources in HPC environments. Within the broader context of quantum–HPC integration, QRMI plays a central role in enabling hybrid workflows envisioned for Quantum-Centric Supercomputing (QCSC) [3]. As quantum and HPC systems evolve from loosely coupled offload models toward tightly integrated, co-designed platforms, the need for consistent abstractions across heterogeneous resources becomes critical. The QRMI approach has been validated with Slurm. The QRMI APIs allow on-premises and cloud-hosted quantum devices from a variety of hardware vendors to be incorporated into Slurm via extensible interfaces. In this paper, we examine the QRMI approach across a wider variety of workload managers including PBS (Portable Batch System), IBM Spectrum LSF® (Load Sharing Facility), Grid Engine, Kubernetes, and the Flux Framework. This is, to the best of our knowledge, the first examination of a quantum resource interface spanning traditional batch schedulers (Slurm, PBS, LSF, Grid Engine), a container orchestrator for elastic cloud resources (Kubernetes), and a hierarchical workload manager that uses a graph-based scheduler (Flux Framework). Building on the initial Slurm integration, this paper makes the following contributions: • Examination of QRMI integrations across five major workload managers: (1) Slurm, (2) PBS, (3) LSF, (4) Grid Engine, and (5) Kubernetes; • Analysis of integration patterns for batch schedulers and a container orchestrator; • Quantum integration in a graph scheduler (Flux Framework); • Suggestions for improvements to QRMI and workload managers to facilitate quantum-HPC integration, practical

deployment guidelines, and lessons learned. The remainder of this paper is organized as follows: Section II provides background on HPC workload management systems, quantum resources integration challenges, and existing quantum-HPC integration approaches. Section III describes the QRMI architecture and design. Section IV describes the QRMI integrations across different workfload managers. Section V presents an analysis of the workload manager integrations and lessons learned. Section VI discusses future work. Section VII concludes. II. BACKGROUND AND R ELATED W ORK This section discusses the workload managers used in the examination, the quantum integration challenges, and other quantum integration approaches. A. HPC Workload Managers A workload manager (or batch system) provides the interface to manage resources and schedule workloads [47]. It includes the job manager, which receives new jobs and moves them through job lifecycle states, and the resource manager, which is responsible for tracking and monitoring hardware resources. The paper also refers to workflows. A workflow is a set of tasks with dependencies that need to be executed in a specific order for proper handling of exchanging inputs and outputs of data [47]. Workflows typically have two components: data and applications. Workflow tools (also called workflow managers) must decide the granularity at which to map tasks to execution workload units, which are then handled by a workload manager. Slurm: Slurm is a widely deployed open-source workload manager that provides job scheduling, resource allocation, and job monitoring [17] [52]. It can manage custom resources through its Generic Resource (GRES) framework, which enables scheduling and accounting of resources such as GPUs, high-bandwidth memory, software licenses, and other site-defined devices. Its plugin architecture, particularly the SPANK (Slurm Plug-in Architecture for Node and Job Control) framework, enables extensibility at various points in the job lifecycle. PBS: PBS Professional and its open-source counterpart, OpenPBS, are workload managers for distributed and HPC environments [18] [53]. OpenPBS was used in this study. PBS is extensible through custom resource definitions and scheduler policies. A Python-based hook framework lets sitespecific logic run at key points across the job and system lifecycle from submission and scheduling to execution. The site-specific logic runs in hooks within a central daemon or compute node daemon depending on the triggering events. LSF: LSF and its free version, LSF Community Edition, used in this study, are workload managers for distributed and HPC environments [19] [54]. LSF provides workflow capabilities through job dependencies, resource sharing, and fault-tolerant execution. It is extensible through features such as ELIM (External Load Information Manager), which enables

site-specific resource metrics to be incorporated into scheduling decisions, as well as through custom resource definitions. LSF also supports extensible lifecycle management via eventdriven hooks that allow custom actions to be triggered at key job and system lifecycle events. Grid Engine: Grid Engine is a family of workload managers that originated from Sun Grid Engine [20] and is actively continued today through the open-source Open Cluster Scheduler [40] and its commercial derivative, Gridware Cluster Scheduler. Open Cluster Scheduler was used in this study. It supports resource-aware scheduling, cluster queues, job dependencies, and consumable resource management including extensible accounting. A key feature is its flexible custom resource model based on complex definitions. It is further extensible through a large set of event-driven mechanisms that allow site-specific integrations and lifecycle management actions. Kubernetes: While Kubernetes is not primarily a workload manager, it is included in this evaluation due to its growing adoption in HPC environments for hybrid workflows and elastic resource provisioning across on-premises and cloud infrastructure [21] [55]. Kubernetes provides declarative resource management and supports extensibility through custom resources (CRDs), operators, admission controllers, and scheduler plugins. It also includes built-in mechanisms for service discovery, load balancing, scaling, fault tolerance, and automated reconciliation of desired and actual system state. The default Kubernetes scheduler is used in this study. Flux Framework: Flux is a next-generation workload management framework designed for exascale and post-exascale computing [22] [56]. It features a hierarchical architecture with flexible module and plugin systems and a graph-based scheduler. It is extensible through its plugin architecture, including Jobtap plugins that enable custom scheduling policies, job prioritization, dependency management, and resource management logic, as well as through site-defined resources. Flux also supports extensible lifecycle management through event-driven plugins and callbacks, allowing custom actions to be triggered at key job and system lifecycle events. B. Quantum Resources Integration Challenges Integrating quantum resources with existing workload managers introduces several architectural, operational, and userexperience challenges, stemming from the fundamental mismatch between classical HPC scheduling models and the behavior of quantum resources. Abstraction mismatches: Existing workload managers expect local and relatively static resources, while quantum resources may be remote and more dynamic in nature with differing capabilities and access semantics. This requires additional configuration layers and administrator-managed mappings between logical resource names and physical endpoints, introducing complexity and potential inconsistency across environments. Until quantum computing matures, users must still reason about quantum resource selection and performance, which vary across systems and providers. Ensuring

that applications remain quantum resource-agnostic while still exposing enough control for performance tuning is a delicate balance. [1] highlights that developing appropriate software abstractions is a key hurdle. Scheduling limitations: Traditional schedulers are not designed for hybrid quantum–HPC workflows that require tight coordination across CPUs/GPUs and quantum resources. Quantum resources may have latency constraints, session semantics, or limited availability windows that can be incompatible with queue-based batch scheduling. As noted in [3], current systems often require manual orchestration of workloads, job coordination, and data movement, significantly reducing productivity as well as incurring unnecessary costs. This motivates the development of new integration layers such as QRMI. Ensuring correct co-scheduling, for example, aligning HPC compute with quantum execution windows, and avoiding duplicated queues or fragmented scheduling domains remain challenging. Lifecycle integration: The initial integration of quantum resources into Slurm through QRMI and the SPANK plugin model is described in [1]. The integration required hooking into multiple stages of the job lifecycle (submission, initialization, execution, teardown) to acquire and release quantum resources and propagate tokens and environment variables. Of course, other workload managers have different plugin models, APIs, lifecycle semantics, and process models which determine how environment variables are propagated, creating additional integration complexity. Deployment and operational complexity: While deployment and operational complexity will ease as quantum resources matures, the current complexity is a challenge. Workload manager integrations require plugins or hooks with different language requirements. See Table III that summarizes the language requirements for the workload managers in this study. System dependencies such as compilers, libraries, and workload manager headers lead to installation and maintainability issues. Administrators must manage credentials, endpoints, and environment variables for each quantum resource, which increases operational burden. C. Other Quantum-HPC Integration Approaches Driven by practical needs, several efforts to integrate quantum computers into HPC environments exist [10] [11]. There has also been prior work integrating quantum resources with cloud-native orchestration engines like Kubernetes [12] [13]. None of these efforts, in our view, provides a sufficiently comprehensive framework for quantum-HPC integration. Two larger systematic projects are also currently being developed as we explain below. QDMI (Quantum Device Management Interface) [6] provides a device-level management interface with an implementation for IQM quantum computers and a Slurm integration [34]. The QDMI-Slurm integration is similar to the QRMI-Slurm integration described in [1]. While QRMI focuses on integration with HPC environments through workload managers, QDMI focuses on compiler toolchain integration

and monitoring. In many ways, QDMI and QRMI complement each other. The openQSE (open Quantum-HPC Software Ecosystem) project [4] is an open-source, community-driven effort to define a reference architecture and common interface boundaries for the quantum-HPC software stack. It was motivated by a survey of nine production quantum-HPC stacks, which found that current solutions are largely isolated, often proprietary, full-stack implementations lacking common interfaces across the runtime, compilation, resource management, and execution layers. The goal of openQSE is not to replace existing SDKs, vendor stacks, or open-source efforts, but to define vendorneutral layer boundaries to allow applications, runtimes, resource managers, and quantum resource implementations to interoperate. The effort is organized into working groups spanning architecture, workflows and use cases, compilation, and resource management. To ground these interface definitions in working code, the project is developing QFw (Quantum Framework), a modular orchestration framework that integrates quantum resources into conventional HPC infrastructure [23]. QFw plugs into the workload manager (Slurm), exposes a uniform platform API to hybrid applications, and dispatches quantum tasks through pluggable resource adapters to interchangeable quantum resources, whether software simulators or vendor hardware. Because the quantum resources sit behind a common internal boundary, QFw serves as a practical testbed in which candidate interfaces can be exercised end-to-end rather than evaluated only on paper. The resource management working group is using this testbed to build a concrete understanding of what a common quantum resource interface must provide. Both QRMI and QDMI have been integrated into QFw behind the same adapter layer, allowing identical workflows (resource discovery and introspection, acquisition and release, and job execution) to be driven through each interface side by side against the same scheduler integration and the same quantum hardware. This comparison exposes where the two interfaces converge, where their semantics differ, and which capabilities users actually require. The findings feed back into the openQSE specification effort, creating a loop in which architectural decisions are validated in a working system before being proposed as community standards. III. QRMI A RCHITECTURE AND D ESIGN As shown in Figure 1, QRMI serves as a vendor-agnostic abstraction layer that enables quantum computers to be managed as first-class schedulable resources within existing HPC workload management systems [1]. Users submit hybrid quantum–HPC jobs through a familiar workload manager interface. QRMI sits between the workload manager (such as Slurm) and diverse quantum resources. QRMI decouples workload manager logic from hardware-specific APIs, allowing the same operational workflow to support multiple quantum providers and deployment models. Through this abstraction, quantum resources can be represented consistently regardless of whether

they correspond to a cloud-hosted quantum resource, a single QPU, a partition of a larger device, or a set of parallel execution lanes, simplifying administration and enabling unified scheduling, accounting, and access control.

GRES, and extends them just enough to incorporate quantum execution. This is a pragmatic compromise that enables early and incremental adoption without requiring wholesale changes. This approach does have limitations which will be discussed later in the paper. Use thin integration layers for lifecycle management: QRMI addresses lifecycle management through thin integration layers such as Slurm SPANK plugins that map scheduler events to QRMI operations as shown in Table I. This design preserves the native control flow, avoids invasive changes, and provides a clear contract between lifecycle management and quantum resource management. While this approach is not fully portable between workload managers due to differences in workload manager design, this approach does create a repeatable pattern (referred to as acquire-execute-release) that will be discussed later in the paper. Lifecycle Event

QRMI Operation

Job start

Acquire quantum resources and tokens for each quantum resource Expose connection information for each quantum resource via environment variables Release quantum resources and free tokens for each quantum resource

Job execution Job completion

TABLE I: QRMI job lifecycle events.

Fig. 1: QRMI architecture, showing core language bindings, resource-management functions, and adapters connecting workload managers and quantum SDKs to heterogeneous quantum resources. QRMI addresses integration challenges by reshaping how quantum resources are exposed, scheduled, and consumed within existing systems. Its approach is a combination of standardization, indirection, and incremental integration. Abstract heterogeneity: To address abstraction mismatches, QRMI abstracts heterogeneity by providing a uniform, vendorneutral API for interacting with quantum resources. Instead of requiring workload managers and applications to understand provider-specific details, QRMI exposes a consistent interface for resource discovery, acquisition/release, job management, and observability. This decouples workload manager and application logic from hardware details and enables the same integration approach to work with multiple hardware providers. By shifting complexity into a well-defined middleware layer, QRMI allows workload managers and applications to integrate against the same abstraction rather than different quantum resource APIs. Treat quantum resources as first-class schedulable resources: QRMI represents quantum devices as first-class resources within existing workload managers, similar to CPUs or GPUs. This helps address scheduling and co-scheduling challenges by integrating quantum resources into existing resource accounting and allocation models and enabling hybrid job submission through familiar interfaces. QRMI tries to reuse existing workload manager semantics, for example, Slurm

Encapsulate complexity into configuration and middleware: QRMI pushes environment- and provider-specific complexity into configuration files (quantum resource definitions and credentials) and middleware logic (resource acquisition, authentication, session management). This addresses operational and heterogeneity challenges by keeping the scheduler interface simple and stable, isolating provider-specific logic from user workflows, and allowing administrators to centrally manage resource mappings. Although this increases configuration burden, it enables consistent behavior across environments and reduces coupling between application code and infrastructure. Integration Challenges Not Discussed: As shown in Figure 1, QRMI provides resource discovery and accounting information. QRMI resource discovery allows users to specify constraints, for example, the number of qubits or the type of quantum processor. Some workload managers, such as LSF and Grid Engine, support the ability to define resource characteristics and specify resource constraints. QRMI accounting information makes quantum resource and quantum job metrics available in a QRMI database. Most workload managers provide accounting information. However, not all workload managers provide support for extending accounting information, for example, Slurm. Because both QRMI and workload managers provide resource discovery and accounting information, the challenge is defining the responsibilities of QRMI and the workload managers. This challenge is out of scope for this paper. Another integration challenge not discussed is credentials management. QRMI does not dictate how credentials are managed. Credentials can be placed in an administratormanaged file. Credentials can be specified by users through

environment variables. Credentials can be stored in files in user home directories. The correct credentials management approach depends on the security requirements of the HPC data center. IV. QRMI W ORKLOAD M ANAGER I NTEGRATIONS The integration of QRMI with Slurm introduced design patterns for incorporating quantum resources into established HPC environments [24]. Extending this work, we describe the integration of QRMI with Slurm, PBS, LSF, Grid Engine, Kubernetes, and the Flux Framework with respect to three key design patterns: (1) treat quantum resources as a schedulable resource, (2) use thin integration layers for lifecycle management, and (3) encapsulate complexity into configuration and middleware. Although the Kubernetes integration does not strictly follow these design patterns, it nevertheless supports quantum-HPC workloads. The Flux Framework integration remains incomplete but provided valuable insights into scheduling challenges. The section ends with a discussion of other integration considerations which are captured in Table III. A. Slurm Integration Treat quantum resources as a schedulable resource: Slurm provides Generic Resources (GRES) for this purpose. Administrators define GRES in two layers: cluster-level enablement in slurm.conf and node-level details in gres.conf. An example of defining a quantum resource (qpu) in slurm.conf is shown in Listing 1. ibm_fez is a logical name for the quantum resource which can be accessed from node[1-8]. Listing 1: Slurm GRES quantum resource configuration GresTypes=qpu Gres=qpu:ibm_fez:1 NodeName=node[1-8] Gres=qpu:1

Then simple

users can request quantum resources using command-line flags, for example, sbatch --gres=qpu:ibm_fez:1. This decouples the quantum application code from underlying cluster infrastructure configurations. In addition to GRES, Slurm can also set up licenses to abstract quantum resource consumption. Use thin integration layers for lifecycle management: Slurm supports lifecycle customization through SPANK plugins. The QRMI SPANK plugin follows an acquire-execute-release pattern. During job setup (slurm_spank_init_post_opt() callback), it acquires access to the requested quantum resources through QRMI. During execution (slurm_spank_task_init() callback), it exposes the required connection and quantum resource metadata to the application environment. At job completion (slurm_spank_exit() callback), it releases those resources back to the underlying provider or control service. The acquirer provides an acquisition token for each quantum resource. These tokens must be stored for the release. Because the SPANK callbacks slurm_spank_init_post_opt() and slurm_spank_exit() run in the same process, the QRMI SPANK plugin stores the token as part of an internal context structure.

Encapsulating complexity into configuration and middleware: As discussed above, users request abstract quantum resources through standard Slurm submission interfaces using logical resource names and scheduler options. Administrators define the mapping from those logical names to physical quantum resources and credentials, and QRMI encapsulates the provider-specific logic needed to establish and manage access. Application code should remain as quantum resourceagnostic as possible. Application code should not handle session setup or quantum resource-specific configuration because those concerns are delegated to the Slurm configuration and QRMI. Slurm configuration is through the qrmi_config.json file which is administrator-managed. It connects Slurm-visible, logical quantum resource names to the quantum resources that QRMI can access. qrmi_config.json contains all the information that the QRMI SPANK plugin needs to access the quantum resources, including API endpoints and credentials. Additional challenges: The Slurm integration revealed several important challenges. Most fundamentally, there is a mismatch between the abstractions of classical batch scheduling and the operational semantics of quantum resources. Slurm assumes relatively stable and schedulable resources, but quantum resources are not always available due to calibration requirements and are usually governed by provider-specific queueing and session models. The Slurm GRES abstraction exposes quantum resources as requestable resources, but does not itself represent provider-side changes in readiness or queue state without deep changes in code where the intended target are GPUs. Thus, Slurm does not support a mechanism to update the status of custom resources defined as GRES. The QRMI-Slurm integration assumes that a GRES quantum resource is always available. If a job requires both quantum and HPC resources, the Slurm scheduler will assume that quantum resource is available, reserve the HPC resources (for example, GPU nodes), and submit the job. If the quantum resource is not available, then the HPC resources will remain idle until the quantum resource becomes available. A possible solution (Slurm’s Dynamic License mechanism) is discussed below. Slurm’s Dynamic License mechanism [45], available since Slurm v23.02, can be used to address the availability of dynamic resources. Resources can be configured to require a license before a job may proceed. The scheduler checks license availability during the Schedule state, and if the license cannot be acquired, the job remains pending until it becomes available. Unlike static licenses, Dynamic Licenses allow an external license manager to control the license count at runtime. An example of defining a license sacctmgr is shown in Listing 2. Users add a license requirement to their sbatch invocations as shown in Listing 3. A daemon runs on one node in the cluster, acting as an external license manager. The daemon monitors the quantum resources. When the quantum resource becomes ready to execute jobs, the daemon uses the sacctmgr CLI to decrement the lastconsumed count from 1 to 0, making the license available as shown in Listing 4.

Listing 2: Defining a quantum resource license with sacctmgr sacctmgr add resource name=ibm_kingston \ count=1 \ cluster=<your cluster name> (for example, linux) \ allowed=100 \ type=license sacctmgr -i update resource ibm_kingston set lastconsumed=1 scontrol show license sacctmgr show resource withcluster

Listing 3: sbatch invocation with --licenses option sbatch --licenses=ibm_kingston@slurmdb:1 run_sampler.sh

Listing 4: Updating the quantum resource license consumed count to reflect availability # Quantum resource unavailable: consume the license sacctmgr -i update resource ibm_kingston set lastconsumed=1 # Quantum resource available: release the license sacctmgr -i update resource ibm_kingston set lastconsumed=0

The Slurm scheduler checks the Dynamic License count and, once available, allocates quantum and HPC resources together and transitions the job to the Execute state. Because the daemon uses polling, this approach suffers from a race condition in which the license count does not match the actual status. The Slurm integration served as a proof-of-concept. We then applied design patterns used for the QRMI-Slurm integration to other workload managers to understand if the design patterns would hold across a variety of workload managers. B. PBS Integration The PBS integration can only be understood within the context of the PBS daemons that drive job scheduling and lifecycle management. There are three daemons: (1) a central server daemon (PBS server or pbs_server), (2) a scheduler daemon (PBS scheduler or pbs_sched), and (3) per-node execution daemons that typically run on separate hosts (MoM or Machine Oriented Mini-server or pbs_mom). The roles of these daemons are explained below within the context of the design patterns below. Treat quantum resources as a schedulable resource: PBS requires two steps for this design pattern: (1) define the custom resource with qmgr and (2) make the scheduler aware of it [25]. qmgr is the PBS administrator command-line interface. It sends management directives to the PBS server, such as creating queues, setting server or queue attributes, defining custom resources, and configuring nodes/vnodes. An example of defining a quantum resource with qmgr is shown in Listing 5. To make the PBS scheduler aware of the quantum resource, the resource must be added to the scheduler’s resources list in PBS_HOME/sched_priv/sched_config as shown in Listing 6. Listing 5: Defining a quantum resource with qmgr qmgr -c "create resource ibm_kingston type=long, flag=nh" qmgr -c "set node node001 resources_available.ibm_kobe=1"

Listing 6: Scheduler resources resources: "ncpus, mem, arch, host, vnode, aoe, eoe, ibm_kobe"

PBS supports the dynamic availability of quantum resources through dynamic resources (server_dyn_res). A new dynamic resource can be defined in PBS_HOME/sched_priv/sched_config along with a script that is run at each scheduling cycle to report the availability of the resource. Use thin integration layers for lifecycle management: PBS supports lifecycles customization through hooks that run in different daemons. A runjob hook performs the acquire step by resolving requested quantum resources through qrmi_config.json, injecting provider-specific environment variables, checking quantum resource accessibility, calling QRMI acquisition APIs, and storing acquisition tokens in the PBS job environment. Because the runjob hook executes at the PBS server before compute nodes are allocated to the job, an inaccessible quantum resource causes the hook to reject the job, leaving it pending in the queue rather than leaving already-allocated compute resources idle. PBS automatically retries resource acquisition at the next scheduling cycle. The user workload then executes with this QRMI state available through the job’s variable list (job.Variable_List). Finally, an execjob_end hook performs the release step by retrieving the stored resource names, types, and acquisition tokens and invoking QRMI release logic. This design closely mirrors the SPANK-based Slurm integration, replacing SPANK callbacks with PBS hooks, but shifts the acquire step earlier in the job lifecycle, avoiding the idle-resource cost incurred when acquisition is instead attempted during the execution phase. Because the runjob hook runs within the PBS server process while execjob_end runs within the MoM process on the execution host, passing tokens obtained during acquisition requires serializing the data into job.Variable_List, which PBS propagates from the server to the execution host as part of the job’s attributes. Encapsulating complexity into configuration and middleware: Like the Slurm integration, the PBS configuration is through the administrator-managed qrmi_config.json file, located in $PBS_HOME/server_priv for the runjob hook and $PBS_HOME/mom_priv for the execjob_end hook. Alternate design pattern: The design pattern just described requires administrator support when a quantum resource is added or removed. PBS offers an alternate design pattern that allows quantum resources to be accessed without administrator support. An administrator can specify a general quantum_resources in the scheduler’s resources list. quantum_resources is not associated with a host and is considered to be non-schedulable and excluded from scheduler consideration. The value of quantum_resources is carried with the job rather than used for host allocation which allows the runjob hook to acquire the specified quantum resource. In environments where quantum resources change frequently, this design pattern eliminates the need for administrators to reconfigure PBS frequently. Another advantage is

that this approach preserves a submission experience consistent with native PBS resources such as CPU and memory as shown in Listing 7. CPU and memory (native PBS resources) are specified with select=1:ncpus=1:mem=2gb. Quantum resources (custom resources) are specified with quantum_resources="ibm_kingston,ibm_kobe". Of course, this alternate design pattern hides quantum resources from the scheduler. For example, a scheduler could no longer enforce a maximum number of concurrently running jobs per quantum resource. Listing 7: PBS job example #!/bin/bash #PBS -N sampler #PBS -l select=1:ncpus=1:mem=2gb #PBS -l walltime=00:10:00 #PBS -l quantum_resources="ibm_kingston,ibm_kobe" #PBS -j oe #PBS -m bae # Change to the directory where the job was submitted cd $PBS_O_WORKDIR # Your actual commands source ˜/pyenv/bin/activate python3.12 ˜/qrmi/examples/qiskit_primitives/ibm/sampler.py

C. LSF integration The LSF integration [26] is based on prior work [36] that focused on resource discovery. In this paper, the LSF integration is focused on the QRMI integration design patterns described earlier. Treat quantum resources as a schedulable resource: LSF provides a resource definition and resource-requirement model. Administrators can define resources in the Resource section of LSF_ENVDIR/lsf.shared where each resource is assigned a name, type, and optional scheduling attributes as shown in Listing 8. There are two common patterns: static and dynamic resources. For dynamic resources, LSF obtains changing resource values from an External Load Information Manager (ELIM). This can be used for resources whose availability changes independently of the host state, for example, quantum resources. In this case, the resource is defined in LSF_CONFDIR/lsf.shared with an update INTERVAL and an ELIM program reports current values back to LSF. LSF can then use those values for host selection, dispatch decisions, and queuing until the resource becomes available. An example of defining a quantum resource in this way is shown in Listing 8. The quantum resource is mapped to a host. The LSF manager for the host will run the ELIM program every 30 seconds to check the status of ibm_fez. Listing 8: LSF quantum resource configuration. Begin Resource RESOURCENAME TYPE ibm_fez Boolean qpu_ready Numeric End Resource

INTERVAL () 30

DESCRIPTION (IBM QPU name) (QPU availability)

Users can then run jobs as usual with bsub with a specific quantum resource through the QRMI_QPU_RESOURCES environment variable as shown in Listing 9. Listing 10 shows how

users can also run jobs by requesting any ready quantum resources. Listing 9: LSF bsub request for a specific quantum resource. QRMI_QPU_RESOURCES=ibm_fez bsub job.sh

Listing 10: LSF bsub request for any ready quantum resource. bsub -R "select[qpu_ready==1]" job.sh

Use thin integration layers for lifecycle management: LSF provides lifecycle extensibility through hooks, which are sufficient to implement the QRMI acquire-execute-release pattern. In contrast to Slurm’s SPANK plugins, which supports stacking multiple plugins, LSF provides separate lifecycle hooks that can be used to implement the required workflow. The QRMI acquire and execute steps are performed in the jobstarter hook which is a wrapper around job execution. The QRMI release step is run in the postexec hook instead of at the end of the jobstarter wrapper to ensure the release is always performed. Because the jobstarter and postexec hooks run in different processes, the acquisition tokens obtained in the acquire (jobstarter) are stored in a temporary file which the release (postexec) reads. Encapsulating complexity into configuration and middleware: Like the Slurm integration, LSF configuration is through the LSF_ENVDIR/qrmi_config.json file which is administrator-managed. D. Grid Engine and Open Cluster Scheduler Treat quantum resources as a schedulable resource: The Grid Engine family represents site-defined resources through complexes. In the QRMI integration [37], quantum resources are modeled using a combination of resource-selection and resource-capacity complexes. The quantum resource identity is represented by a requestable, non-consumable string complex qpu. Users select a quantum resource using the standard resource request syntax shown in Listing 11. The scheduler dispatches the job only to execution hosts whose complex values advertise the requested quantum resource. Listing 11: Grid Engine quantum resource request. qsub -l qpu=PASQAL_FRESNEL job.sh

A quantum resource request can be decomposed into two components: quantum resource selection and quantitative resource constraints. Quantum resource selection is performed through the qpu string complex. Capacity and availability constraints are represented using numeric complexes. Because consumable complexes must use numeric resource types and the <= relation, the qpu complex itself cannot be consumable. Instead, consumables such as qpu_slots are used to represent the amount of quantum resource capacity requested by a job, while numeric state indicators such as qpu_ready can be used to express availability requirements. The scheduler can obtain these dynamic resource values through Load Sensors, which provide functionality similar to the LSF ELIM described in Section IV-C. A Load Sensor is

executed by the Grid Engine execution daemon and periodically reports site-defined resource values. The integration uses a Load Sensor to query the quantum resource provider and publish availability information to the scheduler, in a way which should be compatible with other Grid Engine distribututions. For example, Pasqal’s on-premise environment uses Warden [38], which reports whether a quantum resource is accessible and how many slots are available for internal scheduling as outlined in [8]. The Load Sensor exposes these values through the qpu_ready and qpu_slots complexes. A job can combine quantum resource selection and quantitative constraints in a single resource request, as shown in Listing 12. Grid Engine treats the comma-separated request as a conjunction, so the job is dispatched only when the selected quantum resource is advertised by the host and the requested capacity and readiness constraints are satisfied. Listing 12: Grid Engine request with constraints. qsub -l qpu=PASQAL_FRESNEL,qpu_ready=1,qpu_slots=6 job.sh

Use thin integration layers for lifecycle management: Lifecycle integration is implemented with queue prolog and epilog hooks. The prolog reads the quantum resource granted by Grid Engine, uses that name to select the corresponding QRMI definition, and invokes QRMI accessibility and acquisition operations. It then publishes the QRMI runtime metadata required by the job. The epilog reads the acquisition metadata, releases the QRMI resource, and writes QRMI accounting fields into the job usage data, making them available through standard tools such as qacct and third-party accounting and monitoring integrations. Encapsulating complexity into configuration and middleware: The Grid Engine integration separates scheduler configuration from provider-specific QRMI configuration. The administrator-managed qrmi_config.json file maps logical quantum resource names to QRMI resource types and their environment. The Grid Engine qconf command is used to configure the qpu, qpu_slots, and optional qpu_ready complexes, assign logical quantum resource names to execution hosts, and install the queue hooks and Load Sensors. At dispatch time, the prolog reads the granted quantum resource name from Grid Engine’s job resource state and uses it to select the matching entry in qrmi_config.json. QRMI then handles provider-specific authentication, session management, accessibility checks, acquisition, and release, leaving application code independent of the provider API. E. Kubernetes Operator Integration Because Kubernetes (k8s) is structured quite differently than traditional workload managers, the description of the k8s integration does not strictly follow the design patterns. However, the resulting k8s integration described here can support quantum–HPC workloads and demonstrates the flexibility of k8s and QRMI [39].

The k8s integration exposes quantum resources as schedulable resources via a combination of two custom k8s API resources. The first is the QuantumResource (QR), which created by a cluster administrator and configures access to a particular quantum resource. The second is the QuantumResoureClaim (QRC), which represents a request for access to a particular QR. Valid QRCs create a k8s Secret to be consumed by a workload. The Secret contains data which provides access to the requested quantum resource. Listing 13: k8 QuantumResource CRD definition. apiVersion: quantum.qrmi.io/v1alpha1 kind: QuantumResource metadata: name: example-qr spec: resourceType: alice-bob-felis resourceId: ab_emu_1q_lescanne_2020 envVars: QRMI_AB_FELIS_BASE_ENDPOINT: "https://example-quantumapi.alice-bob.com" secretRefs: - secretName: alice-bob-felis-credentials secretKey: api-key envVarName: QRMI_AB_FELIS_API_KEY --apiVersion: quantum.qrmi.io/v1alpha1 kind: QuantumResourceClaim metadata: name: example-qrc spec: quantumResource: example-qr ttl: 3600

There are two main advantages of the claim model. First, claims are resources in the k8s API server which gives them visibility to k8s API clients such as kubectl. The second advantage is in extensibility because a QRC itself is not tied to any particular workload type. These advantages provide users with more control over quantum-HPC workloads. However, a QRC could outlive the workload it was created for which could lead to unnecessary quantum resource acquisition time because the QRC is responsible for both the quantum resource acquire and release. A QRC that outlives the workload delays the release unnecessarily. The simple time-to-live parameter on QRCs is a preliminary mitigation. A more complete mitigation is the addition of Jobs annotations to support QRC. The operator creates a QRC from the annotations which allows the operator to associate the QRC with a particular job and enables the automatic cleanup of QRCs when the job is deleted or when the job finishes, whichever happens first. The association of QRC and Job prevents a possible race condition where the Job could start before the QRC is bound. The operator simply suspends all jobs with unbound claims. The design adheres to the k8s-native approach of representing the problem-space ontology as k8s API resources via means of CustomResourceDefinitions (CRDs) which are implemented by an operator which itself runs as a workload in the cluster and captures all the logistical complexity. The QuantumResource CRD can be seen as equivalent to a resource block in qrmi_config.json from the Slurm integration. The design aims to adhere to established k8s design patterns and

conventions, in particular, in the implementation of a claimstyle resource in the style of storage.k8s.io, in the use of resource annotations, and in the use of finalizers for cleanup. Note that this prototype contains no modification of the k8s scheduler itself. The only modification to scheduling logic leverages a feature particular to Jobs, allowing them to be suspended until claims are ready. This decision would likely be revisited in a more complete implementation should there be a desire to support tighter integration with a wider variety of workload types or to support more complex co-scheduling of resources. F. Flux Framework Integration The Flux Framework integration has focused on the challenges of scheduling hybrid quantum-HPC workloads. This section describes the current state and the next steps needed for complete integration. To treat quantum resources as a schedulable resource, quantum resources are modeled in the Fluxion resource graph (Figure 2). While other workload managers consider quantum resources as job features, Flux models quantum devices as full-fledged hardware in the resource graph, on equivalent footing with HPC compute. When a user requests a job, they can request quantum and HPC resources. A job request can be represented as a resource “shape” that must be matched within the graph. Fluxion performs a depth-first search across both resources and time, returning a match when sufficient resources are available. Different match policies determine how matches are searched and scored, and how nodes are pruned from the graph. When a match is found for quantum and HPC resources, the resources are allocated for the duration of the job. The modular design of the Flux Framework allows the scheduler to be integrated with other workload managers, or the Flux workload manager to use other schedulers. To avoid the complexity of modifying the Flux core modules, integration experiments were run using Kubernetes as a workload manager. A Kubernetes custom scheduler plugin, Fluence, based on the Flux scheduler was developed from previous work [14] [15] [16] to model quantum and HPC resources in the resource graph [29]. Integration experiments enabled study of the two-queue problem which we describe briefly here and will be described in more detail in upcoming work [2]. The two-queue problem is the coordination of jobs in two queues, where one queue (quantum) does not provide transparency to running times. Given that HPC workload resources should execute at the same time as quantum, it becomes problematic if a quantum submission has an unknown waiting time. A conservative approach is to start HPC resources and incur the cost of keeping them idle while waiting for quantum resources. The Fluence approach is to monitor the quantum queue depth and dispatch classical resources when the quantum work is about to run. Quantum resources are modeled in the resource graphs as allocatable quotas. When a resource match is found, Fluence schedules a gang of N pods. Using a producer and consumer model, Fluence then

gates N-1 workers in a group, allowing a single worker to act as a producer to submit to the quantum queue with a backend like QRMI or Amazon Web Services (AWS) Braket. This design does not put any credentials in the system space. They are owned by and scoped to the application user. Fluence automatically deploys a sidecar to the application that retrieves task identifiers, and monitors the queue depth, un-gating other worker pods when the quantum work is about to be executed. This model eliminates HPC resource idle time. When the work is finished, the quantum and HPC resources are freed in the resource graph. A kubectl plugin can be used to modify submission manifests according to assessments using local credentials and state [28]. The next integration step will be moving quantum resources to the Flux resource graph and the Flux Core [32]. The Flux Core will provide traditional plugins for lifecycle management and provide users with a rich set of tools. An early prototype integration [27] that served as a learning example focused on using Flux shell plugins, and other plugin types will be used for a more holistic integration. While the Flux Framework is expected to support the “use thin integration layers for lifecycle management” and “encapsulate complexity into configuration and middleware” design patterns (Table II), this will only be declared when the integration is complete. G. Other Integration Considerations The previous sections describe how workload managers address the three key design patterns: (1) treat quantum resources as a schedulable resource, (2) use thin integration layers for lifecycle management, and (3) encapsulate complexity into configuration and middleware. Of course, the design patterns do not address all the integration considerations. Table III summarizes remaining considerations. Each row of Table III is described below. Note that the Flux Framework is not included in Table III because of its incomplete integration. Implementation language: Extending workload manager functionality requires different language bindings for extension code. QRMI provides multiple language bindings, including Rust, C, and Python. Deployment: Workload managers have different methods to distribute extension code across nodes. Some require extension code to be distributed and installed manually. Others provide support for distribution. Execution location: Workload managers organize processes differently, which determines where extension code is executed. Job information access: How extensions will access job information. Job rejection and modification: How extensions will handle job rejection and modification. Environment variable passing: How extensions can access, modify, and add environment variables to a job. Custom resource integration: How new resources, such as quantum resources, can be added to the workload manager.

Fig. 2: A depth-first quantum resource match using the Fluxion resource graph.

Quantum resource availability: Because quantum resources are typically shared between many users, submitting a job does not mean it will actually run in the near future. A workload manager must understand when a quantum resource is available or when a submitted job will actually run. Logging and debugging: Where do extensions output information. Code update: How are extensions updated. QHPC user experience: How do users run quantum-HPC workloads. V. A NALYSIS AND L ESSONS L EARNED This section discusses the support for design patterns across the workload managers examined in Section IV, credentials management, and lessons learned at QRMI deployments. A. Support for Design Patterns In Section IV, we described how the workload managers support the QRMI design patterns that address the quantum integration challenges. Table II summarizes the differences between the traditional workload managers: Slurm, PBS, LSF, and Grid Engine. Kubernetes and the Flux Framework are not included. Full support of the first design pattern (treat quantum resources as schedulable resources) requires the ability to define new custom resources such as quantum resources and the ability to track the dynamic availability of quantum resources. While all the workload managers allow new custom resources to be defined, they all have limitations tracking the dynamic availability of quantum resources. Due to these limitations, they are all assigned partial support. Slurm (specifically, GRES) cannot reflect the dynamic availability of quantum resources, hence, the special symbol (≈∗∗ )

Integration Challenge

Slurm

PBS

LSF

Grid Engine

Treat quantum resources as schedulable resources Use thin integration layers for lifecycle management Encapsulate complexity into configuration and middleware Native quantum resource support Overall

≈∗∗

≈

≈

≈

✓

✓

✓

✓

✓

✓

✓

✓

×

×

×

×

≈

≈

≈

≈

TABLE II: Workload manager support for design patterns. ✓ is full support, ≈ is partial support, and × is no support.

in Table II. Slurm introduced Hierarchical Resources (HRES) in version 25.05 (May 2025) [46]. HRES allows for licenselike resources to be defined and associated with specific nodes. Jobs may request any integer count of that resource. If license counts could be dynamically adjusted to reflect quantum resource availability, Slurm HRES could represent quantum resources without the need for an external daemon. At present, however, this functionality is not supported. While PBS, LSF, and Grid Engine can reflect the dynamic availability of quantum resources, there are still concerns about race conditions and scalability that must be carefully explored. PBS does this through dynamic resources (server_dyn_res), which invoke an administrator-supplied script at each scheduling cycle to report a resource’s current value. LSF does this through ELIMs which can be run periodically, updating the availability of dynamic resources. Grid Engine does this through Load Sensors scripts. Although Flux is not included in Table II because its QRMI integration remains incomplete, the Fluxion approach described in Section IV-F offers

an alternative mechanism for representing dynamic resource availability. The Fluxion approach is to monitor the length of the queue that contains quantum jobs. While the queue length of quantum jobs can be misleading, this is a practical solution absent additional information about the dynamic availability of quantum resources. It is worth noting that the PBS approach to dynamic availability is different than the polling approach of LSF and Grid Engine. The PBS approach allows quantum resource availability to be checked in two places: (1) administratorsupplied script at each scheduling cycle for dynamic resources and (2) the runjob hook. The runjob hook is a viable alternative because it is executed at the PBS server before any other resources are allocated. An inaccessible quantum resource causes the hook to reject the job, leaving it pending in the queue rather than leaving other resources idle. These approaches are complementary. The dynamic resources script can filter out jobs before invoking the runjob hook which could be important as the number of concurrently pending jobs for the same quantum resource grows. While it is important for workload managers to reflect the dynamic availability of quantum resources, it is also important that QRMI supports a vendor-agnostic method to reflect availability. QRMI has is_accessible() as a quantum resource method, but this method does not reflect availability. The QRMI community is considering adding a is_runnable() method. The intent of is_runnable() would be to provide a time estimate for when a quantum job can expect to run. All the workload managers allow lifecycle events to be mapped to QRMI operations through plugins or hooks. However, not all the workload managers enable thin integration layers (plugins or hooks) for lifecycle management. QRMI requires acquisition tokens to be passed between the acquire and release steps. Because the Slurm acquire and release callbacks run in the same process, the acquisition tokens are easily passed between the acquire and release steps. While the PBS acquire and release hooks run in different processes, PBS provides support to pass acquisition tokens through job.Variable_List. In the LSF implementation, the jobstarter and postexec hooks execute as separate processes. As a result, acquisition tokens are persisted to a temporary file by the jobstarter hook during acquire and subsequently read by the postexec hook during release. The two hook types also have different execution environments and logging mechanisms, requiring hook-specific debugging and diagnostics. These implementation details are accommodated within the QRMI acquire-execute-release pattern. “Native quantum resource support” is a product support and maintenance statement. Some HPC data centers cannot incorporate non-product software in their production systems. None of the traditional workload managers have “native quantum resource support” which would exclude them from these HPC data centers. Of course, QRMI itself would be excluded as well. Addressing this requires collaboration between the QRMI community and workload manager producers.

B. Credentials Although QRMI does not prescribe a specific credentialmanagement model, secure handling of authentication data remains a critical deployment consideration. By default QRMI places credentials in qrmi_config.json which is an administrator-owned file and credentials are passed through environment variables. While this is convenient, an adversarial, multi-tenant environment requires more secure management of credentials. For example, the pasqal-local QRMI implementation relies on MUNGE to generate authentication tokens scoped to the cluster. These tokens are decoded to extract a Linux UID which is then used for authorization checks. The Linux user base remains the source of truth for access control. As a result, the hosting site administrators do not need to maintain a separate access database for the onpremise quantum resources and no credentials are needed in qrmi_config.json. C. Deployments QRMI has been deployed at multiple sites, including CINECA [48], BasQ (Basque Quantum) [49], RPI (Rensselaer Polytechnic Institute) [50], and the United Kingdom’s HPC ecosystem [57] [58]. CINECA is using QRMI with the Slurm SPANK plugin integration to integrate the Pasqal quantum resource ”Sol” with its production, EuroHPC Tier-0 system Leonardo. BasQ and RPI use QRMI with the Slurm SPANK plugin integration to integrate IBM quantum systems with existing HPC computing infrastructure. BasQ integrated an IBM Quantum System Two with a network of Basque research centers. RPI integrated an IBM Quantum System One with its AIMOS supercomputer. QRMI’s ability to access both cloud and on-premise quantum resources allowed CINECA to begin integration work even before the quantum resource was available. The CINECA deployment also illustrates the need for middleware beyond the workload manager, for example, by optimizing quantum resource usage with a second-level scheduler [9], that is integrated with the system scheduler [8]. This further reinforces the value of QRMI’s lightweight, middleware-centric design. Integrating QRMI with a large production HPC such as the Leonardo, also surfaced other minor features to improve within the QRMI, such as ensuring that the logs were correctly logged to the admin-defined Slurm logs, security, and setup of the integration in a situation where there are many stakeholders, such as the system administrators, HPC-QC, and the vendor. The RPI integration uncovered the quantum-HPC coscheduling problem. AIMOS supercomputer GPUs were left idle for long periods of time due to hybrid quantum-HPC workloads getting allocated to GPUs while waiting for a quantum resource. One possible solution is to split quantumHPC workloads into separate quantum and HPC jobs as suggested in [7]. However, this requires users to change how they behave. As discussed previously, there are multiple ways to address the quantum-HPC co-scheduling problem without requiring users to change their behavior.

Within the United Kingdom’s HPC ecosystem, QRMI has been deployed on development test nodes of the Mary Coombs supercomputer at the STFC Hartree Centre, where it is currently evaluated using cloud-accessible quantum resources. This environment supports the implementation and validation of new features, assessment of scalability, development of tests for early software versions, and investigation of prospective capabilities, including improved accounting support and expanded unit-test coverage. In parallel, the UK National Quantum Computing Centre (NQCC) is undertaking a preliminary integration of its API into QRMI to enable access to compatible quantum systems, including on-premises testbeds and cloud-accessible resources that expose the supported interfaces of QRMI. This API integration establishes the technical foundation for subsequent deployment across NQCC infrastructure, and extended evaluation of different quantum systems within a QCSC context.

Workflow managers: Integrating QRMI with workflow managers such as Airflow [41], Prefect [42], Nextflow [43], and Snakemake [44] is a key step toward scalable orchestration of hybrid quantum-HPC workloads. As quantum resources become part of larger scientific workflows, workflow managers require a consistent and reliable interface for interacting with diverse quantum resources. QRMI can provide this interface through direct integration with workflow managers or through workload managers integrated with QRMI as shown in Figure 3.

VI. F UTURE W ORK Future work includes evolving the QRMI interface, refining current integrations, integration of QRMI resource discovery and accounting information, integration with workflow managers, and quantitative analysis of integrations. Evolving the QRMI interface: The QRMI community is working with the openQSE and QDMI communities to understand HPC data center requirements. While QRMI has been successful in integrating quantum resources in HPC data centers, quantum technologies are rapidly evolving and the QRMI interface must evolve with them. The possible addition of is_runnable() as discussed in Section V is an example. Refining current integrations: Many of the integrations presented in this paper remain at the proof-of-concept stage. The QRMI community had limited contact with the workload manager developers. The QRMI community intends to collaborate more closely with workload manager developers to refine the current integrations and to eventually see native support for quantum resources in workload managers. Refining current integrations also includes credentials management. Resource discovery and accounting information: While it is possible to implement resource discovery and accounting at the workload-manager level, QRMI offers the possibility of providing these services consistently across workload managers. Resource discovery is challenging because quantum technologies expose different capabilities, while schedulers use different resource models and selection mechanisms. Current prototypes use metadata to represent these properties; future work will define simple, compact abstractions that can be mapped to scheduler-specific models. Reliable accounting integration is also essential because HPC facilities use different accounting systems. QRMI therefore requires technologyaware abstractions that represent quantum usage consistently across cloud and on-premises resources. These abstractions can also associate usage records with authenticated users, projects, and allocations, enabling auditable HPC accounting without exposing provider-specific credentials.

Fig. 3: Workflow manager integration with QRMI and a workload manager. Quantitative analysis: The analysis presented in this paper is qualitative. While this is valuable because it helps the larger community understand the challenges of integrating quantum resources into HPC data centers, a quantitative analysis would tell the larger community more. VII. C ONCLUSIONS This paper examined QRMI across a diverse set of workload managers, including Slurm, PBS, LSF, Grid Engine, Kubernetes, and the Flux Framework. We identified three common integration patterns: (1) representing quantum resources as schedulable resources, (2) mapping workload-manager lifecycle events to QRMI acquire-execute-release operations, and (3) encapsulating provider-specific complexity within middleware and administrator-managed configuration. The examination demonstrates that QRMI provides a portable and vendoragnostic abstraction that can be integrated into substantially different scheduling and orchestration environments without requiring invasive modifications. Our examination also highlights limitations of current workload managers when applied to quantum resources. While all evaluated systems provide mechanisms for extending scheduling and lifecycle management, support for dynamic quantum resource availability varies. Challenges such as providermanaged queues, calibration downtime, opaque execution latencies, and quantum-HPC co-scheduling can reduce overall system utilization if not addressed through additional scheduling logic or resource-awareness mechanisms. These findings suggest that future workload managers and orchestration systems will require stronger support for dynamic and heterogeneous resources than is typically needed in current HPC environments. Overall, the examination supports the use of QRMI as a practical foundation for integrating heterogeneous quantum

resources into emerging Quantum-Centric Supercomputing (QCSC) platforms. Beyond validating QRMI across multiple workload managers, this work identifies reusable integration patterns, deployment considerations, and scheduling challenges that can inform future standardization efforts within the QRMI, QDMI, openQSE, and broader quantum-HPC communities. Continued collaboration among hardware vendors, middleware developers, scheduler maintainers, and HPC data centers will be essential for evolving these proof-of-concept integrations into production-ready quantum-HPC ecosystems. ACKNOWLEDGEMENTS The authors would like to thank Leonardo Torretta (Siemens) for insightful discussions that shaped the design of the PBS integration work, Stefano Mensa and Zohim Chandani (NVIDIA) for fruitful discussions, and Edoardo Altamura (NQCC) for editing. This work was performed under the auspices of the U.S. Department of Energy by Lawrence Livermore National Laboratory under Contract DE-AC52-07NA27344 (LLNL-JRNLXXXXXX). This manuscript has been authored by Lawrence Livermore National Security, LLC under Contract No. DE-AC52-07NA2 7344 with the US. Department of Energy. The United States Government retains, and the publisher, by accepting the article for publication, acknowledges that the United States Government retains a non-exclusive, paid-up, irrevocable, worldwide license to publish or reproduce the published form of this manuscript, or allow others to do so, for United States Government purposes. This work was supported by the Hartree National Centre for Digital Innovation, a collaboration between the Science and Technology Facilities Council and IBM. The authors used AI-assisted tools, specifically, ChatGPT 5.5, Codex 5.6, and IBM Bob, during the preparation of this work to support tasks such as grammar checking, literature summarization, and text drafting. All AI-generated content was reviewed, edited, and verified by the authors. The authors take full responsibility for the accuracy, integrity, and originality of the submitted work. AI tools were not used for analysis or the drawing of conclusions.

Slurm

PBS

LSF

Grid Engine

Kubernetes Operator

Implementation language

C (shared library .so)

Python (script)

Programming language agnostic

Programming language agnostic. Golang is preferred.

Rust

Deployment

Compiled .so distributed to each node manually

Registered via qmgr; server distributes automatically

jobstarter and postexec LSF extensions/plug-ins registered in lsb.queues; placed in LSF_SERVERDIR

Deploy queue hooks binaries then configure complex entries via qconf

Operator that contains 2 custom resources: QuantumResource (for execute) and QuantumResourceClaim (for acquire-release)

Execution location

slurmctld (controller) or slurmd (compute node), depending on context

PBS Server or MOM (compute node), selected per hook type

jobstarter and postexec run on (first) execution host

Queue prolog and epilog execute on the execution host; scheduling logic on master node

Claim processed on service node; execution occurs on worker node

Job information access

SPANK API, for example, spank_get_item to read C structs

pbs.event().job object — attributes readable and writable directly

Parameter file and environment variables for submission hooks and execution hooks

Environment variables and command-line arguments provided by the execution daemon (sge_execd)

NA

Job rejection and modification

[Limited] Return an error code to abort; modifying attributes is difficult

[Flexible] event.reject() and attribute rewriting are straightforward

Job error codes are returned in case of a jobstarter or postexec failure

Job Submission Verifier (JSV) framework can reject and modify job parameters and environment

NA

Environment variable passing

spank_{set,get}env for direct manipulation

Via job.Variable_List; accessible as PBS_VAR inside the job script

Environment variables accessible in hooks

Environment variables accessible in hooks

“Inline” or sourced from Kubernetes Secrets

Custom resource integration

Add SPANK options to sbatch and combine with GRES

Define custom resources via qmgr; specify in select or -l; read inside the hook

Add resource in the Resource section of lsf.shared

Resource ID and consumption separated; defined as STRING complexes

Defined through custom operator

Quantum resource availability

Use licenses to represent availability; add external daemon to update license count

Use licenses to represent availability; add external daemon to update license count‡

Extend LIM (Load Information Manager) via ELIM hooks to update availability

Use Load Sensors scripts to update availability

Use sidecar containers to update availability‡

Logging and debugging

slurm_info, slurm_error → slurmd log

pbs.logmsg() → PBS server log (configurable log level)

jobstarter can write to stdout,stderr,file; postexec limited to file

Hook status exposed through job environment variables

NA

Code update

C source must be rebuilt and redeployed on every change

Re-register the updated Python script with qmgr

Redeploy scripts/binaries in LSF_SERVERDIR

Rebuild and redeploy hooks

Load updated container

QHPC user experience

sbatch --gres=qpu:1 --qpu=ibm_fez job.sh

QRMI_QPU_RES=ibm_fez qsub job.sh

QRMI_QPU_RES=ibm_fez bsub job.sh

qsub -l qpu=ibm_fez job.sh

kubectl apply -f job.yaml

TABLE III: Summary of integration considerations. Note 1: The environment variable QRMI_QPU_RESOURCES has been shortened to QRMI_QPU_RES to fit in the table. Note 2: ‡ indicates not implemented.

R EFERENCES [1] U. Bacher, M. Birmingham, C. D. Carothers, A. Damin, C. D. Gonzalez Calaza, A. K. Karnad, S. Mensa, M. Moreau, A. Nober, M. Ohtani, M. Rossmannek, P. Rubin, M. E. Sahin, O. Wallis, A. Shehata, I. Sitdikov, and A. Wennersteen, “Quantum Resources in Resource Management Systems,” arXiv:2506.10052, 2025. Available: https://ar xiv.org/abs/2506.10052. [2] V. Sochat and D. Milroy, “Hybrid Quantum and Classical Workload Management with Graph-based Scheduling,” arXiv:2607.09151, 2026. Available: https://arxiv.org/abs/2607.09151. [3] S. Seelam, J. M. Chow, A. Córcoles, S. Sheldon, T. Mittal, A. Kandala, S. Dague, I. Hincks, H. Horii, B. Johnson, M. Le, H. Jamjoom, and J. M. Gambetta, “Reference Architecture of a Quantum-Centric Supercomputer,” arXiv:2603.10970, 2026. Available: https://arxiv.or g/abs/2603.10970. [4] A. Shehata, B. Austin, T. Beck, L. Burgholzer, A. Chernoguzov, S. Churchill, A. Delgado, Y. Eckert, J. Heckey, K. Kissell, K. Klymko, J. Moles, T. Naughton, L. J. O’Riordan, C. Ortiz Pauyac, G. Prawiroatmodjo, E. Rrapaj, J. Schindler, L. Schulz, S. Stern, T. Takeshita, M. Tsuji, A. Wennersteen, T. Humble, and M. Schulz, “Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey,” arXiv:2604.20912, 2026. Available: https://arxiv.org/abs/2604.20912. [5] L. Burgholzer, M. Walter, P. Hopf, Á. Caride-Tabarés Sánchez, T. Mattsson, B. Hoffmann, N. Färkkilä, D. Bulmash, R. Wille, and E. Mansfield, “Practical HPCQC Integration with QDMI: A Real-Hardware Case Study with IQM Systems,” arXiv:2604.19869, 2026. Available: https://arxiv.org/abs/2604.19869 [6] R. Wille, L. Schmid, Y. Stade, J. Echavarria, M. Schulz, L. Schulz, and L. Burgholzer, “QDMI – Quantum Device Management Interface: Hardware-Software Interface for the Munich Quantum Software Stack,” IEEE International Conference on Quantum Computing and Engineering (QCE), 2024. Available: https://doi.org/10.1109/QCE60285.2024.10 411. [7] A. Esposito and U.-U. Haus, “SLURM Heterogeneous Jobs for Hybrid Classical-Quantum Workflows,” arXiv:2506.03846, 2025. Available: ht tps://arxiv.org/abs/2506.03846. [8] A. Wennersteen, M. Moreau, A. Nober, M. Beji, “Towards a user-centric HPC-QC environment,” Proceedings of the SC ’25 Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis, pp. 1879-1887, 2025. Available: https://dl.acm.o rg/doi/full/10.1145/3731599.3767549. [9] P. Viviani, R. Rocco, M. Barbieri, G. Bettonte, E. Boella, and M. Cipollini, “Assessing the Elephant in the Room in Scheduling for Current Hybrid HPC-QC Clusters,” 55th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSN-W), 2025. Available: https://doi.org/10.1109/DSN-W65791.20 25.00059. [10] J. Cacheiro, Á. C. Sánchez, R. Rundle, G. B. Long, G. Dold, J. Friel, and A. Gómez, “QMIO: A Tightly Integrated Hybrid HPCQC System,” arXiv:2505.19267, 2025. Available: https://arxiv.org/abs/2505.19267 [11] P. Mantha, F. J. Kiwit, N. Saurabh, S. Jha, and A. Luckow, “PilotQuantum: A Middleware for Quantum-HPC Resource, Workload and Task Management,” 2025 IEEE 25th International Symposium on Cluster, Cloud and Internet Computing (CCGrid), pp. 1–10, 2025. Available: https://doi.org/10.1109/CCGRID64434.2025.00070. [12] V. Stirbu, O. Kinanen, M. Haghparast, and T. Mikkonen, “Qubernetes: Towards a Unified Cloud-Native Execution Platform for Hybrid Classic-Quantum Computing,” Information and Software Technology, vol. 175:107529, 2024. Available: https://doi.org/10.1016/j.infsof.2 024.107529. [13] M. Tejedor, M. Grossi, C. Tüysüz, R. Rocha, and S. Vallecorsa, “Kubernetes-Orchestrated Hybrid Quantum–Classical Workflows,” arXiv:2603.24206, 2026. Available: https://arxiv.org/abs/2603.2 4206. [14] C. Misale, M. Drocco, D. Milroy, C. Gutierrez, S. Herbein, D. Ahn, and Y. Park, “It’s a Scheduling Affair: GROMACS in the Cloud with the KubeFlux Scheduler,” 3rd International Workshop on Containers and New Orchestration Paradigms for Isolated Environments in HPC (CANOPIE-HPC), pp. 10–16, 2021. Available: https://doi.org/10.1109/ CANOPIEHPC54579.2021.00006. [15] C. Misale, D. Milroy, C. Gutierrez, M. Drocco, S. Herbein, D. Ahn, Z. Kaiser, and Y. Park, “Towards Standard Kubernetes Scheduling Interfaces for Converged Computing,” Driving Scientific and Engi-

neering Discoveries Through the Integration of Experiment, Big Data, and Modeling and Simulation, pp. 310–326, 2022. Available: https: //doi.org/10.1007/978-3-030-96498-6 18. [16] D. Milroy, C. Misale, G. Georgakoudis, T. Elengikal, A. Sarkar, M. Drocco, T. Patki, J. Yeom, C. Gutierrez, D. Ahn, and Y. Park, “One Step Closer to Converged Computing: Achieving Scalability with CloudNative HPC,” IEEE/ACM 4th International Workshop on Containers and New Orchestration Paradigms for Isolated Environments in HPC (CANOPIE-HPC), pp. 57–70, 2022. Available: https://doi.org/10.1109/ CANOPIE-HPC56864.2022.00011. [17] M. A. Jette and T. Wickberg, “Architecture of the Slurm Workload Manager,” Job Scheduling Strategies for Parallel Processing (JSSPP), pp. 3– 23, 2023. Available: https://doi.org/10.1007/978-3-031-43943-8 1. [18] B. Nitzberg, J. M. Schopf, and J. P. Jones, “PBS Pro: Grid computing and scheduling attributes,” Grid Resource Management: State of the Art and Future Trends. Kluwer Academic Publishers, pp. 183–190, 2004. Available: https://dl.acm.org/doi/10.5555/976113.976127. [19] S. Zhou, “LSF: Load Sharing in Large-Scale Heterogeneous Distributed Systems,” Proceedings of the Workshop on Cluster Computing, 1992. Available: ftp://ftp.csri.toronto.edu/white-technical-reports/257/lsf.ps.Z. [20] W. Gentzsch, “Sun Grid Engine: towards creating a compute power grid,” Proceedings of the IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid), 2001. Available: https: //doi.org/10.1109/CCGRID.2001.923173. [21] B. Burns, B. Grant, D. Oppenheimer, E. Brewer, and J. Wilkes, “Borg, Omega, and Kubernetes,” Communications of the ACM, vol. 59, no. 5, pp. 70–93, 2016. Available: https://doi.org/10.1145/2890784. [22] D. H. Ahn, J. Garlick, M. Grondona, D. Lipari, B. Springmeyer, and M. Schulz, “Flux: A Next-Generation Resource Management Framework for Large HPC Centers,” 43rd International Conference on Parallel Processing Workshops, 2014. Available: https://doi.org/10.1109/ICPPW. 2014.15 [23] S. Chundury, A. Shehata, T. Naughton III, S. Kim, and I. Suh, “QFw: A Quantum Framework for Large-scale HPC Ecosystems,” arXiv:2509.14470, 2025. Available: https://arxiv.org/abs/2509.14470. [24] Qiskit Community, Slurm SPANK Plugins for QRMI, GitHub repository, 2025. Available: https://github.com/qiskit-community/spank-plugins/. [25] M. Ohtani (IBM), PBS Hooks for QRMI, GitHub repository, 2026. Available: https://github.com/qrmi-community/pbs-integration. [26] Y. Park (IBM), LSF QRMI Integration, GitHub repository, 2026. Available: https://github.com/qrmi-community/lsf-integration. [27] Y. Park (IBM), Flux Shell QRMI Integration, GitHub repository, 2026. Available: https://github.com/qrmi-community/flux-shell-integration. [28] V. Sochat (LLNL), Kubectl Fluence, GitHub repository, 2026. Available: https://github.com/converged-computing/kubectl-fluence. [29] Converged Computing, Fluence Kubernetes Scheduler Plugin, GitHub repository, 2026. Available: https://github.com/converged-computing/f luence. [30] Converged Computing, QRMI Sampler, GitHub repository, 2026. Available: https://github.com/converged-computing/qrmi-sampler. [31] Converged Computing, qrmi-go, GitHub repository, 2026. Available: ht tps://github.com/converged-computing/qrmi-go. [32] Flux Framework, Flux Core, GitHub repository, 2012. Available: https: //github.com/flux-framework/flux-core. [33] Munich Quantum Software Stack, Quantum Device Management Interface (QDMI), GitHub repository, 2023. Available: https://github.com/M unich-Quantum-Software-Stack/QDMI. [34] IQM Finland, QDMI on IQM, GitHub repository, 2026. Available: https: //github.com/iqm-finland/QDMI-on-IQM. [35] M. Ohtani and S. Salaria (IBM), SCA/HPCAsia 2026 Tutorial: QRMI with Prefect, GitHub repository, 2026. Available: https://github.com/q rmi-community/SCA-HPCAsia-2026. [36] Vadim Elisseev (IBM), Quantum Workloads with IBM LSF, GitHub repository. Available: https://github.com/IBM/lsf-quantum. [37] D. Gruber and A. Wennersteen, Grid Engine family QRMI Integration, GitHub repository, 2026. Available: https://github.com/hpc-gridware/qp u-resource/. [38] Pasqal, Warden, GitHub repository, 2025. Available: https://github.com /pasqal-io/warden. [39] J. Machin (Alice & Bob), Kubernetes Operator QRMI Integration, GitHub repository, 2026. Available: https://github.com/qiskit-communi ty/qrmi/tree/proto/k8s-operator. [40] HPC Gridware, Open Cluster Scheduler, GitHub repository, 2024. Available: https://github.com/hpc-gridware/clusterscheduler.

[41] Airflow Community, Airflow, GitHub repository, 2014. Available: https: //github.com/apache/airflow. [42] Prefect Community, Prefect, GitHub repository, 2018. Available: https: //github.com/PrefectHQ/prefect. [43] Nextflow Community, Nextflow, GitHub repository, 2013. Available: ht tps://github.com/nextflow-io/nextflow. [44] Snakemake Community, Snakemake, GitHub repository, 2011. Available: https://github.com/snakemake/snakemake. [45] SchedMD, Dynamic Licenses, Software documentation. Available: https: //slurm.schedmd.com/licenses.html#dynamic licenses. Accessed: 19 Jul 2026. [46] SchedMD, Hierarchical Resource Scheduling (HRES), Software documentation. Available: https://slurm.schedmd.com/hres.html. Accessed: 19 Jul 2026. [47] Converged Computing, Introduction, Converged Computing Community Space. Available: https://converged- computing.org/introduction. Accessed: 19 Jul 2026. [48] Pasqal, “Pasqal Inaugurates Italy’s First Neutral-Atom Quantum Computer, Third Pasqal System in Europe,” Press Release, 11 Jun 2026. Available: https://www.pasqal.com/newsroom/pasqal-inaugurates-italy s-first-neutral-atom-quantum-computer-third-pasqal-system-in-europ e/. Accessed: 19 Jul 2026. [49] Basque Quantum, “The Basque Government Opens the IBM Quantum System Two to Industry and Public Entities to Boost New Innovation and Technology Transfer Projects,” Press Release, 6 Jul 2026. Available: https://www.basquequantum.eus/en/news/basque-government-opens-i bm- quantum- system- two- industry- and- public- entities- boost- new. Accessed: 19 Jul 2026. [50] IBM, “Building Software for Quantum-Centric Supercomputing,” IBM Quantum Blog, 15 Sep 2025. Available: https://www.ibm.com/quantu m/blog/qcsc-software. Accessed: 19 Jul 2026. [51] Siemens (Altair), Altair PBS Professional 2021.1.2 Plugins (Hooks) Guide, Software documentation, 2021. Available: https://2021.help. altair.com/2021.1.2/PBS%20Professional/PBSHooks2021.1.2.pdf. Accessed: 19 Jul 2026. [52] SchedMD, Slurm Workload Manager, Software documentation, version 26.05. Available: https://slurm.schedmd.com. Accessed: 19 Jul 2026. [53] OpenPBS Project, OpenPBS, Software documentation. Available: https: //openpbs.org. Accessed: 19 Jul 2026. [54] IBM, IBM Spectrum LSF Documentation, Software documentation, version 10.1.0. Available: https://www.ibm.com/docs/en/spectrum-lsf. Accessed: 19 Jul 2026. [55] Kubernetes Authors, Kubernetes Documentation, Software documentation. Available: https://kubernetes.io/docs/. Accessed: 19 Jul 2026. [56] Flux Authors, Flux Documentation, Software documentation, 4 Jun 2026. Available: https://flux- framework.readthedocs.io/en/latest/. Accessed: 19 Jul 2026. [57] UK Research and Innovation, “STFC launches powerful new AI supercomputer for industry,” Press Release, 20 Oct 2025. Available: https://www.ukri.org/news/stfc- launches- powerful- new- ai- superco mputer-for-industry/. Accessed: 19 Jul 2026. [58] National Quantum Computing Centre, “Quantum computing testbeds,” Press Release, 5 Feb 2024. Available: https://www.nqcc.ac.uk/quantum -computing-testbeds-in-the-uk/. Accessed: 19 Jul 2026.