FULL TECHNICAL REFERENCE.

Build it. Operate it. Know exactly how it works.

The complete STRATUM field guide.

OPEN USER GUIDE BACK TO INTERACTIVE ARCHITECTURE

TECHNICAL INDEX.

STRATUM Documentation

System Reqs Setup Deploy Start K8s Appliances User Guide Administrator Guide DevSecOps Guide stratum-host Helm Details

00 / SYSTEM REQUIREMENTS

System Requirements

STRATUM / SYSTEM REQUIREMENTS

Size the host for STRATUM-and the workloads it will run.

STRATUM requires a 64-bit Linux host with a working container runtime and hardware-assisted virtualization. The platform minimums below cover STRATUM itself; your host must also provide enough CPU, memory, networking, GPU, and storage capacity for all simultaneously running workloads.

01 HostMinimum Requirements Minimum host requirements The operating system, runtime, virtualization, memory, storage, and permissions required to run STRATUM.

Requirement	Minimum or guidance
Operating system	64-bit Linux distribution on `x86_64` or `Arm64`. S390x Linux, Microsoft Windows, and MacOS will be released soon if we have demand for them.
Container runtime	Docker Engine or Podman, installed, configured, and running.
Processor	64-bit CPU with hardware virtualization enabled.
Virtualization access	Linux KVM available to STRATUM through `/dev/kvm`.
Memory	At least 1 GB of available RAM for the STRATUM platform.
Platform storage	At least 10 GB of available storage for STRATUM, excluding workload capacity.
Permissions	Root or equivalent administrative access for installation and host configuration.
Storage media	SSD or NVMe recommended. RAID-backed HDD storage is supported when performance is sufficient. NFS storage is supported, but NFS locking must not be disabled/localized when the same files could be accessed from multiple hosts.

Workload capacity is additional.

The host must also provide sufficient CPU, RAM, network bandwidth, GPU resources, and storage performance for every workload that may run concurrently.

02 ComputeKVM Processor and virtualization Hardware-assisted virtualization must be enabled and exposed to Linux through KVM.

The host processor must support 64-bit operation and hardware-assisted virtualization. Virtualization must be enabled in the system firmware and available to Linux through /dev/kvm.

When STRATUM itself runs inside a virtual machine or cloud instance, the outer platform must expose nested virtualization to that guest.

KVM access is a host requirement.

A container runtime alone is not sufficient. STRATUM must be able to access the Linux KVM device in order to run hardware-accelerated virtual machines.

03 CapacityMemory Plan host memory Add Linux, STRATUM, active workloads, and operational headroom-not just configured guest RAM.

The 1 GB minimum is for the STRATUM platform only. It does not include memory assigned to running virtual machines, virtual switches, routers, firewalls, or other workload components.

Linux host+STRATUM+simultaneous workloads+operational headroom

For example, four virtual machines configured with 4 GB of RAM each require capacity for 16 GB of guest memory, in addition to the memory required by Linux, STRATUM, and normal operating headroom.

Plan for concurrency.

Size memory for the workloads that can run at the same time, not merely the number of templates or systems stored in the environment.

04 CapacityStorage Plan platform and workload storage The 10 GB platform minimum does not include templates, VM disks, snapshots, media, data, or backups.

The 10 GB minimum covers the STRATUM platform only. Budget additional capacity for:

VM templates and imported disk images

Writable virtual-machine disks

Container images and writable layers

Snapshots and checkpoints

ISO images and installation media

Persistent application data

Logs and temporary files

Exports, updates, and backups

A virtual machine created from a STRATUM template does not initially require another complete copy of the template. The template data is shared, while each VM stores its own changes and deltas.

Leave recovery and growth headroom.

As a practical planning baseline, provide roughly twice the storage you expect active VMs and platform data to consume. This leaves room for deltas, snapshots, updates, temporary operations, and unexpected growth.

05 Container RuntimeStorage Path Check the actual container storage filesystem Free space on / does not help when Docker or Podman stores its data on a smaller /var filesystem.

Docker and Podman store downloaded images, container layers, metadata, and logs in the container runtime's storage directory. Common default locations are:

Docker/var/lib/docker

Podman/var/lib/containers/storage

On many Linux systems, /var is a separate and relatively small filesystem. In that layout, the root filesystem may have ample free space while the container storage filesystem becomes full.

Check Docker storage

df -h /var/lib/docker

Check Podman storage

df -h /var/lib/containers/storage

Measure the filesystem that actually holds runtime data.

It must have at least 10 GB available for STRATUM, plus sufficient room for image updates, logs, writable layers, and normal runtime growth.

06 Persistent DataVM Storage Provide capacity for STRATUM persistent storage VM disks and persistent platform data normally live below /persistent, but the location is configurable.

STRATUM's default host location for VM and persistent platform storage is below /persistent. This path can be changed through the stratum-host configuration.

Ensure the selected filesystem has enough capacity for VM disks, templates, snapshots, persistent databases, exports, and expected growth. For larger deployments, place persistent data on a dedicated high-capacity SSD, NVMe device, storage array, or RAID-backed volume.

Separate runtime and workload planning.

The container runtime storage path and STRATUM persistent storage path may reside on different filesystems. Verify and size both.

07 StoragePerformance Match storage performance to the workload Capacity alone is not enough when several active virtual machines generate random I/O.

SSD or NVMe

Strongly recommended for hosts running multiple active virtual machines, frequent snapshots, or I/O-intensive applications.

RAID-backed HDD

Supported when the array provides adequate random I/O performance, resilience, and capacity for the intended workload.

Single HDD

Generally appropriate only for light evaluation, archival use, or workloads with limited disk activity.

Evaluate latency and random I/O.

Large sequential capacity does not guarantee acceptable VM performance. Size storage for the number and behavior of active workloads.

08 KubernetesPersistent Volumes Kubernetes storage requirements Kubernetes deployments require durable PersistentVolume capacity sized for both STRATUM and its workloads.

Kubernetes deployments require ample persistent volume capacity for STRATUM platform data, templates, virtual disks, snapshots, and workload growth.

The detailed PersistentVolume, StorageClass, access-mode, and deployment-specific requirements are included with the STRATUM Helm chart download package.

The same sizing rules still apply.

A PVC changes how storage is presented to STRATUM; it does not remove the need to plan capacity, performance, redundancy, snapshots, and backups.

01 / HOST SETUP

Setup host

Setting up a few things on your Linux host

run ./stratum-host command.
It opens up a console-based menu interface. Scroll to Host Action Status. Tab over to right side. ‘P’ for Plan to see what commands would be used to setup. Also select which GPU and PCI devices to have available to STRATUM (default will automatically load all GPU but in some cases you may want to have more control).
Go to Dashboard, press A to apply host setup.
CTRL-S to save, Q to quit

Command-line capability:
run sudo ./stratum-host apply
Compare the saved desired state with the actual host:
run sudo ./stratum-host status

For automation, the same configuration (/etc/stratum/host.yaml) can be copied to many hosts and used without the menu interface:
run sudo ./stratum-host apply -yes

NOTE: You do not need to use Network Continuum, which is an encrypted virtual network layer, if you are running with Kubernetes that already has a virtual network or you are on a protected LAN. Unless you are using a 3rd party Kubernetes service, then you should keep Continuum for data protection.

The UI is the interactive editor and operator interface; /etc/stratum/host.yaml is the persistent source of truth.

STRATUM Host Manager r005-r001 | /etc/stratum/host.yaml

────────────────────────────┬──────────────────────────────────────────────────────────

Dashboard │ Host Action Status

Runtime │

Certificates │ [x] Container engine ok docker is usable

Network │ [x] Create STRATUM directories warning missing /etc/s…

Workers & GPU │ [x] Persistent data permissions ok persistent da…

Host Setup │ [x] Large-host sysctl warning not applied

Controller Services │ [x] Network sysctl warning not applied

Advanced │ [x] irqbalance ok enabled

• Host Action Status │ [x] fstrim timer ok enabled

PCI & GPU Inventory │ [x] NVMe tuning ok no NVMe devices

Deployment Roles │ ▶ [x] pnet bridge ok pnet0 healthy with…

Help │ [x] pnet NAT ok persistent masquer…

Quit │

│ Selected: pnet bridge

│ Status: ok - pnet0 healthy with uplink ens33

│ IPv4 192.168.1.110/24

│

│ ↑/↓ select | Enter inspect | Space enable/disable | P

│ plan | A apply

│

STRATUM Host Manager r005-r001 | /etc/stratum/host.yaml

Dashboard │ PCI & GPU Inventory

Runtime │

Certificates │ 0000:81:00.0 10de:2331 driver=nvidia group=65

Network │

Workers & GPU │ Selected: 0000:81:00.0

Host Setup │ Class=030200 Driver=nvidia IOMMU=65 BootVGA=false

Controller Services │ 0000:81:00.0 3D controller [0302]: NVIDIA Corporation

Advanced │ GH100 [H100 PCIe] [10de:2331] (rev a1)

Host Action Status │

▶ PCI & GPU Inventory │ Vendor: NVIDIA Model: H100 PCIe VRAM: 80 GB HBM3

Deployment Roles │ Driver: 535.183.01 CUDA: 12.2 MIG: supported

Help │ PCIe: Gen5 x16 NUMA: 0 Serial: 0324519087123

Quit │

│ ↑/↓ select

│

Tab switch pane | ↑↓/j/k navigate | Enter edit/select | Ctrl-S save | Q quit

02 / DEPLOY

Deploy container

Everything STRATUM is deployed as a single container

Simply deploy the container using a container manager such as docker or podman. You can also deploy from a container register server if you have one. This is how STRATUM can deploy and scale to thousands of nodes quickly, using the same mechanism as cloud-scale applications use.
Run sudo ./stratum-host and configure the STRATUM controller certificates (not needed on worker nodes). The default will create self-signed certificates, however you should create valid certificates for production use.

Container-based application deliveries have changed the world already. Now STRATUM lets it change infrastructure too.


$ sudo docker load -i stratum.tar

$ sudo docker images
IMAGE            ID             DISK USAGE   CONTENT SIZE 
stratum:latest   38b731499409         5GB             0B   

$ sudo ./stratum-host
STRATUM Host Manager r005-r001 | /etc/stratum/host.yaml
────────────────────────────┬──────────────────────────────────────────────────────────
  Dashboard                 │ Certificates
  Runtime                   │
• Certificates              │ ▶ Certificate mode             self-signed
  Network                   │ Self-signed is the demo-friendly default. External
  Workers & GPU             │ never overwrites certificate files.
  Host Setup                │   Certificate directory        /etc/stratum/certs
  Controller Services       │   Demo PKCS#12 password        1234
  Advanced                  │   Expiration warning days      30
  Host Action Status        │
  PCI & GPU Inventory       │ Enter edits/cycles the selected value. Left/right cycles
  Deployment Roles          │ booleans and choices.
  Help                      │
  Quit                      │
                            │
                            │
                            │
                            │
                            │
                            │
                            │
Tab switch pane | ↑↓/j/k navigate | Enter edit/select | Ctrl-S save | Q quit

03 / START

Start container

Simple

Run sudo ./stratum-host
Tab over in Dashboard. Press S to start. X to stop.
Workers call home to the Controller and auto-join the STRATUM Continuum mesh which is a secure network overlay on top of your existing network that spans datacenters, clouds, and edge.

Command-line capability:
run sudo ./stratum-host start

STRATUM Host Manager r005-r001 | /etc/stratum/host.yaml
────────────────────────────┬──────────────────────────────────────────────────────────
▶ Dashboard                 │ Dashboard
  Runtime                   │
  Certificates              │ Role:        controller
  Network                   │ Node:        ctrl1.stratum.lab
  Workers & GPU             │ Controller:  ctrl1.stratum.lab
  Host Setup                │ Public UI:   https://ctrl1.stratum.lab:8443/stratum/
  Controller Services       │ Engine:      docker
  Advanced                  │ Container:   running running=true
  Host Action Status        │ Image:       stratum:latest
  PCI & GPU Inventory       │ Network:     ok - pnet0 healthy with uplink ens33
  Deployment Roles          │ Firewall:    warning - UFW missing required rules
  Help                      │ IOMMU:       0 groups
  Quit                      │ GPUs:        0 matching
                            │ Certificate: ok - certificate valid for 728 more days
                            │
                            │ Actions:
                            │   S start   X stop   C reconcile
                            │   P plan    A apply host setup
                            │   V verify  R refresh
                            │
Tab switch pane | ↑↓/j/k navigate | Enter edit/select | Ctrl-S save | Q quit

CLI alternative:
sudo ./stratum-host start

ALT: Kubernetes

Alternative: K8s deploy

STRATUM is a container, deploy it to Kubernetes

Many datacenters are buying and deploying full racks, not indivudual servers these days. They tend to come with Kubernetes to scale out to thousands of nodes. Deploy STRATUM to Kubernetes and scale out your virtualized datacenter massively.

The chart design is simple: the controller uses a one-replica StatefulSet with a Persistent Volume (PVC) and image-based init container; workers use a node-labelled DaemonSet. Kubernetes values generate both the mounted host.yaml and the runtime environment, so there is still one configuration source.

STRATUM / KUBERNETES DEPLOYMENT

Prepare the cluster, then deploy with Helm.

Use Kubernetes 1.25 or newer on a cluster you control. STRATUM runs as privileged, host-networked infrastructure: prepare the nodes first, provide durable controller storage, then let Helm deploy the controller and optional worker fabric.

01 Container ImageRegistry Make the STRATUM image available Publish the STRATUM OCI image to a reachable registry, or preload it on every selected node.

Publish the STRATUM OCI image to the private or enterprise registry used by your cluster. Set image.repository, image.tag or image.digest, and image.pullSecrets as required.

For disconnected clusters, preload the exact image on every controller and worker node and set image.pullPolicy: Never. For production registry deployments, pin a tested release tag or immutable digest rather than relying on a moving tag.

Registry access

Every Kubernetes node that may run STRATUM must be able to resolve, authenticate to, and pull the selected image. The controller initialization container uses the same image.

02 Cluster PreparationNodes & Storage Prepare the Kubernetes nodes and controller storage Helm schedules STRATUM; it does not configure the host kernel, provider network, GPU bindings, or storage platform.

Before scheduling STRATUM, prepare selected nodes with stratum-host, a golden image, MachineConfig, Ansible, or equivalent automation. The default chart expects privileged host access, hostNetwork, hostPID, /dev/kvm, /dev/net/tun, host /sys, and host cgroups.

Prepare pnet0 when VMs need provider/LAN access. Configure IOMMU/VFIO and GPU drivers only on nodes that need those capabilities. Helm does not create or rewrite pnet0, rebind PCI devices, change the management NIC, or apply host firewall policy.

Useful host and storage checks

test -c /dev/kvm && echo KVM-ready
test -c /dev/net/tun && echo TUN-ready
kubectl get storageclass
kubectl get nodes --show-labels

The controller is stateful. By default, controller.persistence.enabled=true creates one ReadWriteOnce PVC starting at 100Gi. Use the cluster default StorageClass, set controller.persistence.storageClass, or supply controller.persistence.existingClaim. Size and performance should reflect VM disks, templates, ISO images, databases, logs, and normal STRATUM state.

Kubernetes does not replace host preparation

The chart deliberately renders Host Setup actions disabled inside the pod. Prepare the host first; use Helm for Kubernetes desired state.

03 KubernetesNamespace Create the STRATUM namespace Create the namespace first and explicitly permit the privileged infrastructure workload.

Create and label the namespace

kubectl create namespace stratum
kubectl label namespace stratum \
  pod-security.kubernetes.io/enforce=privileged \
  pod-security.kubernetes.io/audit=privileged \
  pod-security.kubernetes.io/warn=privileged

Using only helm --create-namespace does not add the required Pod Security labels. On OpenShift, grant the chart ServiceAccount an approved privileged SCC according to your policy.

04 Node PlacementController & Workers Label the controller and worker nodes The chart deploys one controller StatefulSet and, when enabled, a worker DaemonSet.

Label exactly one prepared node for the controller. Label each prepared compute node that should receive the worker DaemonSet.

Current chart placement labels

kubectl label node ctrl1 stratum.io/role=controller
kubectl label node worker001 stratum.io/role=worker
kubectl label node worker002 stratum.io/role=worker

Do not label the controller as a worker

The chart deliberately separates the controller and worker placements because both use host networking and host-level virtualization resources. The controller still has its own local executor and can run workloads without a worker DaemonSet.

The current Helm chart does not deploy a dedicated Kubernetes storage role, so stratum.io/role=storage is not a chart placement label. Dedicated STRATUM Storage is a separate deployment concern.

05 HelmController First Deploy the STRATUM controller Start with the controller, persistent storage, public hostname, and certificate policy.

Set a stable stratum.publicHost that resolves for users and future workers and matches the controller certificate. Keep workers disabled for the first deployment when using the controller-generated self-signed CA.

Minimal controller values

image:
  repository: registry.stratum.local/stratum
  tag: latest

stratum:
  publicHost: ctrl1.stratum.lab

controller:
  enabled: true
  certificates:
    mode: self-signed
  persistence:
    enabled: true
    size: 100Gi

workers:
  enabled: false

Install or upgrade

helm upgrade --install stratum ./stratum \
  --namespace stratum \
  -f values-production.yaml

Replace ./stratum with the chart directory or packaged chart delivered with your STRATUM release. For production, pin the image tag or digest and select an appropriate StorageClass/capacity.

06 WorkersEnrollment Add remote worker nodes Create the enrollment Secret after the controller is available, then enable the worker DaemonSet.

Remote workers use STRATUM Connect for identity/enrollment and maintain an authenticated outbound HTTPS execution channel to the controller. The chart requires stratum.connect.enabled=true and a worker enrollment Secret whenever workers.enabled=true.

Generate or download the enrollment token and controller CA from the running STRATUM controller, then create the Kubernetes Secret:

Create worker enrollment Secret

kubectl -n stratum create secret generic stratum-worker-enrollment \
  --from-file=stratum-enroll \
  --from-file=controller-ca.crt=ca.crt

Enable workers

workers:
  enabled: true
  existingSecret: stratum-worker-enrollment

Apply the worker deployment

helm upgrade stratum ./stratum \
  --namespace stratum \
  -f values-production.yaml

Each worker uses the Kubernetes node name as its execution identity and persists its Connect/native-executor state under /var/lib/stratum/worker on that node.

07 OperationsVerify Verify the deployment Check controller storage, pod placement, Services, logs, DNS, and worker enrollment.

Inspect STRATUM on Kubernetes

kubectl -n stratum get pods,pvc,svc -o wide
kubectl -n stratum get pods -l app.kubernetes.io/component=controller
kubectl -n stratum get pods -l app.kubernetes.io/component=worker
kubectl -n stratum logs -l app.kubernetes.io/component=controller \
  -c stratum --tail=200

The public controller Service exposes 8443/TCP for the UI/API, enrollment, and native worker execution transport, plus the configured STRATUM Connect UDP port when Continuum is enabled. Other host-network runtime listeners are not automatically published as Kubernetes Services and must be controlled by node firewall policy.

After DNS, Service exposure, firewall policy, and certificates are correct, open https://<stratum.publicHost>:8443/stratum/.

ALT: Appliances

Alternative: STRATUM Cloud

STRATUM appliances that boot STRATUM container

STRATUM appliances are customized Linux kernels that boot, have nothing else except enough to boot a Linux container. And that container is STRATUM. So you can deploy a VMware OVF image, an Amazon AWS AMI, etc… and boot STRATUM that way. Its still a container, just wrapped in a Linux kernel.

STRATUM appliances will auto-enlarge it’s filesystem if the host/hypervisor expands it. STRATUM appliances also make use of pre-labeled disks, identifying specific labels as VM storage.

01 Virtual Hardware PCIe Device Virtual Hardware, Not a Remote Endpoint A purpose-built PCIe accelerator presented directly to the VM.

STRATUM GPU is not simply a GPU service exposed over a network. STRATUM presents a purpose-built virtual PCIe accelerator device directly to the guest.

The device participates in the VM's hardware model with PCIe enumeration, BAR address spaces, MMIO registers, interrupts, and device state.

The VM sees hardware. STRATUM sees the fabric.

02 Data Path CUDA + NVML Built for GPU Workloads BAR, MMIO, DMA, command rings and GPU runtime integration.

STRATUM GPU combines BAR data windows, MMIO control, command rings, DMA-oriented transport, completion handling, and interrupts into a hardware-facing path designed for accelerator traffic.

Supported CUDA and NVML operations travel through the STRATUM GPU device to the physical accelerator without requiring the application to understand the network beneath it.

Not REST calls pretending to be hardware-a virtual hardware path built for GPU operations.

03 Continuum GPU Fabric The Datacenter Becomes the GPU Backplane The physical PCIe slot no longer has to define where the accelerator lives.

Traditional GPU attachment is constrained by the chassis:

VM → Server → PCIe Slot → GPU

STRATUM introduces another model:

VM → STRATUM GPU → Continuum → GPU Resource

The accelerator can be associated with the local worker or supplied by GPU-capable infrastructure elsewhere in the STRATUM Continuum.

The GPU becomes a datacenter resource, not merely a peripheral installed in one server.

04 Operations Zero Endpoint Plumbing No GPU-Server Plumbing No GPU-server addresses or transport topology inside the workload.

Traditional remote-GPU architectures can expose another layer of infrastructure: GPU-server addresses, ports, firewall rules, client services, transport mappings, and resource endpoints.

STRATUM moves that relationship beneath the VM. The workload consumes STRATUM GPU while the platform resolves the accelerator, execution worker, transport, and Continuum relationship behind it.

Other architectures expose the GPU network. STRATUM makes it disappear into the infrastructure.

05 Datacenter as an Application Portability The GPU Relationship Travels With the Datacenter Accelerator topology becomes part of the executable infrastructure.

STRATUM can define GPU capability alongside the rest of the virtual datacenter: VMs, CPU, memory, networking, STRATUM Switch topology, storage, execution placement, identity, policy, and site relationships.

Existing Windows and Linux workloads can gain accelerator access without first being rebuilt as cloud-native applications.

Build the environment. Version it. Move it. Reconstruct it where compatible infrastructure exists.

A GPU should not be a peripheral attached to a server. It should be a resource attached to the datacenter.

User Guide

Virtual Datacenters

On top right of the Mission Planner interface, select Datacenter. Create or select a virtual datacenter. You have can have many datacenters that are virtually isolated from each other.

Data Layers

Left pane is a drawer that lets you select what you want to show on the Mission Planner canvas. The screenshot here shows no layers selected so its cleaner but without contextual details.

System Arsenal

System Arsenal pull-out drawer on the right side of the datacenter canvas lists all virtual system templates. Switches, firewalls, routers, virtual machines. Deploy to the canvas by clicking one.

Selection Details

Click a node on the canvas and the right pane shows selection details. Runtime state, interfaces, template used, worker execution host, capacity, GPU details.

Right Click Menu

Right click a node on the canvas gives a radial menu for editing and controlling the node. Open the node’s console, edit system, create network or serial link, suspend/resume, hibernate, snapshot management, and move/migrate to another STRATUM worker.

Snapshots

From the right-click radial menu you can manage snapshots. You can include snapshotting memory runtime as well, not just disk. Due to the nature of massive scaling capabilities (10s of thousands of stratum workers), the current version of STRATUM will not let you migrate/move a VM to another host while snapshots are enabled. To migrate/move you will need to press the button ‘Consolidate to Shared Storage’.

Migrate VM

From the right-click radial menu you can move/migrate VMs to specific hosts when there is a specific need to do so. STRATUM shows you what target hosts are compatible with resources, GPUs, ARM vs x86 architecture, etc…

Node Editor (runtime)

From the right-click radial menu you can edit a node. Name, template used, payload image used, ethernet interfaces, and runtime details enabling or disabiling: acceleration, 3D acceleration (OpenGL shared with host), encrypted runtime (memory of VM), and high availability (HA). HA is active-passive, meaning if a VM crashes or its host goes offline, the VM will be rescheduled to run on another worker. Memory state is not preserved with HA in the current STRATUM version.

Node Editor (GPU)

Scrolling down in the node editor gives more settings, removable media and STRATUM’s AI/GPU Accelerator Fabric. You can attach local-to-host PCIe passthrough, but STRATUM also can attach remote accelerators. Any GPU in your datacenter can be shared and are accessible as paravirtual GPU PCIe devices in your VM. You do not need to install any GPU-over-IP software and maintain GPU-over-IP software, just enable the STRATUM GPU device and it enables a paravirtual GPU as a PCIe device.
The current version of STRATUM’s special GPU PCI device only supports NVIDIA CUDA runtime.

VM Console

From the right-click radial menu you can open the console. Depending on your VM setup, this could be the display console or a serial port. Serial ports are often used with switches, routers, and firewalls.

Removable Media (runtime)

From the console UI, on the top right is a button with a CDrom icon. That opens up the removable media interface to add or swap ISO images, or add STRATUM’s guest tools image. Guest tools are needed for STRATUM’s paravirtual PCIe GPU device enabling access to remote GPUs as if local. Windows-based VMs should also install STRATUM Guest Tools to enable VirtIO device drivers for performance. Your modern Linux platforms already come with VirtIO device drivers.

All Nodes UI

The All Nodes view provides a centralized table for managing virtual machines and network devices at scale. View CPU, memory, ethernet, GPU, image, and runtime details, edit configurable settings, and manage each node individually or perform lifecycle actions across all selected nodes at once.

STRATUM Switch

While you can use any virtual switch appliance/VM, from Cisco, Arista, Palo Alto, etc.. STRATUM does provide an integrated, fast, and powerful software L2 and L3 switch that uses a familiar interface. Setup VLANs, setup port mirroring, everything you would do in a physical switch.
On the right selection panel, you can get more switch and individual port details.

Link Impairment Profile

Selecting a network link on the canvas shows its details in the selection pane on the right. This is useful for testing labs to similiate latency, jitter, and packet loss. Some of our customers use STRATUM as a digital twin, complete with network realism of satelitte communications and large geographical distances.

Edit Link Impairment

Editing a link Impairment profile lets the user enter custom latency, jitter, or packet loss settings or choose from a set of prepared mission effects profiles: clean, high-latency backhaul, degraded RF, or contested link.

Interfaces

Selected Data Layers show in-line details such as Interfaces. A fast operational way to see the digital landscape.

Execution

Selelcted Data Layers show in-line details such as execution/worker host context. With 100s or thousands of STRATUM worker hosts, you can clearly see impact and mission risk quickly.

Storage

Selected Data Layers show in-line details operationally such as storage. STRATUM uses a storage protocol and data is stored on the Controller. STRATUM is also unique in that template VM data is immutable, the individual VMs store deltas but still using the same storage protocl, However snapshots, hibernation, and paused VMs (memory runtime) store that specific metadata locally on the worker node.

Arsenal Forge: Templates

Everything in STRATUM is a template. You deploy a template to the canvas and run it. Think of templates like how Linux container images are to applications. You can deploy 100 application using the same image. Arsenal Forge lets you create, manage, import, and export templates.

Arsenal Forge: Image Create

After you create a template, you need to create a VM image folder using that same template name and a version# (template name = test, VM folder = test-1.0.0). Then click the create VM image button to add a VM disk image into that folder.

Arsenal Forge: VM Images

Your VM images should be in folders that are the same name as its related template, with a version number after it. ISO images can be added in Arsenal Forge too.

Arsenal Forge: ISOs

The STRATUM Arsenal Forge uploads, versions, and manages ISO images used across your virtual datacenters. Administrators can organize, inspect, download, rename, and track image history from one central library.

STRATUM Ops

Operations interface is a datacenter visualization in real-time and is accessible from a button on the left rail. Operational layers include all assets, physical, worker scheduler, workloads, networks, GPU, Storage, and assets requriing operational attention. If you have 100s of nodes, they will show up as their own drill-down node that can be expanded or collapsed. Relationships are key here, and identifying the blast radius to a failure, lineage, or resource contention.

Packet Capture

Launch Packet Capture directly from any STRATUM Switch to inspect live traffic without leaving the operations interface. Filter and decode packets, trace flows through the topology, inspect protocol details, and export PCAP files for deeper analysis or troubleshooting.

Packet Capture Path Highlight

Turn captured traffic into an immediate visual path through the datacenter. STRATUM highlights every node and link involved in the selected flow with an animated pulse, making traffic paths, dependencies, and unexpected routing instantly visible on the live topology.

STRATUM AI: Infrastructure Reasoning.

A datacenter that thinks. STRATUM AI is a movable, context-aware infrastructure interface that can reason directly over the live datacenter. Building and modifying environments, analyzing topology and capacity, explaining selected objects, troubleshooting failures, and inspecting network captures across the fabric. With vision-enabled VM Console Computer Use, it can also enter guest consoles to install, configure, test, debug, click, and type while you watch its actions directly alongside the datacenter canvas.

Administrator Guide

Compute Fabric

Cluster-wide (all datacenters, clouds, labs, edge) partitions, jobs, nodes, and compute fabric status. Every VM, network switch, firewall,or router are submitted as jobs, similiar to how High Performance Computing (HPC) delivers massive execution scale.

AI Accelerator Fabric

Cluster-wide remote GPU capacity, placement, and VM attachment readiness. Users select AI/GPU capability only and STRATUM owns GPU placement, VM transport, and guest CUDA/NVML exposure.

Network Fabric

The STRATUM Continuum is encrypted mesh management paths and distributed private datacenter networks. All STRATUM worker nodes connect through this network fabric even if they are remote, Cloud, or edge. It provides a virtual datacenter network substrate across everything to form 1 platform. Workers initiate outbound HTTPS enrollment and connect into the distributed Continuum mesh autonomously. Their private tunnel keys never leave the worker. For manual enrollment, you download Token and Controller CA from this interface.

License Management

License add, replace, download, and details

Users

User administration. Create, delete, edit, select role, select groups. Users are able to use CAC or YukiKey but those require a valid TLS certificate for STRATUM. The user sets those up from the login window.

Roles

Manage User roles such as platform administration, enabling users to edit mission topology where you can have users view-only and operate VMs and the network but cannot make changes.

Groups

Manage User groups.

Sessions

List users logged in and if active.

Audit

Administative action audit showing time, actor, action, and target.

Execution Hosts

STRATUM host execution enrollment is automated, but you are able to add worker nodes manually, edit, and delete them. Not usually necessary but it is here in case manual worker host configuration is needed.

Storage Fabric

The STRATUM Storage Fabric distributes controller-authoritative VM image replicas across dedicated STRATUM Storage nodes to reduce centralized storage load and place VM data closer to where it runs. Administrators assign templates to specific storage nodes, review the desired placement, and ‘Bake’ the Storage to replicate those images to their selected destinations. Storage nodes can operate across edge locations, cloud environments, multiple datacenters, or even disconnected platforms that have selective needs, while remaining connected through direct Continuum iSCSI paths. The controller retains the authoritative copy, giving STRATUM a consistent source of truth while allowing new VM disks to be served from the most appropriate storage location.

Directory Services

Connect STRATUM to Microsoft Active Directory, Microsoft Entra Domain Services (Azure AD DS), or any standards-based LDAP directory for centralized authentication.

STRATUM AI Configuration

Connect STRATUM to an OpenAI-compatible AI endpoint for infrastructure reasoning and assisted operations. Configure the model, authentication, request limits, and optional vision-based VM Console Computer Use while retaining STRATUM user permissions and administrative control. Multi-modal LLM is required for VM Console interfacing (installing OS, debug, troubleshoot, the AI needs to be able to ‘see’ your VM console and interact with it).

Install a Worker

Ensure mutual FQDN hostname resolution!
Copy stratum-container.tar and stratum-host binary to the worker. STRATUM’s Network Fabric UI has a Worker Enrollment section to download stratum-enroll token and controller-ca files, including the commands to type on the worker. Copy these to the worker.
Apply host settings: ./stratum-host apply -yes
Copy/paste the host.yaml from the UI
Run the commands shown in the Worker Enrollment UI.

Install a Storage Worker

Ensure mutual FQDN hostname resolution!
Copy stratum-container.tar and stratum-host binary to the worker. STRATUM’s Network Fabric UI has a Worker Enrollment section to download stratum-enroll token and controller-ca files, including the commands to type on the worker. Copy these to the worker.
Apply host settings: ./stratum-host apply -yes
Copy/paste the host.yaml from the UI
change role: worker to role: storage
Run the commands shown in the Worker Enrollment UI.

Disk Encryption

Disk encryption is a property of the storage volume. Storage Fabric flow can distribute encrypted images. Enable or disable encryption on VM disks. NOTE: exporting an Arsenal bundle retains its encryption.

DevSecOps Guide

Workload Layering

Your infrastructure, workloads, and deployment logic are layered into one portable Datacenter-as-an-Application. Package virtual machines directly into a custom STRATUM OCI image by copying their disks into the image and creating or reusing a template definition under /stratum/html/templates/intel/ within the container image.

STRATUM automatically maps each disk according to its naming convention: sata* disks are distributed across AHCI controllers, sd* disks use VirtIO SCSI, vd* and virtio* disks use VirtIO Block, and hd* disks use IDE. Raw disk formats such as .raw, .img, and .bin are presented through the iSCSI URI provided by STRATUM Store rather than accessed through a local filesystem path.

The resulting OCI image contains STRATUM, the VM workloads, and their deployment definitions as one versioned artifact. Distribute it through an existing container registry, deploy it to any supported Linux or Kubernetes environment, import a Virtual Datacenter, and start the complete environment with its required virtual machines already embedded.

docker load -i stratum-container.tar
cat > Dockerfile.workload <<‘EOF’
FROM stratum:1.0.0
COPY templates/esxi.yaml /stratum/html/templates/intel/customvm/
COPY disks/sataa.qcow2 /stratum/addons/qemu/customvm/
COPY disks/satab.qcow2 /stratum/addons/qemu/customvm/
EOF
docker build -f Dockerfile.workload -t stratum:1.0.0-customvm .
docker save -o stratum-container-customvm.tar stratum:1.0.0-customvm
Distribute stratum-container-customvm.tar

Move from VMware to STRATUM

Bring existing VMware workloads forward without rebuilding them from scratch. STRATUM provides free, open-source migration tools on GitHub that convert VMware-exported OVA and OVF packages into portable STRATUM Arsenal Bundles, ready to import, version, and deploy.

For enterprise migrations, STRATUM can also use an optional virt-v2v backend to inspect and prepare Windows or Linux guests for KVM, including installing the VirtIO drivers required for STRATUM. It supports VMware-exported OVA files and unpacked OVA directories, providing a practical path from legacy virtualization to infrastructure delivered as a versioned application.

See our GitHub page for migration tools, documentation, and examples.

Stratum-host command (TUI & CLI)

STRATUM / HOST MANAGER

Configure the host. Deploy the datacenter.

stratum-host is the CLI and TUI for preparing Linux, configuring STRATUM, operating the OCI container, enrolling workers, managing pnet0 and nat0, assigning GPUs, validating storage, and automating fleets.

18 sections shown

01 GuideGetting StartedStart here What is stratum-host? The TUI for people; the CLI for repeatable operations.

stratum-host is the host-side control surface for STRATUM. It prepares Linux, manages the STRATUM OCI container, validates configuration, handles certificates and networking, exposes hardware inventory, and keeps the running container reconciled with /etc/stratum/host.yaml.

One command, two layers. The TUI edits desired configuration. The CLI makes that configuration repeatable through scripts, golden images, configuration management, and fleet provisioning.

Open the TUI

sudo stratum-host
# or
sudo stratum-host tui

Key	Action
`Tab`	Switch between the left menu and the current pane.
`↑ ↓` or `j k`	Move through menus and fields.
`Enter`	Edit, select, inspect, or run the highlighted operation.
`Ctrl-S`	Save settings to `/etc/stratum/host.yaml`.
`Q`	Quit the TUI.

Dashboard shortcuts

Key	Action	What it does
`S`	Start	Starts the configured controller, worker, or storage container.
`X`	Stop	Stops the container but retains it and its persistent data.
`C`	Reconcile	Recreates a drifted container while preserving persistent state.
`P`	Plan	Shows host changes without applying them.
`A`	Apply	Applies enabled host setup actions. Root is required.
`V`	Verify	Runs checks for enabled features without changing the host.
`R`	Refresh	Reloads live status.

stratum-host Dashboard menu — Runtime configuration in stratum-host.

02 RunbookGetting StartedWorker Install a STRATUM worker Plan first, apply host changes deliberately, install the trusted bundle, then reconcile.

A worker bootstrap bundle normally contains these five files:

host.yaml
stratum-ca.crt
stratum-container.tar
stratum-enroll
stratum-host

Copy both the stratum-host binary and stratum-container.tar to every host. The binary prepares and operates the host; the tarball supplies the STRATUM OCI image that Host Setup loads.

1. Inspect and apply host preparation

chmod +x ./stratum-host
sudo ./stratum-host plan
sudo ./stratum-host apply --yes

Yes, apply --yes may interrupt the network. Default physical-bridge mode moves the active uplink under pnet0. Use an out-of-band console, or select cloud-safe routed mode before applying when preserving SSH is critical.

2. Install enrollment material and configuration

sudo install -m 0755 stratum-host /usr/local/sbin/stratum-host
sudo install -d -m 0700 /etc/stratum/secure
sudo install -m 0600 stratum-enroll /etc/stratum/secure/stratum-enroll
sudo install -m 0644 stratum-ca.crt /etc/stratum/secure/controller-ca.crt
sudo install -m 0600 host.yaml /etc/stratum/host.yaml

3. Start and reconcile the worker

sudo stratum-host start --reconcile
sudo stratum-host status --deep
sudo stratum-host logs --follow

The worker must have a unique FQDN, and it must be able to resolve and reach the controller FQDN. The controller CA and enrollment secret are required when the Continuum fabric is enabled.

Repeatable by design. Run plan during change review, then run apply --yes from Ansible, Puppet, Chef, Terraform-driven provisioning, a golden-image pipeline, or your own scripting framework.

03 ScaleAutomationFleet pattern From one worker to 1,000 Standardize the host, distribute a small trusted bundle, and let workers identify themselves.

For a large fleet, treat stratum-host as an idempotent node-preparation step rather than a manual installer.

Fleet requirement	Guidance
Consistent host preparation	Apply the same enabled Host Setup actions through golden images or `stratum-host apply --yes`.
Bootstrap files	Distribute `stratum-host`, `stratum-container.tar`, `host.yaml`, `stratum-enroll`, and `stratum-ca.crt`.
Entitlement	Reuse the approved entitlement or enrollment code generated in the STRATUM Admin UI where your license permits it.
Identity	Every physical worker needs a unique, stable FQDN. `identity.nodeName: auto` uses the detected host FQDN.
Controller discovery	Every worker must resolve the controller FQDN through DNS or `/etc/hosts`.
Portable GPU configuration	Keep fleet YAML on `gpu.policy: auto`. Avoid host-specific PCI BDFs in a common image.
Controlled startup	The default worker Continuum startup jitter spreads enrollment and heartbeat traffic instead of creating a synchronized burst; controllers default to zero startup jitter.

Sites divide one Continuum into regions

identity.site is a placement label. It can be default, us-east, boston, taiwan, tokyo, or any naming convention meaningful to your organization.

sudo stratum-host config set identity.site boston
sudo stratum-host start --reconcile

A virtual datacenter can set a default site. VMs deployed into that VDC then prefer workers in that site unless a more specific placement rule overrides it. This creates regions inside one enterprise-wide STRATUM Continuum without operating a separate control plane for every facility.

Site is scheduling metadata, not automatic data sovereignty. Storage, backups, logs, keys, identity systems, and external services must also follow the required regional policy.

04 TUI MenuRuntimeCore settings Runtime Role, identity, controller discovery, container lifecycle, and persistent state.

The Runtime menu defines what this host is, how it handles VM storage I/O, which container it runs, where it finds the controller, and where mutable state lives.

Setting	Plain-English meaning
`role`	`controller`, `worker`, or dedicated `storage`. `fabric-gateway` and `failover-controller` remain reserved and cannot be started.
`execution.ioProcessing`	Controls IOThread assignment for virtio-blk and virtio-scsi: `compatibility`, `auto`, or `dedicated`. Applies to newly started VMs.
`identity.nodeName`	Stable STRATUM Continuum identity. `auto` uses the controller host for controllers, detected host FQDN for workers, and a storage-specific identity for storage containers.
`identity.site`	Continuum site metadata used for placement.
`controller.host`	Controller FQDN or IP. Workers and storage nodes must set this explicitly; a resolvable FQDN is preferred.
`controller.ip`	Controller underlay IP. Controllers can auto-detect their primary IPv4 address; workers and storage roles resolve `controller.host` through the host resolver.
`public.host`	Browser-facing hostname used by the web frontend, authentication layer, and certificate SANs.
`public.httpsPort`	HTTPS port. Controller and worker host-networked runtime requires `8443`.
`runtime.engine`	`auto` prefers a responsive Docker daemon, then Podman.
`runtime.image`	OCI image to run. Default `stratum:latest`; pin a versioned release tag in production.
`runtime.containerName`	Docker or Podman container name. Use a distinct name when another STRATUM container shares the host.
`runtime.restartPolicy`	Container restart behavior: `unless-stopped`, `always`, `on-failure`, or `none`.
`runtime.socket`	Container API socket: `auto`, `none`, or an explicit Docker-compatible path.
`storage.root`	Host root for mutable STRATUM state. Default: `/persistent/stratum`.
`storage.persistControllerData`	Persists controller state outside the replaceable container, including `/stratum/var`, datacenters, data, Arsenal, config, self-signed certificates, and controller secrets.
`storage.seedControllerData`	Copies image defaults into missing persistent paths on first host deployment without replacing existing content.
`storage.repairPermissions`	Maintains the mixed ownership required by current persistent state: native execution state remains root-owned while service data uses the image's numeric STRATUM UID/GID.

New deployment rule: leave automatic identity and engine detection enabled unless the environment has a concrete reason to override them. Explicit settings are most useful for fixed controller addresses, multiple containers on one host, or strict release pinning.

stratum-host Runtime menu — Runtime configuration in stratum-host.

05 TUI SettingRuntimeVM storage I/O I/O Processing Choose how STRATUM assigns IOThreads for virtio storage so you can balance compatibility, latency, and host thread count.

I/O Processing controls how STRATUM assigns IOThreads to VM storage devices. An IOThread is a dedicated event-loop thread that one or more devices can use for disk I/O instead of sending all storage work through the main VM loop. Moving storage activity off that primary loop can reduce lock contention, improve I/O latency, and cut down guest-visible jitter on busy systems.

STRATUM applies this feature to virtio-blk and virtio-scsi storage, which are the paravirtualized disk paths most likely to benefit. The chosen mode affects newly started VMs; already running VMs keep the threading model they were launched with.

Recommended default: keep Compatibility if you want strict continuity with historic STRATUM behavior. Use Auto when you want a practical middle ground. Reserve Dedicated for testing, benchmarking, or specialized high-I/O workloads that justify the extra host threads.

Implemented modes

Mode	VM behavior
Compatibility	Preserves STRATUM's established behavior and does not introduce the newer IOThread assignment model. This is the safest choice when consistency matters more than I/O experimentation.
Auto	Lazily creates one shared IOThread per VM when that VM has `virtio-blk` or `virtio-scsi` storage. It improves separation from the main VM loop without multiplying threads aggressively.
Dedicated	Creates one IOThread per virtio-blk disk and one shared IOThread for the VM's virtio-scsi controller. This gives the most explicit separation, but it also increases host thread count the most.

What changes and what does not

Area	Behavior
Affected	`virtio-blk` and `virtio-scsi` devices participate in the selected IOThread policy.
Unchanged	SATA/AHCI, IDE, CD-ROM, floppy, kernel, and initrd handling remain unchanged. This setting is specifically about the virtio storage paths.
When it applies	The change applies to newly started VMs. If you change the setting, restart affected VMs to launch them with the new I/O processing model.

Why Auto is usually the best next step

It introduces an IOThread only when the VM actually uses supported virtio storage, and it keeps the design simple by sharing one thread per VM instead of creating many threads.

Why Dedicated should stay specialized

On a dense host, a dedicated-thread model can substantially increase the total number of virtualization threads. That may be useful for targeted workloads, but it should be validated instead of enabled broadly by default.

Operator guidance

Use Compatibility when you need repeatable behavior across an existing estate. Use Auto when you want a low-friction improvement path for virtio-backed storage. Use Dedicated for focused testing, for known high-I/O guests, or when benchmarking shows a measurable benefit worth the additional host overhead.

Dedicated is not a free upgrade. More IOThreads can reduce contention inside a VM, but they also increase scheduling overhead on the host. On high-density systems, that can become a meaningful tradeoff.

stratum-host Runtime page showing the VM I/O processing setting — The Runtime menu exposes the VM I/O processing mode so operators can keep legacy behavior or enable IOThread-based virtio storage handling for newly started VMs.

06 TUI MenuRuntimeTLS Certificates Create demo certificates or validate externally managed PKI without overwriting it.

The Certificates menu controls the TLS material used by the controller and workers.

Setting	Meaning
`certificates.mode`	`self-signed` creates and preserves the demo-friendly CA/server/client bundle. `external` validates supplied files and never overwrites them.
`certificates.directory`	Host certificate directory mounted into the container. Default: `/etc/stratum/certs`.
`certificates.demoP12Password`	Password for the current demo PKCS#12 client bundle. Change only when the consuming workflow is also updated.
`certificates.warningDays`	How early expiration health becomes a warning.

Useful certificate checks

stratum-host cert status
stratum-host cert trust
sudo stratum-host cert ensure

On a worker, status and trust perform a live controller TLS verification with /etc/stratum/secure/controller-ca.crt. Keep connect.insecureTLS disabled outside a disposable demo.

stratum-host Certificates menu — Certificates configuration in stratum-host.

07 TUI MenuNetworkingHost networking Network Continuum transport, pnet0 provider access, rollback safety, and nat0 DHCP/NAT.

The Network menu configures the Continuum underlay, the physical provider network, and the simple host-local NAT network.

Setting	Meaning
`connect.enabled`	Starts STRATUM Continuum and supplies authenticated worker identity. It is required for worker execution; controllers may disable it only for standalone local operation.
`connect.interface`	Continuum interface name, normally `stratum0`.
`connect.port`	STRATUM Connect v3 Continuum UDP port, normally `51820`.
`storage.connectHostPort`	Host UDP port published to an isolated storage container. Default `51821`; use a unique value for each storage container sharing a host.
`connect.payloadMTU`	Continuum payload MTU. Default `1350`.
`connect.pollSeconds`	Worker report/heartbeat interval. Default `60`.
`connect.meshPollSeconds`	Conditional static mesh-state check interval. Default `60`.
`connect.startupJitterSeconds`	Random worker startup delay used to spread large reconnect waves. Default `60`.
`connect.controllerStartupJitterSeconds`	Controller Continuum startup delay. Default `0` keeps a newly started controller immediately responsive.
`connect.insecureTLS`	Development escape hatch that weakens controller certificate verification. Leave `false` outside disposable demos.
`network.pnetMode`	`bridge` gives direct physical-LAN attachment. `routed` is cloud/SSH-safe and leaves the management NIC untouched.
`network.pnetBridgeName`	Provider bridge name, normally `pnet0`.
`network.pnetUplink`	Physical uplink. `auto` chooses the default-route interface.
`network.pnetCIDR` / `network.pnetGateway`	Private subnet and gateway used only in routed pnet0 mode.
`network.pnetRollbackSeconds`	Bridge-mode safety timer. Default `120` seconds.
`network.pnetValidationTargets`	Optional hosts, IPs, or host:port targets that must be reachable before bridge rollback is cancelled.
`network.natEnabled`	Creates the host-local `nat0` bridge plus DHCP and NAT egress.
`network.natBridgeName`	Host-local NAT bridge name, normally `nat0`.
`network.natCIDR` / `network.natGateway`	Private NAT subnet and guest gateway.
`network.natDHCPStart` / `network.natDHCPEnd`	Guest DHCP lease range.
`network.natDNS`	DNS servers advertised to nat0 guests.

Physical bridge versus cloud-safe pnet0

Physical bridge - default

VM / tap → pnet0 bridge → physical NIC

Best when you control Layer 2 and want VMs directly on the LAN. Applying it can interrupt SSH while the uplink moves under the bridge.

Cloud-safe routed mode

VM / tap → pnet0 → host routing / NAT → uplink

Keeps the cloud- or provider-managed NIC intact. It prioritizes preserving access over extracting the last increment of direct Layer 2 performance during initial setup.

sudo stratum-host config set network.pnetMode routed
sudo stratum-host plan
sudo stratum-host apply --yes

Bridge mode arms a crash-resistant rollback before changing the management uplink. Inspect or control it with:

stratum-host network status
sudo stratum-host network confirm
sudo stratum-host network rollback

stratum-host Network menu — Network configuration in stratum-host.

08 ReferenceNetworkingCanvas networks STRATUM network types Bridge, Internal, Private, pnet0, and nat0 are intentionally different scopes.

These are network objects used inside the STRATUM canvas. They choose the Layer 2 domain to which a VM or virtual switch attaches.

Network object	Scope and purpose
Bridge	A normal, distinct Layer 2 network object inside the current virtual datacenter or lab. Each Bridge object creates its own broadcast domain. It has no DHCP or internet access unless you attach a service that provides them.
Internal	A shared internal backbone for the current tenant and running lab/session. Multiple Internal attachments in that same session converge on the same segment. It remains separate from other lab sessions.
Private	A tenant-scoped private backbone that can be reused across that tenant’s labs or virtual datacenters. It stays isolated from other tenants and is useful for common management or service networks.
Management (Cloud0) / pnet0	pnet = Physical Network. Connects the virtual topology to the host’s provider network. In physical-bridge mode this reaches the external LAN directly; in cloud-safe mode it uses host routing/NAT.
NAT / DHCP (nat0)	A host-local network with automatic DHCP and outbound NAT. It is never stretched across workers, and inbound access requires an explicit routing or forwarding design.

Simple distinction: Bridge is one explicit network object. Internal is shared inside one active vDatacenter/session. Private is shared for the tenant. pnet0 reaches the provider network. nat0 gives easy host-local DHCP and outbound access.

09 TUI MenuGPU / PCINative execution Workers & GPU Native worker execution plus GPU Fabric, passthrough, Host Only, and advanced assignment controls.

STRATUM 1.0 uses its native execution fabric. QEMU and STRATUMSwitch workloads are dispatched directly through STRATUM. Remote workers authenticate through STRATUM Continuum, maintain an outbound execution channel to the controller, and report their own CPU, memory, site, architecture, and GPU capabilities. Worker admission, dispatch, and accounting are part of STRATUM rather than a separately configured scheduler service.

Worker execution depends on Continuum. A worker requires connect.enabled=true, enrollment material, and controller trust. The controller's local executor does not depend on Continuum.

GPU policy settings

Setting	Meaning
`gpu.policy`	Advanced fleet policy normally maintained by the GPU page: `auto`, `host-all`, `vfio-all`, `mixed`, or `disabled`. `auto` makes supported GPUs available through GPU Fabric unless a host-specific exception exists.
`gpu.vendor`	Limit discovery to NVIDIA, AMD, Intel, or any supported vendor. Default is NVIDIA.
`gpu.includeCompanionFunctions`	Includes eligible audio/USB companion functions in the same PCI slot or IOMMU group when preparing passthrough.
`gpu.allowBootDisplayGPU`	Allows passthrough of the GPU serving the host console. Leave disabled unless another verified console path exists.
`gpu.allowSharedIOMMUGroups`	Allows passthrough when unrelated devices share an IOMMU group. Advanced and normally unsafe.
`gpu.runtimeDiscovery`	`auto` or `off`. `vfio-all` resolves discovery off because devices are detached from vendor drivers.
`gpu.vfioDevices`	Host-specific PCI BDFs assigned to direct passthrough. Normally maintained by the GPU page or `gpu assign` CLI.
`gpu.hostDevices`	Host-specific GPUs kept on the host and excluded from STRATUM. Normally maintained by the GPU page or `gpu assign` CLI.

Native execution behavior

Worker enrollment provides the execution trust root and per-worker identity. When the controller has work for a worker, the already-established outbound command channel can deliver start, stop, QMP, snapshot, and other directed operations without a separate scheduler daemon or inbound worker-control service.

stratum-host Workers and GPU menu — GPU policy and worker hardware configuration in stratum-host.

10 TUI PagesGpu PciHardware GPU assignment and PCI inventory Understand GPU Fabric, VFIO passthrough, Host Only, BDFs, and reboot requirements.

The GPU page is operational: it assigns each detected GPU. The PCI page is inventory-only in the current release; generic PCI passthrough, other than for GPUs, is intentionally not enabled.

GPU assignment	What happens
GPU Fabric	Default. The GPU stays on its vendor driver and is served through `stratum` and the virtual STRATUM GPU hardware device.
Passthrough	The device is bound to `vfio-pci` and reserved for direct attachment to a VM on that same worker. A reboot is required when bindings change.
Host Only	The GPU remains on the host driver but is excluded from STRATUM inventory and scheduling.

VFIO, boot display, and BDFs

VFIO is the Linux framework used to hand a physical PCI device directly to a VM. Binding a GPU to vfio-pci removes it from the normal host graphics or compute driver.

A boot-display GPU is the adapter the host firmware or Linux console is using. Passing it through may blank the local screen and remove your emergency console. Enable gpu.allowBootDisplayGPU only when the host has another GPU, serial console, BMC/iDRAC/iLO, or a verified cloud console.

A PCI BDF is the device address in domain:bus:device.function form:

0000:65:00.0

Find the correct values with:

stratum-host gpu list
stratum-host pci list

Do not guess BDFs. They are host-specific and may change after hardware, firmware, or topology changes. The GPU page is the preferred way to maintain gpu.vfioDevices and gpu.hostDevices.

vfio-all is broad. It assigns all matching GPUs-and eligible companion functions-to passthrough. Keep the boot-GPU and IOMMU-group safety checks enabled unless the hardware has been qualified.

Existing NVIDIA MIG instances are detected as GPU Fabric scheduling units. STRATUM does not create or repartition MIG layouts in this release.

stratum-host GPU and PCI menu — GPU configuration in stratum-host.

11 TUI MenuHost SetupHost reconciliation Host Setup Container engine, images, networking, KVM, KSM, storage tuning, and firewall preparation.

Host Setup is the reconciler for Linux capabilities STRATUM needs. Every action has a check, a dry-run plan, and an apply path.

Action	Meaning
`hostSetup.containerEngine`	Installs Docker on Debian/Ubuntu or Podman on RHEL-family systems when no usable engine exists.
`hostSetup.loadImages`	Loads `stratum-container.tar`.
`hostSetup.sharedDirectories`	Creates `/etc/stratum` and persistent storage roots.
`hostSetup.sysctlLargeHost`	Raises memory-map, queue, and file-descriptor limits for large virtualization hosts.
`hostSetup.sysctlNetwork`	Applies high-throughput TCP and network settings.
`hostSetup.irqbalance`	Installs and enables IRQ balancing across CPUs.
`hostSetup.fstrim`	Enables periodic SSD/NVMe trim where supported.
`hostSetup.nvmeTune`	Uses the low-overhead `none` NVMe scheduler where supported.
`hostSetup.pnetBridge`	Builds pnet0 in physical-bridge or cloud-safe routed mode.
`hostSetup.pnetL2Filter`	Installs Layer 2 bridge filtering rules.
`hostSetup.pnetDot1x`	Allows required 802.1X link-local forwarding through the bridge.
`hostSetup.kvmTune`	Enables nested virtualization and safe KVM host defaults.
`hostSetup.ksm`	Enables Kernel Same-page Merging memory deduplication.
`hostSetup.ksmPages`	Number of memory pages KSM examines per scan batch.
`hostSetup.ksmSleepMilliseconds`	Delay between KSM scan batches; lower is more aggressive and uses more CPU.
`hostSetup.tuned`	Installs and selects an appropriate host performance profile.
`hostSetup.firewall`	Applies role-aware UFW or firewalld rules.

KSM is memory deduplication

Kernel Same-page Merging scans eligible anonymous memory, finds identical pages, and replaces them with one shared copy-on-write page. It can improve density when many VMs come from the same template. Spin up 10 STRATUM VM templates yet consume the memory footprint of only 2, maybe 3, depending on workloads.

KSM is not free RAM: it consumes CPU for scanning, saves little on dissimilar or encrypted pages, and may be disabled across hostile multi-tenant boundaries because memory deduplication can increase side-channel risk. Tune pages_to_scan and the sleep interval from measured workload behavior.

Open Memory Deduplication in the TUI to see the live savings estimate, scan progress, and the kernel settings currently controlling KSM.

sudo stratum-host plan
sudo stratum-host apply --yes
sudo stratum-host verify

stratum-host Host Setup menu — Host Setup configuration in stratum-host.

12 TUI PageHost SetupLive KSM telemetry Memory Deduplication See how much physical memory KSM is avoiding, how aggressively it is scanning, and whether the current workload is benefiting.

The Memory Deduplication page turns Linux Kernel Same-page Merging statistics into practical host-capacity information. KSM looks for identical eligible memory pages-often created when several VMs run the same operating system or originate from the same template-and keeps one shared copy until a workload writes to it.

Start with “Net physical memory avoided.” This is the closest single answer to “How much host RAM is KSM saving right now?” STRATUM uses the kernel's net-profit value when the running kernel exposes it, rather than presenting only a raw page count.

How to read the savings summary

Field	What it tells you
Net physical memory avoided	The estimated physical RAM no longer required after duplicate pages are merged and KSM's own bookkeeping cost is considered. Use this as the primary savings figure.
Estimated workload reduction	STRATUM's estimate of how much less physical memory the KSM-eligible workload is consuming because of deduplication. It describes workload efficiency, not additional RAM assigned to the VMs.
Host RAM reclaimed	Net memory avoided as a percentage of the host's total physical RAM. This shows whether deduplication is materially changing whole-host capacity.
Gross deduplicated pages	The raw duplicate memory represented by merged page copies before net KSM overhead is deducted. Gross savings can therefore be higher than net physical memory avoided.
KSM state	`Running` means the kernel scanner is actively looking for mergeable pages. The dashboard headline is shown only while KSM is running.
Completed scans	The number of complete passes KSM has made through its registered memory areas. This normally increases over time and confirms the scanner is progressing.

Kernel counters and scan behavior

Field	Meaning
`Net calculation`	Identifies the source used for the net estimate. `kernel_general_profit` means the host kernel supplied its KSM general-profit calculation.
`Shared physical pages`	The number of physical pages currently retained as shared KSM pages.
`Eliminated page copies`	The duplicate page copies currently replaced by those shared pages. This is the main raw indication that consolidation is occurring.
`Zero pages eliminated`	Pages consolidated through the kernel's shared zero-page behavior. A value of zero is expected when `use_zero_pages` is disabled or no eligible zero pages are present.
`Pages per scan batch`	The current `pages_to_scan` setting. A larger value searches memory faster but can consume more CPU.
`Sleep between batches`	The current `sleep_millisecs` delay. A shorter delay makes KSM more aggressive; a longer delay reduces scanner overhead.
`Merge across NUMA nodes`	When enabled, identical pages may be merged across NUMA nodes for greater savings. NUMA-sensitive systems should balance that gain against memory locality.
`Use kernel zero pages`	Shows whether the kernel may merge eligible empty pages into the shared zero page.

Workloads that usually benefit most

Multiple VMs built from the same image, similar operating systems, repeated application stacks, VDI pools, and other environments with substantial identical anonymous memory.

Workloads that may show little savings

Encrypted or compressed memory, highly diverse guests, rapidly changing working sets, and applications whose pages contain mostly unique data.

Enable, tune, and observe

Enable hostSetup.ksm in Host Setup, then plan and apply the host change. hostSetup.ksmPages controls the number of pages examined in each batch, and hostSetup.ksmSleepMilliseconds controls the pause between batches.

sudo stratum-host config set hostSetup.ksm true
sudo stratum-host plan
sudo stratum-host apply --yes
sudo stratum-host verify

Return to this page after workloads have been running long enough for KSM to complete several scans. Press R to refresh. Savings can rise or fall as VMs start, stop, modify shared pages, or change their working sets.

Measure before increasing scan aggressiveness. KSM exchanges CPU time for memory density. It can be valuable on trusted, similar VM fleets, but it should be evaluated carefully for latency-sensitive systems and across mutually untrusted security boundaries.

stratum-host Memory Deduplication page showing KSM savings, scan progress, and tuning values — The Memory Deduplication page separates practical host-memory savings from the underlying KSM counters and scan settings.

13 TUI MenusHost SetupAdvanced Demo Data & Advanced Synthetic capabilities, development-only bypasses, compatibility controls, and debug startup.

Demo Data

demo.enabled enables STRATUM demonstration data and synthetic capabilities, including simulated GPU Fabric. It is intended for demonstrations, development, and scale testing and is disabled by default.

Advanced

Setting	Meaning
`security.adminDevelopmentBypass`	Passes `STRATUM_ADMIN_DEV_BYPASS=1` into the STRATUM container. Development only; never enable it on production systems.
`compatibility.hostID`	Eight-hex-character Cisco IOL compatibility host ID. It is unrelated to the worker FQDN or Continuum identity.
`compatibility.hostIDEndian`	Uses native or reversed byte order for the legacy IOL host ID.
`runtime.debug`	Starts an interactive shell using the image entrypoint override instead of normal STRATUM startup.

Advanced means exceptional. These settings exist for qualified compatibility, diagnostics, or development, not normal installation.

Controller Services are intentionally not exposed in the current customer-facing TUI or CLI. Reserved service schema remains in the source for future work, but the 1.0 host manager hides those placeholders rather than presenting non-functional controls.

stratum-host Demo Data menu — Demo Data configuration in stratum-host.

14 TUI PagesOperationsStatus Host actions and deployment roles Inspect one host action at a time and keep implemented roles separate from reserved ones.

Host Action Status

This page shows whether each enabled host feature is already correct, needs change, is disabled, or requires a reboot.

Key	Action
`↑ ↓` or `j k`	Select an action.
`Enter`	Inspect details.
`Space`	Enable or disable the selected action in configuration.
`P`	Plan only the selected action.
`A`	Apply only the selected action.

Deployment Roles

Role	Current behavior
controller	Runs the control plane and includes the local native executor; remote workers join through authenticated STRATUM Continuum enrollment.
worker	Provides compute, memory, network, KVM, and GPU capabilities to the native STRATUM execution fabric.
storage	Runs a dedicated STRATUM Storage replica container with its own identity, container name, persistent path, and host UDP port. Storage communication is over STRATUM Continuum.
fabric-gateway	Reserved. Configuration is visible, but startup is intentionally blocked.
failover-controller	Reserved. Configuration is visible, but startup is intentionally blocked.

A worker and storage container may share one physical host when they use separate configuration files, container names, storage roots, and non-conflicting storage.connectHostPort values.

stratum-host Host Action menu — Host Action Statusconfiguration in stratum-host.

15 Architecture NoteOperationsPersistent data Storage for STRATUM The platform automates VM storage access; you provide the durable, performant application storage beneath it.

STRATUM manages VM storage access through its platform storage layer and can also run a dedicated storage role as a Continuum iSCSI replica. The operator does not manually connect each VM disk, but the durable host or platform storage beneath STRATUM remains an infrastructure responsibility.

STRATUM is Datacenter as an Application. Applications need storage. Give storage.root durable, adequately sized, protected, and fast storage; STRATUM handles the rest of the virtual-datacenter relationships.

Standalone Linux

The default persistent root is /persistent/stratum. Back it with the design appropriate to the deployment: fast local SSD/NVMe, RAID, DAS, a NAS mount, SAN-backed filesystem, or another qualified backend. Capacity, latency, redundancy, snapshots, backups, and disaster recovery remain infrastructure decisions.

Kubernetes

Use the appropriate PersistentVolume and StorageClass design. Kubernetes can mount the storage into the STRATUM workload, but the cluster operator must still select the performance, topology, access mode, backup, and retention behavior.

Inspect and repair

stratum-host storage status
sudo stratum-host storage fix-permissions

The permission repair resolves the numeric STRATUM UID/GID from the installed OCI image, preserves root ownership for native execution state under var/lib/stratumd, keeps service-owned mutable data correctly owned, and never changes certificate files.

Do not size only for the container image. Persistent state can include databases, virtual datacenters, templates, VM disks, snapshots, Arsenal content, logs, certificates, and recovery-critical configuration.

16 OperationsOperationsLifecycle Start, stop, reconcile, verify, and view logs Daily commands keep the container predictable without hiding persistent state.

Normal lifecycle

sudo stratum-host start
sudo stratum-host stop
sudo stratum-host restart
sudo stratum-host start --reconcile
sudo stratum-host restart --reconcile

--reconcile recreates a container when the selected image or configuration has drifted, while retaining persistent data. Image drift is the local container image being updated, or a container registry with a new updated STRATUM image. Just as regular containerized applications get new updates or pushing updates to a Kubernetes cluster.

Status and logs

stratum-host status
stratum-host status --deep
stratum-host status --json --strict
stratum-host logs --tail 200
stratum-host logs --follow

status --deep includes relevant listening sockets and the tail of the in-container supervisor log. Container output is available through stratum-host logs. Persistent logs normally appear below <storage.root>/var/log, which is /persistent/stratum/var/log with defaults.

Validation and drift

stratum-host config validate
stratum-host config diff
stratum-host verify
stratum-host verify --json

Create a support bundle

sudo stratum-host support bundle
sudo stratum-host support bundle --output /tmp/stratum-support.tar.gz
sudo stratum-host support bundle --json

The bundle is role-aware and sanitized: it collects host configuration, status, diagnostics, container output, and selected persistent logs/state while excluding VM disks/images, credentials, certificates, enrollment tokens, licenses, and embedded database files. Review the archive before sending it to support.

Remove the container, not the data

sudo stratum-host remove --yes

Removal deletes the configured container. Persistent host data and certificates are retained.

17 ReferenceCli ReferenceComplete CLI arguments and usage Every supported command in the reviewed stratum-host source.

Global options must appear before the command:

stratum-host [--config PATH] [--set KEY=VALUE] COMMAND

Command	Purpose
`stratum-host` / `tui`	Open the interactive host manager.
`help [COMMAND]`	Show general or command-specific help.
`start [--reconcile]`	Create/start the configured controller, worker, or storage container; optionally recreate drifted configuration.
`stop`	Stop without deleting the container.
`restart [--reconcile]`	Stop and start; optionally recreate drifted configuration.
`remove --yes`	Remove the configured container while retaining persistent data and certificates.
`status [--json] [--strict] [--deep]`	Show resolved deployment, runtime, certificates, hardware, network, host actions, reboot state, and-when deep-relevant sockets and supervisor-log tail.
`logs [--follow\|-f] [--tail N]`	Show Docker/Podman container output.
`plan`	Run the same enabled host-action engine as apply using dry-run operations.
`apply --yes`	Apply enabled host actions. Root is required.
`verify [--json]`	Check every enabled host feature without changing the host.
`config init [--force]`	Create a default YAML configuration.
`config show`	Print the current YAML configuration.
`config validate`	Validate registered settings and resolved deployment requirements.
`config diff`	Show differences from registered defaults.
`config settings`	List registered customer-facing settings grouped by section with their defaults.
`config set KEY VALUE`	Persist one registered setting atomically to the selected configuration file.
`cert status [--json]`	Inspect local controller certificates or live worker controller trust.
`cert trust [--json]`	Perform controller TLS trust inspection using the configured controller CA.
`cert ensure`	Create/preserve self-signed material or validate external certificate mode. Root required for creation.
`network status [--json]`	Show pnet mode, addresses, uplink, and pending rollback state.
`network cleanup [--json]`	Inspect orphaned STRATUM runtime bridges and TAP/TUN interfaces.
`network cleanup --yes [--json]`	Delete eligible orphaned STRATUM network devices. Root required; refuses while STRATUM containers are running.
`network confirm` / `network rollback`	Confirm or manually revert a pending physical-bridge rollback transaction.
`storage status [--json]`	Inspect persistent storage ownership and mount-root modes.
`storage fix-permissions`	Repair current mixed persistent ownership. Root required.
`support bundle [--output PATH] [--json]`	Create a sanitized, role-aware `.tar.gz` diagnostic bundle.
`ksm status [--json]`	Show Kernel Same-page Merging state and memory-deduplication telemetry.
`pci list [--json]`	List PCI BDF, vendor/device IDs, class, driver, IOMMU group, and boot-VGA state.
`gpu list [--json]`	List physical GPUs and their current STRATUM assignment.
`gpu show <BDF\|UUID\|index> [--json]`	Inspect one GPU selected by PCI BDF, UUID, or index.
`gpu assign <BDF\|UUID\|index> fabric\|passthrough\|host`	Persist GPU Fabric, direct-passthrough, or Host Only assignment. Apply afterward; passthrough changes require reboot.
`gpu verify [--json]`	Verify GPU assignment plus NVIDIA driver/toolkit/runtime readiness when GPU Fabric devices are present.
`roles`	List implemented and reserved deployment roles.
`version`	Print application version and build revision.

Global options

Option	Behavior
`--config PATH`	Use an alternate configuration file, such as a dedicated storage-role YAML.
`--set KEY=VALUE`	Repeatable one-run override. It does not modify `host.yaml`.

Configuration precedence is: built-in defaults, saved YAML, supported environment variables, then one-run --set overrides. Use config set for a persistent change.

Native execution is the worker dispatch path. QEMU and STRATUMSwitch workloads are handled directly by STRATUM. Workers authenticate through Continuum; the controller also has a local executor.

18 ExamplesAutomationCLI Automation patterns Use the same plan, apply, verify, and reconcile model from one host to an enterprise fleet.

Automation-safe host preparation

sudo ./stratum-host --config ./host.yaml plan
sudo ./stratum-host --config ./host.yaml apply --yes
sudo install -m 0755 ./stratum-host /usr/local/sbin/stratum-host
sudo install -m 0600 ./host.yaml /etc/stratum/host.yaml
sudo stratum-host config validate
sudo stratum-host verify --json
sudo stratum-host start --reconcile
sudo stratum-host status --json --strict

For unattended runs, treat a non-zero exit as failure and retain the plan output with the change record.

One-run overrides

sudo stratum-host \
  --set role=worker \
  --set identity.site=us-east \
  --set network.pnetMode=routed \
  start --reconcile

These values affect only that invocation. Persist them with config set or write the desired YAML through your preferred configuration-management system.

Separate worker and storage containers on one host

sudo stratum-host --config /etc/stratum/host.yaml start --reconcile
sudo stratum-host --config /etc/stratum/storage.yaml start --reconcile

Give the storage configuration its own container name, persistent role directory, node identity, and unique storage.connectHostPort.

Recommended pattern: configuration management copies the binary, OCI tarball, YAML, controller CA, and enrollment material; runs plan; applies approved host changes; starts with --reconcile; then records JSON verification and status.

No matching sections.Try a broader term or clear the category filter.

Helm chart details

STRATUM / KUBERNETES

Prepare the cluster. Deploy the datacenter.

The STRATUM Helm chart deploys a persistent controller and an optional worker fabric onto Kubernetes nodes that have already been prepared for virtualization, Continuum networking, provider networking, and host-level device access.

15 sections shown

01 GuideKubernetesStart here What this Helm chart deploys Kubernetes runs STRATUM; node preparation remains outside Kubernetes.

The chart deploys one STRATUM controller StatefulSet and, optionally, one worker DaemonSet. It generates each role’s /etc/stratum/host.yaml, mounts certificates and enrollment material from Secrets, initializes controller storage, and schedules STRATUM on prepared nodes.

STRATUM 1.0 uses native execution. Resource-aware placement, accounting, worker commands, QEMU/switch lifecycle, and display state are handled by STRATUM itself. No external scheduler, authentication daemon, or general-purpose SQL service is required for workload execution or display state.

Host preparation

stratum-host
Golden image
Ansible / Puppet / Chef
Node provisioning

Prepare KVM, TUN, pnet0, IOMMU/VFIO, GPU drivers, firewall policy, kernel settings, and the host itself.

Kubernetes runtime

Helm
StatefulSet controller
DaemonSet workers
PVC + Secrets + Services

Schedule and operate the already-prepared STRATUM infrastructure workload.

This is not a normal restricted application pod. STRATUM needs privileged host access, host networking, host PID visibility, KVM, TUN, and selected host filesystems. Use Kubernetes you control. Locked-down managed services commonly block one or more required capabilities.

STRATUM helm chart requires Kubernetes 1.25+.

02 ChecklistBefore InstallRequired Kubernetes prerequisite checklist Complete these items before running Helm.

Requirement	What to verify
Controlled cluster	The cluster permits privileged infrastructure pods, `hostNetwork`, `hostPID`, hostPath devices, and the required namespace security policy.
Virtualization	Selected nodes expose `/dev/kvm`. Hardware virtualization must be enabled, and nested virtualization must be available when Kubernetes itself runs in VMs.
Continuum networking	Selected nodes expose `/dev/net/tun`, can resolve the controller hostname, and permit the STRATUM ports between nodes.
Provider network	`pnet0` is prepared on every selected node when VMs need provider/LAN access. Helm only checks it; Helm never creates it.
Persistent storage	A default StorageClass exists, a chart-specific StorageClass is selected, or an existing PVC is supplied.
Image availability	The STRATUM OCI image is in a reachable registry, authenticated with an imagePullSecret, or preloaded on every selected node.
Placement labels	Exactly one controller node has `stratum.io/role=controller`; worker nodes have `stratum.io/role=worker`.
DNS and TLS	`stratum.publicHost` resolves where users and workers need it, and the controller certificate matches that hostname.

Useful node checks

test -c /dev/kvm && echo KVM-ready
test -c /dev/net/tun && echo TUN-ready
ls -ld /sys/class/net/pnet0/bridge
kubectl get storageclass
kubectl get nodes --show-labels

Do not make Helm discover these failures for you. Validate the cluster and nodes first, especially storage binding, KVM, TUN, pnet0, and namespace policy.

03 GuideStorageCritical Give STRATUM persistent storage The controller PVC is the Kubernetes equivalent of the host’s persistent STRATUM directory.

STRATUM is a datacenter as an application. Like any stateful application, it needs durable storage. The chart uses one controller PVC and mounts persistent state into the runtime for:

/stratum/var                     # core state, execution/accounting SQLite, display SQLite, Connect state + logs
/stratum/labs
/stratum/data
/stratum/arsenal
/stratum/config/configuration.yml
/stratum/config/users.yml
/stratum/proxy/certs             # self-signed mode

Size and performance matter. The current STRATUM controller serves VM storage for the fabric. The PVC backend must be appropriate for VM templates, ISO images, virtual disks, SQLite state, and normal controller state. A small or slow general-purpose volume may deploy successfully but perform poorly in real use.

Workers persist locally, not on the controller PVC. Each worker mounts host path /var/lib/stratum/worker at /stratum/var so STRATUM Connect identity and native executor reconciliation/dedupe state survive worker pod restarts.

Value	Meaning
`controller.persistence.enabled`	Keep controller state outside the replaceable OCI image. Leave enabled for normal deployments.
`initialize`	Seed image defaults into empty PVC paths. Existing content is never overwritten during upgrades.
`storageClass`	Select the Kubernetes storage backend. Empty uses the cluster default.
`existingClaim`	Mount a PVC you created and manage separately.
`accessModes`	Defaults to `ReadWriteOnce`, which matches a single controller pod.
`size`	Defaults to `100Gi`. Treat that as a demo starting point, not a production sizing recommendation.

Production storage questions

Is the backend fast SSD/NVMe, RAID, SAN, NAS, or another persistent platform suitable for VM I/O?
Can the volume reattach if the controller is rescheduled, or must the controller remain pinned to one node?
Are snapshots, backups, replication, capacity monitoring, expansion, and reclaim policy configured?
Does the backend have enough capacity for future templates, ISO images, VM disks, and SQLite/controller-state growth?

controller:
  persistence:
    enabled: true
    initialize: true
    storageClass: fast-rwo
    accessModes: [ReadWriteOnce]
    size: 2Ti

STRATUM handles the virtual datacenter above this layer. Kubernetes and your storage platform remain responsible for the durability and performance of the PVC beneath it.

04 RunbookCluster SetupPrivileged Prepare the namespace Pod Security Admission must permit STRATUM’s host-level runtime.

Create and label the namespace before installation. Using only helm --create-namespace does not add the required Pod Security labels.

kubectl create namespace stratum
kubectl label namespace stratum \
  pod-security.kubernetes.io/enforce=privileged \
  pod-security.kubernetes.io/audit=privileged \
  pod-security.kubernetes.io/warn=privileged

On OpenShift, grant the chart ServiceAccount an approved privileged SCC according to your organization’s policy.

ServiceAccount tokens are off by default. serviceAccount.automountServiceAccountToken=false because STRATUM does not need to call the Kubernetes API for normal operation.

Security boundary: the chart defaults to privileged execution, hostNetwork: true, hostPID: true, host /sys, host cgroups, /dev/kvm, and /dev/net/tun. Review this as an infrastructure workload, not as a tenant application.

05 RunbookNode SetupBefore Helm Prepare and label controller and worker nodes Use stratum-host or your own node automation, then control placement with labels.

The chart intentionally disables all hostSetup actions inside the pod. Prepare each selected node before it can run STRATUM.

# On each selected node
sudo stratum-host plan
sudo stratum-host apply --yes

# Kubernetes placement
kubectl label node ctrl1 stratum.io/role=controller
kubectl label node worker001 stratum.io/role=worker

Do not label the controller node as a worker. Both roles use host networking and may contend for fixed STRATUM ports. The chart deliberately pins the controller away from worker-labelled nodes.

What node preparation must handle

Layer	Handled outside Helm
Firmware and kernel	BIOS virtualization, KVM modules, IOMMU, VFIO readiness, kernel tuning, KSM, and device permissions.
Networking	pnet0 bridge or routed provider network, firewall rules, MTU planning, and any physical uplink changes.
GPU	GPU drivers, IOMMU grouping, VFIO binding, and selection of host-display versus passthrough devices.
Image delivery	Container image registry access, registry credentials, or image preload on disconnected nodes.

Golden images, Cluster API bootstrap, MachineConfig, Ansible, Puppet, Chef, Terraform-driven provisioning, or another fleet system may replace direct use of stratum-host as long as the resulting node contract is the same.

06 GuideNetworkingHost prepared pnet0, host networking, DNS, and ports Helm describes the expected network; the node supplies it.

hostAccess.hostNetwork=true is required and enforced by the chart. STRATUM binds directly to the Kubernetes node network rather than relying only on pod-network address translation.

Bridge mode

VM → pnet0 → physical LAN

Default VMware-style behavior. Prepare the physical bridge on each node. Initial host setup may interrupt SSH while the uplink moves under the bridge.

Routed mode

VM → pnet0 → host routing/NAT → uplink

Cloud- and SSH-safe mode. The management NIC remains intact, prioritizing node reachability during setup.

# Cloud-safe node preparation
sudo stratum-host config set network.pnetMode routed
sudo stratum-host plan
sudo stratum-host apply --yes

The Helm values must match the already-prepared host:

stratum:
  network:
    pnetMode: bridge       # bridge or routed
    pnetBridgeName: pnet0

hostAccess:
  pnet:
    requireExisting: true

requireExisting adds an init-container check for /sys/class/net/pnet0/bridge. It fails fast when the bridge is absent or not a Linux bridge. It does not create, convert, repair, or reconfigure anything.

Public controller Service

Port	Use
`8443/TCP`	STRATUM web/API, worker enrollment, and the authenticated native worker execution channel. This port is currently fixed by chart validation.
`51820/UDP`	Default STRATUM Connect / Continuum transport when enabled. Configure with `stratum.connect.port`.

No scheduler ports are published. Remote workers initiate HTTPS to the controller and keep an authenticated command request held open. There is no worker-side scheduling/control listener; worker commands use the authenticated outbound HTTPS channel.

Host-network runtime listeners

Port	Role / purpose
`14833/TCP`	GPU gateway on execution nodes.
`18081/TCP`	Storage-agent path where used.
`18082/TCP`	Controller runtime-state service.
`3260/TCP`	iSCSI path where used.
`20000-40000/TCP`	Dynamic console and management forwarding.
`4789/UDP`	VXLAN when Continuum networking is enabled.

These host-network listeners are not automatically exposed as Kubernetes Services. Helm does not create firewall rules; restrict fabric/runtime listeners to Continuum or approved STRATUM peers. Ensure workers can resolve the certificate-matched controller hostname and reach 8443/TCP.

07 GuideImagesOCI Make the STRATUM image available Use a versioned registry image, a digest, or preload it for disconnected operation.

Value	Use
`image.repository`	Registry path or local image name.
`image.tag`	Release tag. Pin a tested version in production.
`image.digest`	Optional immutable digest; when set, it takes precedence over the tag.
`image.pullPolicy`	`IfNotPresent` for normal use; `Never` for preloaded disconnected nodes.
`image.pullSecrets`	Secrets used by Kubernetes to authenticate to a private registry.

Private registry

kubectl -n stratum create secret docker-registry stratum-registry \
  --docker-server=registry.example.com \
  --docker-username='USERNAME' \
  --docker-password='PASSWORD'

image:
  repository: registry.example.com/stratum/stratum
  tag: latest
  pullPolicy: IfNotPresent
  pullSecrets:
    - name: stratum-registry

Disconnected cluster

image:
  repository: stratum
  tag: latest
  pullPolicy: Never

Preload the exact image on every controller and worker node. The controller initialization container uses the same image and does not need internet access.

08 RunbookInstallController first Deploy the controller A production-friendly installation sequence begins with the controller and persistent storage.

1. Create production values

image:
  repository: registry.example.com/stratum/stratum
  tag: latest
  pullPolicy: IfNotPresent

stratum:
  publicHost: ctrl1.stratum.lab
  site: datacenter-a
  connect:
    enabled: true
    port: 51820
    payloadMTU: 1350
  execution:
    cpuShareFactor: 4
    memoryReserveMB: 1024
    accountingSampleSeconds: 30
    workerTimeoutSeconds: 180
    commandHoldSeconds: 25

controller:
  enabled: true
  certificates:
    mode: self-signed
  persistence:
    enabled: true
    initialize: true
    storageClass: fast-rwo
    size: 2Ti

workers:
  enabled: false

hostAccess:
  pnet:
    requireExisting: true

2. Validate rendering

helm lint ./stratum -f values-production.yaml
helm template stratum ./stratum \
  --namespace stratum \
  -f values-production.yaml > rendered.yaml

3. Install

helm upgrade --install stratum ./stratum \
  --namespace stratum \
  -f values-production.yaml

4. Confirm readiness

kubectl -n stratum get pods,pvc,svc
kubectl -n stratum get pods \
  -l app.kubernetes.io/component=controller
kubectl -n stratum logs \
  -l app.kubernetes.io/component=controller \
  -c stratum --tail=200

Open https://<stratum.publicHost>:8443/stratum/ after DNS, firewall policy, service exposure, and certificates are correct.

Initialization is one-time and non-destructive. The init container seeds empty PVC directories from the immutable STRATUM image, fixes ownership, and leaves existing data untouched on later upgrades.

09 GuideSecurityTLS Certificates, public DNS, and controller access The public hostname is part of both connectivity and certificate validation.

stratum.publicHost is used for the public URL, controller endpoint advertisement, STRATUM server name, and certificate expectations. Choose a stable hostname that users and workers can resolve.

Self-signed

controller:
  certificates:
    mode: self-signed

The controller creates demo CA, server, client, and PKCS#12 material in the persistent certificate directory.

External PKI

controller:
  certificates:
    mode: external
    existingSecret: stratum-controller-certs

Kubernetes mounts your supplied certificate Secret read-only. STRATUM does not overwrite it.

External certificate Secret

kubectl -n stratum create secret generic stratum-controller-certs \
  --from-file=ca.crt \
  --from-file=server-cert.key \
  --from-file=server-key.key \
  --from-file=client-cert.key \
  --from-file=client-key.key \
  --from-file=demo.p12

The certificate must match stratum.publicHost. A worker may reach the controller IP and still fail enrollment when the certificate name, public hostname, or CA is wrong.

The chart creates a controller Service for 8443/TCP and, when Connect is enabled, the configured Continuum UDP port, plus a headless Service for StatefulSet identity. Native worker enrollment and execution use the controller HTTPS endpoint; no separate worker-control Service is created. Configure controller.service.type and any platform-specific annotations when external service exposure is required.

10 RunbookWorkersTwo stage Add worker nodes Create enrollment material after the controller is available, then enable the DaemonSet.

Workers use STRATUM’s native execution manager. Each worker enrolls through STRATUM Connect, initiates HTTPS to the controller, and keeps an authenticated outbound command request available for immediate execution work. A self-signed controller plus workers is normally a two-stage deployment:

Deploy the controller with stratum.connect.enabled=true.
Generate or download enrollment material from the STRATUM administrator interface.
Create the worker Secret.
Enable workers and upgrade the release.

kubectl -n stratum create secret generic stratum-worker-enrollment \
  --from-file=stratum-enroll \
  --from-file=controller-ca.crt=ca.crt

stratum:
  connect:
    enabled: true
    controllerHost: ctrl1.stratum.lab   # optional when publicHost is the same name
  execution:
    cpuShareFactor: 4
    memoryReserveMB: 1024
    accountingSampleSeconds: 30
    workerTimeoutSeconds: 180
    commandHoldSeconds: 25

workers:
  enabled: true
  existingSecret: stratum-worker-enrollment
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 10%

helm upgrade stratum ./stratum \
  --namespace stratum \
  -f values-production.yaml

Each worker’s STRATUM identity comes from Kubernetes spec.nodeName. Use stable, unique Kubernetes node names and working controller DNS. Worker /stratum/var is backed by host path /var/lib/stratum/worker so Connect identity and executor reconciliation state survive pod replacement.

Native execution is controller-driven, but worker-initiated on the network. The controller does not dial a scheduler daemon on each worker. A held authenticated HTTPS request returns immediately when work is queued; the 60-second inventory heartbeat is not a command delay.

Workers-only release

A separate workers-only Helm release is supported. Set controller.enabled=false, keep stratum.connect.enabled=true, point stratum.connect.controllerHost (or stratum.publicHost) at the certificate-matched controller hostname, and configure workers.existingSecret.

11 GuidePlacementRegions Use sites to divide the enterprise fabric A site label groups workers into a region or facility for default VM placement.

stratum.site may be any useful region or facility name, such as:

default
us-east
boston
tokyo
taiwan
edge-plant-07

Workers report the site during enrollment. When a virtual datacenter or VM is deployed to that site, STRATUM can prefer the matching worker pool by default. This lets one enterprise fabric contain multiple geographic regions or operational zones while keeping placement intentional.

One Helm value applies to the release. All workers in the same release receive the same stratum.site. Use separate worker releases or separate clusters/values when worker groups must report different sites.

stratum:
  site: us-east

12 ReferenceConfigurationKey values Important values and why they matter The settings most operators should review before production installation.

Value	Plain-English meaning
`stratum.publicHost`	Browser- and worker-facing controller hostname. It must resolve and match the certificate.
`stratum.site`	Region/facility label reported by controller and workers.
`stratum.connect.*`	Enable STRATUM Connect, choose interface/UDP port/payload MTU, set heartbeat and startup timing, TLS behavior, and an optional worker-facing controller hostname.
`stratum.execution.cpuShareFactor`	Aggregate CPU sharing factor used by native placement/execution. Default `4` preserves STRATUM’s intended four-way CPU sharing.
`stratum.execution.memoryReserveMB`	Host memory reserved from workload placement on each execution node. Default `1024` MB.
`stratum.execution.accountingSampleSeconds`	Native execution/accounting sampling cadence. Default `30` seconds.
`stratum.execution.workerTimeoutSeconds`	How long the controller tolerates a missing worker before treating it as unavailable. Default `180` seconds.
`stratum.execution.commandHoldSeconds`	Duration of the worker’s held HTTPS command request. It returns immediately when work is queued; this is not added command latency.
`stratum.qemu.ioProcessing`	`compatibility` preserves existing launches; `auto` uses one shared IOThread per VM; `dedicated` uses per-virtio-blk IOThreads plus virtio-scsi.
`stratum.network.pnetMode`	Whether the already-prepared provider network is direct bridge mode or cloud-safe routed mode.
`stratum.network.nat*`	nat0 bridge, subnet, gateway, DHCP range, and DNS presented to NAT-connected guests.
`stratum.gpu.enabled`	Enable NVIDIA RuntimeClass/CDI integration for GPU Fabric.
`stratum.gpu.discovery`	`auto` inventories GPUs exposed to the pod; `off` disables runtime discovery.
`controller.nodeSelector`	Defaults to `stratum.io/role: controller`.
`controller.resources`	Kubernetes CPU and memory requests/limits. Define these for production scheduling and capacity control.
`controller.service`	Controls ClusterIP, LoadBalancer, annotations, traffic policy, and optional load-balancer IP.
`workers.nodeSelector`	Defaults to `stratum.io/role: worker`.
`workers.resources`	Requests/limits for each worker pod. Avoid limits that starve host-level virtualization workloads.
`hostAccess.pnet.requireExisting`	Fail fast if the configured pnet bridge is absent.
`serviceAccount.automountServiceAccountToken`	Defaults false because normal STRATUM runtime does not need Kubernetes API credentials.

Generated host configuration is read-only. Helm renders /etc/stratum/host.yaml from values. Make persistent changes in values and run helm upgrade; do not edit the file inside the pod.

13 GuideHardwareOptional GPU, VFIO, host devices, and extra mounts The chart exposes prepared hardware; it does not configure the hardware for you.

Value	Meaning
`hostAccess.devices.kvm`	Mount `/dev/kvm` for hardware-accelerated virtual machines. Enabled by default.
`hostAccess.devices.tun`	Mount `/dev/net/tun` for the STRATUM Continuum. Enabled by default.
`hostAccess.devices.vfio`	Mount the host `/dev/vfio` tree for devices already bound to VFIO. Disabled by default.
`stratum.gpu.enabled`	Enable the NVIDIA RuntimeClass/CDI integration used by STRATUM GPU Fabric.
`stratum.gpu.discovery`	`auto` inventories GPUs visible to STRATUM; `off` disables runtime discovery.
`stratum.gpu.runtimeClassName`	Kubernetes RuntimeClass used when GPU integration is enabled. Default `nvidia`.
`stratum.gpu.assignmentHostPath`	Node-local GPU assignment file generated by `stratum-host apply`. Default `/etc/stratum/gpu-assignments.env`.
`hostAccess.extraVolumes`	Add Kubernetes volumes not modeled by the chart.
`hostAccess.extraVolumeMounts`	Mount those additional volumes into the STRATUM container.

stratum:
  gpu:
    enabled: true
    discovery: auto
    runtimeClassName: nvidia
    assignmentHostPath: /etc/stratum/gpu-assignments.env

hostAccess:
  devices:
    vfio: true   # only when direct QEMU passthrough devices are used

GPU assignments stay node-local. Fabric, Passthrough, and Host Only assignments are prepared independently on each node by stratum-host. Do not put PCI BDFs into Helm values.

Enabling VFIO is not VFIO setup. The node must already have IOMMU enabled, devices isolated into acceptable IOMMU groups, the intended PCI functions bound to vfio-pci, and any host-display GPU decisions resolved before the pod starts.

The optional runtime socket mount is disabled by default. Enable it only for a specific supported integration that truly needs a local Docker-compatible socket; exposing the host container socket gives the pod broad host control.

14 GuideSecretsOptional Licensing and sensitive material Use Kubernetes Secrets for certificates, enrollment, registry credentials, and optional license files.

Secret	Required keys
Controller certificates	`ca.crt`, `server-cert.key`, `server-key.key`, `client-cert.key`, `client-key.key`, and `demo.p12`.
Worker enrollment	`stratum-enroll` and `controller-ca.crt`.
Controller license	`stratum.license`, referenced by `controller.licenseSecret`.
Worker license	`stratum.license`, referenced by `workers.licenseSecret`.
Registry	Standard Kubernetes Docker registry authentication Secret referenced by `image.pullSecrets`.

kubectl -n stratum create secret generic stratum-controller-license \
  --from-file=stratum.license

# values.yaml
controller:
  licenseSecret: stratum-controller-license

When a license Secret is not supplied, STRATUM uses its persistent license path under /stratum/var/lib/stratum-license/. Keep Secrets out of values files and source control.

15 ReferenceOperationsDay two Upgrade, inspect, roll back, and troubleshoot Use Helm for desired state and Kubernetes for runtime inspection.

Common operations

# Current values and release history
helm -n stratum get values stratum
helm -n stratum history stratum

# Upgrade
helm upgrade stratum ./stratum \
  --namespace stratum \
  -f values-production.yaml

# Inspect
kubectl -n stratum get pods,pvc,svc -o wide
kubectl -n stratum describe pod <pod-name>
kubectl -n stratum logs <pod-name> -c stratum --tail=300

# Roll back chart resources
helm -n stratum rollback stratum <revision>

Symptom	Check first
Controller pod stays Pending	Controller node label, PVC binding, StorageClass, node affinity, taints/tolerations, and privileged admission.
pnet preflight fails	The configured bridge does not exist on the scheduled node or is not a Linux bridge. Prepare the node; do not try to repair it from Helm.
Pod fails to create	`/dev/kvm`, `/dev/net/tun`, `/sys`, cgroups, and optional `/dev/vfio` hostPath availability.
Worker will not enroll or execute	`stratum.connect.enabled=true`, worker Secret keys, controller CA, enrollment token, controller DNS/certificate hostname, and outbound `8443/TCP`. The worker does not need an inbound scheduler/control port.
Remote VM fabric is broken	Configured Continuum UDP port, `4789/UDP` where VXLAN is used, payload MTU, node firewall policy, and reachability between approved STRATUM peers.
UI is unreachable	`stratum.publicHost`, DNS, firewall, Service type/annotations, controller node reachability, and certificate validity.
Upgrade did not refresh seeded files	Expected behavior: initialization copies defaults only into empty destinations. Existing persistent data is preserved.
Managed Kubernetes rejects the chart	The platform may prohibit privileged pods, host networking, host PID, KVM/TUN, nested virtualization, or prepared pnet bridges.

Uninstall carefully

helm uninstall stratum --namespace stratum

Uninstall is not a backup policy. Verify the controller PVC and the StorageClass reclaim policy before deleting anything. Preserve or snapshot the volume when the virtual datacenter must survive chart removal.

Current chart boundaries

fabricGateway.enabled and failoverController.enabled are reserved placeholders and deliberately fail validation when enabled. The current chart deploys one controller replica; controller failover is not implemented by these values.

No matching sectionTry a broader search or clear the active filter.