The solution

One platform, one custom component, nothing repackaged. Keep IBM Spectrum Symphony exactly as IBM supports it — full Windows Server compute hosts, RHEL management hosts, the traditional installer, the documented port matrix — and change only the substrate underneath: OpenShift Virtualization on bare-metal workers, reconciled by GitOps, with VM-level elasticity in minutes from a golden image.

The thesis, in three claims

  1. Best-supported modernisation path. Every layer is a supported product — OpenShift, OpenShift Virtualization (GA), OpenShift GitOps, OpenShift Pipelines, Windows Server 2019 (certified OpenShift Virtualization guest since OCP 4.8), Symphony 7.3.2 Advanced Edition on its documented support matrix. Exactly one custom component exists in the whole design: the Host Factory KubeVirt provider — a five-script plug-in interface IBM documents for precisely this purpose, with open-source prior art (FINOS Open Resource Broker, google/symphony-gcp) implementing the identical contract against other substrates. When the grid breaks at 3am there is a vendor to call for every layer but one, and that one is a handful of scripts against a documented interface, not a fork of anything.

  2. Most flexible option for Windows workloads. Full Windows Server VMs mean zero workload-fidelity compromise: Windows services, MSI installers, kernel-level agents — anything Windows Server can run, not just what fits a container image. Golden-image clone-to-join has been measured putting a new compute VM into the Running phase in roughly 2-3 minutes on this build. Dedicated-CPU (d1) instance types give grid-grade CPU isolation. The same golden image, VirtualMachinePool, and GitOps repo runs on any OpenShift with bare-metal workers — self-hosted IPI today, ROSA, a ROKS burst site, or on-prem — a portability statement no cloud-native batch service and no hypervisor-plus-scripts estate can make.

  3. Honest about the trade. The grid pays a virtualization layer and an OpenShift learning curve; Windows Server 2019 is the only supported guest until Advanced Edition BYOL restores Fix Central access (WS2022 needs Fix 601711, unavailable under the eval entitlement); the KEDA-driven demo autoscaler is not grid-aware (no task drain on scale-in — production burst is the Host Factory provider); the custom provider is a genuine multi-person-month build; and a stretched grid pays WAN latency and double cross-cloud egress at scale (Symphony multicluster federation is the documented fallback). Every pro in this design is shown next to its cost.

The supportability spine

Layer Product Support

Cluster

OpenShift 4.20 (self-hosted IPI today; ROSA/ROKS burst variants designed)

Red Hat

Virtualization

OpenShift Virtualization (GA)

Red Hat

Windows guests

Windows Server 2019, certified guest OS since OCP 4.8

Red Hat cert + Microsoft

Image pipeline

OpenShift Pipelines running the windows-efi-installer pipeline

Red Hat platform, upstream KubeVirt community pipeline, adapted in-repo

GitOps

OpenShift GitOps (Argo CD), app-of-apps

Red Hat

Demo autoscale

Custom Metrics Autoscaler (KEDA)

Red Hat

Grid

Symphony 7.3.2 Advanced Edition

IBM

Burst provider

Host Factory KubeVirt provider — the one custom piece

Built in-repo; five-script interface IBM documents; FINOS ORB / Google symphony-gcp prior art

A precision the thesis depends on: the windows-efi-installer pipeline that builds the Windows golden image is not a Red Hat-productized artifact. It is an upstream KubeVirt community example pipeline (kubevirt/kubevirt-tekton-tasks) run on the supported OpenShift Pipelines operator, adapted in-repo (Symphony-specific answer files, MSI staging, firstboot join scripting layered on top). Say "supported platform, community-example pipeline, adapted in-repo" — not "Red Hat productized." This is the one place in the supportability spine that carries community rather than vendor maintenance, and this design says so plainly rather than glossing it. See the golden image page for the detail.

Full topology, network invariants, and burst design: Architecture. Decision record for the keystone choice: ADR 0001.

Status, honestly

  • Windows compute-host join was OPEN at time of writing, fixed in source, not yet confirmed clean end-to-end. Four compounding root causes were found and fixed via a WinRM debug channel and are stated as live-proven on running clones — but whether a separately-recorded WinRM/password blocker on fresh reclones was also closed by that fix is not yet confirmed in a fresh session. Treat this as the one unproven step in an otherwise fully-verified image pipeline.

  • The eval entitlement this build runs on expires 2026-12-31. Production go-live requires Advanced Edition BYOL procurement.

Alternatives: the verdict, and why

Dimensions compared: Windows-workload fidelity, ISV supportability, elasticity, multi-cloud burst, licensing, operational simplicity, cost posture.

Option Fidelity ISV supportability Elasticity Multi-cloud burst

1. This design — OCP Virt + full Windows VMs + HF KubeVirt provider

✅ full Windows Server, unchanged install

✅ exact supported config

✅ VM-minutes on warm metal

✅ same manifests anywhere OpenShift runs

2. Status quo — bare-metal / standalone Windows hosts

✅ that’s where the grid runs today

✅ zero migration risk

❌ static

❌ none

3. Windows containers (WMCO)

❌ cannot run Symphony compute hosts

❌ no supported path exists

N/A

N/A

4. VMware vSphere + Symphony

✅ mature, widely deployed

✅ well-trodden ISV path

⚠️ vMotion, not cloud-elastic

❌ separate silo, no GitOps-native API

5. Cloud-native batch (AWS Batch / Azure Batch / CycleCloud)

⚠️ Azure Batch has real Windows VM fidelity; AWS Batch Windows is Fargate-containers-only

❌ wraps or replaces the scheduler the ISV supports

✅ managed, elastic

❌ single-cloud

6. Lift-and-shift to plain cloud VMs

✅ full VM fidelity on AWS (Host Factory awsprov supports Windows AMI templates)

⚠️ dynamic burst on AWS; static-only guidance elsewhere

⚠️ dynamic on AWS only

❌ IBM Cloud’s ibmcloudgen2 provider is Linux-only — no Windows burst on IBM Cloud

7. Replace the scheduler (K8s batch / Ray / HTCondor rewrite)

✅ cloud-native endgame

❌ loses IBM support entirely

✅ native

✅ native

The one-line case against each: status quo has no burst path without a rewrite; WMCO cannot host Symphony at all (privileged containers, huge pages, and multi-user grid identity all conflict with its documented limitations); vSphere carries the Broadcom licensing volatility this design exits; cloud-native batch is single-cloud and, for AWS Batch, Windows-incapable; lift-and-shift to plain VMs has no Windows burst path on IBM Cloud and no unified control plane; replacing the scheduler forfeits IBM support for a multi-year rewrite.

Verdict. Only option 1 scores on fidelity, supportability, elasticity, and multi-cloud burst simultaneously; every other option sacrifices at least one of those four, and usually the first two — the exact pair that keeps an FSI grid auditable.

Continue to Business outcomes.