ADR 0001 — Windows Compute as Full VMs, Not WMCO

Status: Accepted (D1, keystone) — every other decision in this set assumes it.

Context

Windows compute can run on OpenShift two structurally different ways: the Windows Machine Config Operator (WMCO), which joins Windows machines as cluster nodes running containers; or OpenShift Virtualization, which runs full Windows Server guests as VMs on Linux (RHCOS) nodes. They are not interchangeable.

Red Hat’s own WMCO docs state plainly that on WMCO-managed nodes: privileged containers are not supported, huge pages are not supported, and only Deployment (not DeploymentConfig) workloads are supported [docs.okd.io/latest/windows_containers/wmco_rn/windows-containers-release-notes-limitations.html]. Windows Server Containers under WMCO share the host kernel and are explicitly documented as not intended for hostile multi-tenancy [docs.okd.io/latest/windows_containers/understanding-windows-container-workloads.html]. WMCO’s Bring-Your-Own-Host mode does allow persistent, named Windows instances — so "persistent host" isn’t the blocker — but even a BYOH node still only runs containers, not arbitrary Windows Server software with kernel-level services and multi-user process isolation.

Symphony’s own install model needs exactly that: IBM’s 7.3.2 docs show Windows install via MSI, with LIM registered as a native Windows service under the Service Control Manager, and PEM started automatically by LIM as a child process — never started manually [ibm.com/docs/en/spectrum-symphony/7.3.2?topic=installation-performing-silent-windows-using-msi-packages]. Windows Server (64-bit) is the only supported Windows OS class — client editions are not in the support matrix [ibm.com/docs/en/spectrum-symphony/7.3.2?topic=systems-windows-support]. That is a persistent, host-level, SCM-managed service model, not a container entrypoint process — and the grid’s multi-user job-isolation is precisely the "hostile multi-tenancy" scenario WMCO disclaims.

IBM has also never shipped a Windows container artifact for Symphony. The only container artifact IBM ever published, ibm-spectrum-symphony-operator, is Linux-only, was scoped as a non-production Community Edition PoC, and is now archived (last commit September 2021, targets 7.3.1).

Windows Server 2019 and 2022 are both Red Hat-certified guest operating systems for OpenShift Virtualization via Microsoft’s SVVP program [access.redhat.com/articles/4234591] — this design follows that certified path, and Red Hat’s own reference-architecture line for OpenShift Virtualization treats "full VM" as the first-class pattern for workloads like this.

Decision

Run Symphony Windows compute hosts as full Windows Server VMs on OpenShift Virtualization, cloned from a sysprepped golden image and joined per-VM at boot — not as WMCO-managed Windows container nodes. Linux nodes stay Linux; Windows lives entirely inside VMs. Symphony’s installer, service model, and support matrix are used exactly as IBM ships them. See Windows golden image for the build pipeline this decision requires.

Consequences

Pros

  • Zero workload-fidelity compromise: Symphony installs and runs exactly as IBM documents it — MSI install, LIM as an SCM service, PEM as its child process — nothing adapted to fit a container runtime.

  • Stays inside every constraint WMCO documents as unsupported for this class of workload: privileged operations, kernel-level service management, multi-tenant process isolation.

  • Follows Red Hat’s own certified, blessed pattern for Windows workloads on OpenShift rather than working around a gap in WMCO’s supported feature set.

  • IBM has never shipped, and shows no sign of building, a Windows container artifact for Symphony — there is no supported "wait for IBM" alternative to full VMs.

Cons

  • VM overhead versus containers: a full Windows Server guest (OS licensing, boot time, disk footprint, patching surface) is heavier per compute unit than a container image.

  • The grid now owns a golden-image pipeline (autounattend/sysprep, driver injection, Symphony silent install, per-VM join) as build infrastructure a container image would not require.

  • Windows Server licensing is still this design’s problem to solve, not eliminated by the platform choice — see ADR 0003.

Continue to ADR 0002: Staged minimal footprint.