Docs

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.

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 Continuum startup jitter spreads enrollment and heartbeat traffic instead of creating a synchronized burst.

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 are visible but reserved.
`execution.slurmScheduling`	Enabled sends VMs and STRATUM Switch jobs through managed workers. Disabled uses the direct/local legacy path.
`vm.ioProcessing`	Controls IOThread assignment for virtio-blk and virtio-scsi devices: `compatibility`, `auto`, or `dedicated`. The selected mode applies to newly started VMs.
`identity.nodeName`	Stable Continuum identity. `auto` uses controller host, worker FQDN, or a storage-specific name.
`identity.site`	Placement region or facility label used by scheduling.
`controller.host`	Controller FQDN or IP. Workers should normally use a resolvable FQDN.
`controller.ip`	Controller underlay IP. `auto` resolves the controller host or detects the controller IPv4 address.
`public.host`	Browser-facing hostname used by the UI, authentication layer, and certificate SANs.
`public.httpsPort`	HTTPS port. Current host-networked runtime uses `8443`.
`runtime.engine`	`auto` prefers a responsive Docker daemon, then Podman.
`runtime.image`	OCI image to run. Use a versioned release tag in production rather than an unpinned moving tag.
`runtime.containerName`	Docker or Podman container name. Use a separate name for a second storage container on the same 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 path for mutable STRATUM state. Default: `/persistent/stratum`.
`storage.persistControllerData`	Keeps datacenters, data, Arsenal content, and databases outside the replaceable image.
`storage.seedControllerData`	Copies image defaults into missing persistent paths on first deployment.
`storage.repairPermissions`	Aligns persistent path ownership with the numeric `stratum` UID/GID inside the selected image.

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 QEMU 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 the STRATUM Continuum agent. Disable only for an intentional LAN-only worker design.
`connect.interface`	Continuum interface name, normally `stratum0`.
`connect.port`	Continuum UDP port, normally `51820`.
`storage.connectHostPort`	Published Continuum UDP port for an isolated storage container. It must be unique when multiple storage containers share a host.
`connect.payloadMTU`	Payload MTU carried through the Continuum. Default `1350` avoids common overlay fragmentation.
`connect.pollSeconds`	Worker report or heartbeat interval.
`connect.meshPollSeconds`	Conditional mesh-state check interval.
`connect.startupJitterSeconds`	Random startup delay that spreads fleet enrollment and polling load.
`connect.insecureTLS`	Development escape hatch that weakens controller certificate verification. Leave false.
`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` / `pnetGateway`	Private subnet and gateway used only in routed pnet0 mode.
`network.pnetRollbackSeconds`	Bridge mode safety timer. If validation does not complete, the old uplink configuration is restored.
`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` / `natGateway`	Private NAT subnet and guest gateway.
`network.natDHCPStart` / `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 PciScheduling Workers & GPU Dynamic registration, job accounting, admission, GRES, and advanced GPU controls.

This menu controls worker scheduling, admission, accounting, and expert GPU overrides.

Setting	Meaning
`slurm.accounting`	Records worker job history for Compute Fabric reporting.
`slurm.accountingPort`	TCP port used by worker job accounting.
`slurm.jobAcctGatherFrequency`	Resource-sampling interval. Zero keeps job records but disables periodic samples.
`slurm.dynamicNodes`	true: workers register themselves dynamically. false: use legacy static worker definitions; the operator must manage worker host details manually in the Admin GUI worker configuration.
`slurm.maxNodeCount`	Controller capacity ceiling for worker records. The default is intentionally large.
`slurm.waitForFabric`	Prevents execution service admission until the Continuum is ready.
`slurm.admissionPollSeconds`	How frequently a worker rechecks Continuum execution admission.
`slurm.gres`	Raw Slurm Generic RESources override. Normally leave blank so the GPU menu and inventory generate it.
`slurm.gpuAutoDetect`	Optional Slurm discovery backend: nvidia, nvml, rsmi, or oneapi.
`slurm.dynamicConf`	Advanced raw dynamic-node configuration string.
`gpu.policy`	Fleet policy normally maintained by the GPU menu: auto, host-all, vfio-all, mixed, or disabled.
`gpu.vendor`	Limit discovery to NVIDIA, AMD, Intel, or any supported vendor.
`gpu.includeCompanionFunctions`	Includes audio/USB functions in the same PCI slot or safe IOMMU group when preparing passthrough.
`gpu.allowBootDisplayGPU`	Allows passthrough of the GPU currently serving the host console. Dangerous unless another console path exists.
`gpu.allowSharedIOMMUGroups`	Allows passthrough when unrelated devices share an IOMMU isolation group. Advanced and normally unsafe.
`gpu.runtimeDiscovery`	Controls runtime discovery. `vfio-all` resolves it off because devices are detached from vendor drivers.
`gpu.vfioDevices`	Host-specific PCI BDFs reserved for direct passthrough.
`gpu.hostDevices`	Host-specific GPUs intentionally excluded from STRATUM.

Dynamic Worker nodes

Keep slurm.dynamicNodes: true for normal scale-out. A new worker advertises its own CPU, memory, architecture, site, and GPU capabilities. Set it false only for an advanced static-node workflow where worker definitions are manually maintained.

What does GRES mean?

GRES means Generic RESources. STRATUM's scheduler service, Slurm, uses it for schedulable devices or capacity that are not ordinary CPU cores or RAM. STRATUM primarily uses it for GPUs.

gpu:a100:8

This means “the worker has eight schedulable GPUs of type A100.” A workload requesting A100 capacity will only be placed on an eligible worker with enough matching resources. Leave the override blank unless automatic inventory cannot represent a qualified custom resource.

stratum-host Workers and GPU menu — Workers & GPU 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 Controller Services, Demo Data & Advanced Know which switches are current, simulated, reserved, or development-only.

Controller Services

These controls describe the intended controller service boundary, but they are reserved placeholders in the latest STRATUM release and do not currently provision the services. That means these settings do nothing today.

Setting	Intended purpose
`controllerServices.chrony`	Controller-provided time synchronization.
`controllerServices.coreDNS`	Controller-managed DNS service.
`controllerServices.dhcp`	Provisioning or PXE DHCP. This is separate from the working `nat0` guest DHCP service.
`controllerServices.pxe`	PXE, TFTP, and HTTP boot provisioning.
`controllerServices.nfs`	Shared image or content exports.
`controllerServices.imageTools`	Controller-side disk and image conversion tooling.

Demo Data

demo.enabled adds synthetic capabilities, including simulated GPU Fabric, for demonstrations, development, and scale testing. It still exercises the real guest, STRATUM's virtualized hardware GPU device, lease, and STRATUM GPU Fabric paths, but it is not a performance substitute for physical GPU hardware.

Advanced

Setting	Meaning
`security.adminDevelopmentBypass`	Passes `STRATUM_ADMIN_DEV_BYPASS=1` into the STRATUM container for development-only admin startup or authentication testing. It may weaken the intended admin security boundary. Never enable it in production.
`compatibility.hostID`	Eight-hex-character Cisco IOL compatibility host ID. It is unrelated to the worker FQDN or Continuum identity. STRATUM neither endorses or ships with anything from Cisco.
`compatibility.hostIDEndian`	Uses native or reversed byte order for the legacy IOL host ID.
`runtime.debug`	Starts an interactive debug shell instead of the normal STRATUM startup path.

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

stratum-host Demo Data menu — Runtime 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 can also participate in workload execution when configured.
worker	Provides compute, memory, network, KVM, and GPU capabilities to managed scheduling.
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.

In the current production architecture, STRATUM serves VM disk I/O through controller-managed storage services. The operator does not manually connect each VM disk—the platform APIs handle that—but the underlying persistent storage is still your 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 and fixes mutable data ownership. It does not rewrite 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

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 container; optionally recreate drifted configuration.
`stop`	Stop without deleting.
`restart [--reconcile]`	Stop and start; optionally recreate drifted configuration.
`remove --yes`	Remove the container while retaining persistent data and certificates.
`status [--json] [--strict] [--deep]`	Show resolved role, runtime, certificate, hardware, network, host actions, sockets, and reboot state.
`logs [--follow] [--tail N]`	Show Docker/Podman container output.
`plan`	Run the same host-action engine as apply, but with dry-run operations.
`apply --yes`	Apply enabled host actions. Root is required.
`verify [--json]`	Check enabled host features without changing the host.
`config init [--force]`	Create a default YAML configuration.
`config show`	Print the resolved YAML.
`config validate`	Validate settings and resolved deployment configuration.
`config diff`	Show differences from defaults.
`config settings`	List every registry key, type, default, help text, and environment mapping.
`config set KEY VALUE`	Persist one setting atomically to the selected host.yaml.
`cert status\|trust\|ensure [--json]`	Inspect, verify, or create/validate certificate material.
`network status\|confirm\|rollback [--json]`	Inspect and control a pending physical-bridge rollback transaction.
`storage status\|fix-permissions [--json]`	Inspect or repair persistent storage ownership and modes.
`pci list [--json]`	List BDF, IDs, class, driver, IOMMU group, and boot-VGA state.
`gpu list [--json]`	List GPUs matching the configured vendor.
`roles`	List implemented and reserved 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.

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.

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.

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.

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.

Port	Use
`8443/TCP`	STRATUM web interface, APIs, and controller enrollment. This port is currently fixed by chart validation.
`51820/UDP`	Default STRATUM Continuum transport. The chart value is configurable.
`6817/TCP`	Worker scheduling/control service.
`6818/TCP`	Worker runtime service.
`6819/TCP`	Accounting service.

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.

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.*`	Continuum interface, UDP port, mode, payload MTU, TLS behavior, and optional controller hostname.
`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.slurm.dynamicNodes`	Automatically admit discovered workers. False requires manual worker definitions.
`stratum.slurm.maxNodeCount`	Maximum dynamically managed worker capacity. Default is `65536`.
`stratum.gpu.discovery`	`auto` inventories GPUs exposed to the pod; `off` disables 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.

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.discovery`	Discover GPUs visible from the host-mounted environment.
`stratum.slurm.gres`	Optional explicit Generic RESources declaration, such as `gpu:a100:8`: eight A100-class GPUs on that worker definition.
`stratum.slurm.gpuAutoDetect`	Optional lower-level GPU discovery override used by the current worker startup contract.
`hostAccess.extraVolumes`	Add Kubernetes volumes not modeled by the chart.
`hostAccess.extraVolumeMounts`	Mount those additional volumes into the STRATUM container.

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`.

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	Worker Secret keys, controller CA, enrollment token, controller DNS, certificate hostname, `8443/TCP`, and Continuum UDP connectivity.
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.

DATACENTER AS AN APPLICATION™

User Guide

Virtual Datacenters

Data Layers

System Arsenal

Selection Details

Right Click Menu

Snapshots

Migrate VM

Node Editor (runtime)

Node Editor (GPU)

VM Console

Removable Media (runtime)

All Nodes UI

STRATUM Switch

Link Impairment Profile

Edit Link Impairment

Interfaces

Execution

Storage

Arsenal Forge: Templates

Arsenal Forge: Image Create

Arsenal Forge: VM Images

Arsenal Forge: ISOs

STRATUM Ops

Administrator Guide

Compute Fabric

AI Accelerator Fabric

Network Fabric

License Management

Users

Roles

Groups

Sessions

Audit

Execution Hosts

Storage Fabric

DevSecOps Guide

Workload Layering

Move from VMware to STRATUM

System Requirements

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

Setup host

Setting up a few things on your Linux host

Deploy container

Everything STRATUM is deployed as a single container

Start container

Simple

Alternative: K8s deploy

STRATUM is a container, deploy it to Kubernetes

Prepare the cluster, then deploy with Helm.

Alternative: STRATUM Cloud

STRATUM appliances that boot STRATUM container

Stratum-host command (TUI & CLI)