High Availability & Workload Portability

A STRATUM VM is placed onto an execution worker for CPU, memory, and the physical capabilities required to run it. Its network identity and durable storage path are represented by the larger STRATUM fabric. That separation allows the Execution Fabric to place a movable workload on another compatible worker without redesigning the datacenter around the destination host.

When STRATUM evaluates another execution host, it checks the capabilities the workload actually requires, including architecture such as x86 / ARM / s390x, available CPU and memory, virtual-machine-manager support, GPU requirements, TPM requirements, site policy, and other placement constraints.

A STRATUM virtual switch port belongs to the STRATUM network model. Through STRATUM Continuum, the distributed network fabric can realize that attachment on participating workers instead of tying the topology to the physical server where a VM happened to start.

When a movable VM is restarted on another eligible worker, STRATUM can recreate its existing network attachment at the new execution location. The topology stays the topology while execution moves underneath it.

This same architecture allows STRATUM networking to extend across datacenters, clouds, labs, and edge environments that participate in the Continuum.

The VM disk remains associated with its STRATUM Storage owner and target while the execution location can change.

The execution worker does not need to own a local copy of the VM disk or mount a shared filesystem containing it.

The destination worker reconnects to the assigned storage path through STRATUM's storage protocol and the Continuum Storage Lane. Compute can move while the durable storage relationship remains stable, making execution workers substantially more interchangeable.

For a movable workload, restart-based recovery follows the same platform relationships STRATUM already knows:

1. STRATUM detects that the current execution location is no longer suitable or available.
2. Execution Fabric identifies workers that satisfy the VM's placement and compatibility requirements.
3. STRATUM selects an eligible execution target.
4. The VM's existing storage target is reconnected from the destination worker.
5. Its STRATUM network interfaces are realized against the existing virtual topology.
6. The VM starts on the new worker.
7. Runtime state and workload health can then be verified.

The current HA model is based on restart and rescheduling on compatible infrastructure. It is designed around rapid workload reconstruction from durable platform state rather than dependence on one physical host.

Some workload state deliberately creates locality. Active snapshots are stored on the current execution host, so a VM with an active snapshot chain remains pinned there and HA placement is unavailable until those snapshots are removed or consolidated.

Direct physical-device passthrough can also constrain placement because a destination must provide the required physical capability. Storage still needs a resilient underlying failure domain; multiple logical storage roles on one physical server remain one physical failure domain.

STRATUM exposes these constraints to placement instead of assuming every workload can run everywhere.

Compute workers, storage workers, distributed networking, remote accelerators, and workload state participate in one operating model. The execution location can change without forcing the mission topology to change with it.

A datacenter can be in a rack, in a cloud, at the edge, on a remote platform, or distributed across geographic locations. STRATUM treats those resources as part of the same Continuum and uses capability and policy to decide where work runs.

Remote and intermittently connected sites may deliberately pin workloads to local compute and storage instead of failing them off-site when communications disappear. Application-level and guest-level HA can still operate within that site where required.