DATACENTER AS AN APPLICATION™

STRATUM did not begin as another attempt to copy a rack of hypervisors and put a new dashboard in front of it. Its design grew from work emulating complex Navy and mission systems and from research into communications that could keep forming trusted links when conventional infrastructure became unavailable.

That problem is especially severe in MILSATCOM and multi-domain edge environments. Traditional systems can depend on IP addressing, routing, DNS, central configuration, and pre-established trust. In a contested, intermittently connected, or rapidly reconstituted environment, each dependency becomes another point of failure.

The original research direction

STRATUMvisor, as Cyber Ballistics, explored QEMU-emulated network interfaces and Ethernet multicast as a programmable communications substrate. The objective was to let virtual interfaces discover and exchange Layer 2 frames with minimal infrastructure, then bind cryptographic identity, mission context, anti-replay data, and policy enforcement to the communications path itself.

The associated research concept went further: authenticated frame formats, post-quantum signatures, eBPF/XDP validation, rootless packet capture, and lightweight AI-assisted policy at the edge. Those are separate research objectives—not a claim that every feature is present in today’s STRATUM release.

Tradecraft reclaimed for defense

A widely reported 2024 incident demonstrated that attackers could abuse legitimate QEMU networking backends to create a covert tunnel from a compromised pivot host into an isolated internal network. The incident proved that virtual networking primitives can quietly bridge segmented systems when misused.

What carried into STRATUM

• treat the network as a programmable part of the virtual datacenter;
• make topology executable instead of documenting it after the fact;
• reduce dependence on manual per-node configuration;
• carry identity and policy with the infrastructure relationship;
• design for datacenter, cloud, edge, lab, and disconnected operations from the same foundation.

Today’s STRATUM Continuum uses a routable encrypted Layer 3 worker mesh to carry VXLAN-backed Layer 2 virtual datacenter networks. The earlier post-IP MILSATCOM concept remains a related research direction. The common lineage is the same: communications should form around trusted systems and declared intent—not around fragile assumptions that every site already has perfect networking.

OCI means the Open Container Initiative, a Linux Foundation project that defines open standards for packaging, running, and distributing containers. Strictly speaking, an OCI image is the packaged artifact; a container runtime creates the isolated running process from that image.

The three core OCI specifications

• Image Specification: defines the manifest, configuration, metadata, and ordered filesystem layers that make up an image.
• Runtime Specification: defines the filesystem bundle and runtime configuration used to create, start, stop, and delete a container.
• Distribution Specification: defines the registry API used to push, discover, and pull manifests and content-addressed blobs.

Because these standards are open, STRATUM is not tied to one vendor’s image builder, registry, or runtime. A compatible tool can build the artifact, another can scan or sign it, a registry can distribute it, and a different compliant runtime can execute it.

Immutability by digest

An OCI image is identified by content. Change a file, configuration value, or layer and the resulting image receives a different digest. The old image is not edited in place. That gives STRATUM releases reproducible identity and enables precise statements such as “deploy this approved digest” or “roll back to the previous digest.”

OCI portability is a contract—not magic

OCI standardization does not make every image run on every machine regardless of hardware. A STRATUM node must still provide the correct CPU architecture, Linux capabilities, KVM, TUN/TAP, storage, networking, devices, and privilege boundary. OCI makes the artifact portable across compatible environments; STRATUM and its management app, stratum-host, verifies that the destination can actually operate it.

STRATUM templates do not have to be downloaded after the platform starts. During an image build, approved Arsenal template bundles can be placed into one or more new OCI filesystem layers and published as a new STRATUM image.

The original OCI image remains unchanged. Because the added template content changes the image, the build produces a new manifest and digest. Registries and offline archives can then distribute that complete artifact through the same release process used for STRATUM itself.

A purpose-built image could include:

• Windows and Linux VM templates;
• virtual switches and network operating systems;
• firewalls, routers, load balancers, and security appliances;
• mission applications, cyber-range systems, or site-specific golden images;
• complete template sets required by a predesigned virtual datacenter.

Layers make repeat distribution practical

When unchanged base and template layers retain the same digests, registries and local content stores can reuse them across releases. Only newly introduced or rebuilt blobs need to move. Keeping large templates in deliberately separated, stable layers improves cache reuse and makes low-bandwidth or disconnected (DDIL) distribution more manageable.

Yes. Arsenal bundles provide a convenient import and export format, but they are not the only way to distribute STRATUM templates. A build pipeline can place the template definition files, icons, firmware assets, and virtual-disk files directly into the expected STRATUM template locations while building a new OCI image.

Templates can be their own OCI layers

OCI images are assembled from content-addressed filesystem layers. A customer or integrator can keep the stable STRATUM platform layers unchanged and add one or more deliberate template layers containing Windows or Linux images, routers, firewalls, network operating systems, mission applications, or site-specific golden images.

When the image is updated and published, a normal docker pull or compatible OCI-runtime pull retrieves only blobs the local content store does not already have. If the STRATUM platform is unchanged and only the template layer changed, the update can consist primarily of the new or modified template content rather than retransferring the complete platform.

Existing STRATUM platform layers   — reused locally
Existing approved template layers — reused locally
New or changed template layer     — transferred
New image manifest                — transferred

The resulting OCI image receives a new digest, preserving an exact relationship between the STRATUM release and the template set delivered with it. Third-party operating-system and appliance redistribution rights still apply.

On June 22, 2026, Executive Order 14412 established a federal post-quantum transition timeline. It directs agencies to move High Value Assets and high-impact systems to post-quantum key establishment by December 31, 2030, and post-quantum digital signatures by December 31, 2031. It also directs the FAR Council to propose a rule requiring covered contractors to comply with applicable NIST FIPS—including post-quantum algorithms—by the end of 2030.

The immediate risk is not only a future quantum computer attacking future traffic. It is harvest now, decrypt later: an adversary stores encrypted traffic today, then waits for cryptanalytic capability to catch up. That matters most when data will remain sensitive for years—defense, government, finance, healthcare, telecommunications, intellectual property, and long-lived credentials.

Post-quantum protection should still be treated as an engineered transition, not a checkbox. Larger keys, signatures, certificates, and handshakes can affect high-connection-rate systems. Test connection setup, certificate chains, gateways, load balancers, older clients, and constrained edge systems.

STRATUM Continuum is a real mesh built on STRATUM’s own custom encrypted transport. Every eligible worker can become a direct encrypted fabric participant, so VM networks can span the entire STRATUM Continuum without forcing east-west traffic through the controller.

Each worker receives the enabled fabric peers, installs direct /32 peer routes, and programs VXLAN forwarding entries for the virtual networks it carries. The result is a distributed data path:

VM on Worker A
  → local tap / STRATUMswitch
  → VXLAN virtual network
  → STRATUM-connect encrypted mesh
  → direct UDP path to Worker B
  → destination VM

The controller remains the control point, identity authority, and fallback route. It is not required to remain the permanent packet path. Direct worker peers avoid persistent all-to-all keepalives, preventing a keepalive storm as the fleet grows.

Why is this different from Kubernetes CNI or VMware NSX?

Kubernetes CNI implements the Kubernetes pod-network contract. VMware NSX is a broad SDN and security suite for the VMware estate. STRATUM-connect is purpose-built for VMs, switches, routers, firewalls, storage paths, and complete virtual datacenters distributed across bare metal, clouds, laboratories, edge systems, and eligible Kubernetes nodes.

Both, at different layers. STRATUM Continuum establishes routable encrypted peer connectivity between workers at Layer 3 using STRATUM’s custom FIPS-oriented transport. STRATUM then carries VXLAN-backed Layer 2 networks across those peers for VMs and virtual datacenters.

This is not an application service mesh. Envoy, Istio, or Skupper operate higher in the stack around services and application flows. STRATUM Continuum operates transparently at the infrastructure layer, below the guest workload.

In Kubernetes, STRATUM is CNI-agnostic. Calico, Cilium, Flannel, or another CNI can carry the STRATUM node underlay. The STRATUM Continuum mesh then carries its own VM and virtual-datacenter fabric above it.

ZERO BORDERS is the operating effect of the STRATUM Continuum mesh. A bare-metal datacenter, an AWS VPC, a Kubernetes cluster, an edge appliance, a fleet of ships at sea, and a remote laboratory can remain separate physical environments while participating in one encrypted STRATUM fabric.

STRATUM does not erase routing, sovereignty, policy, or failure domains. It erases the operational border that normally forces each site to become a separate virtualization island.

• workers advertise reachable mesh endpoints;
• direct peers carry east-west traffic when available;
• the controller provides identity, policy, coordination, and fallback;
• VXLAN preserves the virtual datacenter networks above the routed underlay;
• site labels preserve placement and regional control.

The STRATUM Continuum mesh now recognizes STRATUM storage traffic, based on iSCSI, when either the source or destination TCP port is 3260. Classification covers IPv4, IPv4 options, IPv6, and common IPv6 extension headers.

Storage queue protection without wasted capacity

STRATUM keeps one efficient shared queue rather than adding a complicated scheduler. When storage is idle, ordinary VM and management traffic can use the entire queue. When storage becomes pending or active, normal traffic leaves a bounded reserve so disk I/O is not crowded out by a burst.

• Default queue depth: 1,024 packets
• Default storage reserve: 256 packets, or 25%
• Reserve bounds: at least two I/O batches and no more than half the queue
• Bounded storage wait: 250 microseconds by default; configurable to immediate-drop behavior

Storage and ordinary traffic are placed into separate ordered batches per peer. An outer UDP GSO datagram therefore never mixes iSCSI packets with ordinary VM or management packets, while per-peer order remains preserved.

DSCP AF41 by default

Outer storage datagrams are marked DSCP 34 / AF41. Ordinary Continuum traffic remains unmarked. STRATUM applies IP_TOS and UDP_SEGMENT in the same sendmmsg operation, preserving UDP GSO and avoiding an additional send system call. If the kernel rejects per-datagram marking, STRATUM disables the marking and continues the storage path rather than breaking I/O.

No protocol tax

protocol=stratum-connect-v3
crypto=p256-session-aes256gcm-sha256
pipeline=stratum-continuum-ordered-workers-storage
storage-port=3260
storage-reserve=256
storage-wait-us=250
storage-dscp=34
udp-gro=true
udp-gso=true
tun-vnet=true

There is no larger header, no second handshake, no new encryption operation, no per-packet HMAC, and no protocol-version bump. An authenticated flag identifies storage packets inside the existing protocol.

Production qualification matters

• Production FIPS toolchain: validate the exact build, approved cryptographic boundary, startup mode, and absence of an unapproved fallback path.
• Actual switch and cloud DSCP behavior: AF41 only creates value when the physical switch, VPC, virtual switch, or provider preserves and honors it. Verify with packet captures, queue counters, and congestion tests.

“Network segmentation first” sounds great until you are implementing NIST 800-207 in a cluster supporting both public-facing services and TS/SCI workloads. The problem is not the slogan. The problem is proving where every packet can go, which system can reach which resource, and what happens when the infrastructure changes.

Zero Trust STRATUM begins with explicit infrastructure. Every virtual switch, port, routed boundary, firewall, tenant, Virtual DataCenter (VDC), worker placement, storage path, and Continuum mesh relationship can be represented as part of the operating topology.

A powerful deployment can create concentric security rings:

• STRATUM virtual datacenters and network segmentation define the infrastructure boundary.
• STRATUM Continuum encrypts and authenticates worker-to-worker paths across sites.
• Calico, Cilium, or guest firewalls enforce Layer 3/Layer 4 workload policy where required.
• Envoy or a service mesh can enforce Layer 7 identity and application policy.
• STRATUMOPS exposes dependency paths, blast radius, desired-state drift, and the infrastructure behind an event.

DoW’s shift to immutable infrastructure—mandated in IL5+ environments—is exactly where STRATUM’s architecture becomes disruptive.

Traditional virtualization platforms become snowflakes through years of in-place change: packages, agents, plug-ins, scripts, manual switch edits, emergency firewall exceptions, and host-specific fixes. Every change expands drift and makes evidence harder.

STRATUM changes the unit of infrastructure. The platform is a versioned OCI image, and the virtual datacenter can carry the topology with it: templates, switches, routers, firewalls, ports, wiring, placement intent, network definitions, and infrastructure configuration.

Persistent VM disks, certificates, databases, logs, and customer data remain durable. Immutable does not mean stateless. It means the executable platform boundary is controlled, reproducible, and replaceable instead of continuously modified in place.

This brings infrastructure into DevSecOps: OCI registries, provenance, SBOMs, vulnerability remediation, release channels, policy gates, disconnected replication, and deterministic deployment. STRATUM is not merely running containers. STRATUM makes the datacenter itself behave like a modern application artifact.

CMMC enforcement is moving cybersecurity from policy language into contract evidence. Defense contractors must demonstrate that controls are implemented, operating, monitored, and maintained—not merely described in a System Security Plan.

STRATUM is designed to make the infrastructure evidence stronger:

• versioned OCI platform releases and virtual-datacenter definitions;
• SBOMs in SPDX and CycloneDX formats;
• continuous vulnerability scanning and remediation evidence;
• explicit network segmentation, tenant boundaries, and encrypted Continuum paths;
• repeatable host reconciliation with stratum-host plan and stratum-host apply --yes;
• template lineage and blast-radius analysis;
• desired-versus-running drift visibility;
• operational logs that can feed SIEM and assessment workflows.

For smaller Defense Industrial Base organizations, this matters because STRATUM consolidates virtualization, virtual networking, scheduling, encrypted fabric, topology, templates, GPU infrastructure, and operational dependency intelligence into one controlled platform rather than a patchwork of unrelated products.

STRATUM in a U.S. Federal environment

Federal approval is about the complete protection boundary. A hypervisor can launch VMs perfectly and still leave the customer rebuilding the compliance path around network crypto, host libraries, storage encryption, virtual firmware, Secure Boot, evidence, and configuration control.

VMware has invested in validated cryptographic modules and federal security documentation. Proxmox VE, built on Debian and open-source KVM components, does not ship the same out-of-box validated federal stack. Teams have obtained DCSA approval with Proxmox, but public practitioner reports describe compensating architectures such as BitLocker inside Windows VMs, LUKS inside Linux VMs, physical protection, VLAN isolation, and explicit approval by the DCSA assessor or authorizing official.

STRATUM Continuum is not WireGuard

STRATUM Continuum does not use the WireGuard protocol or WireGuard cryptographic suite since WireGuard does not utilize FIPS-algorithms. It is STRATUM’s own custom encrypted mesh transport, engineered around a production FIPS-oriented algorithm profile with P-256 session establishment, AES-256-GCM, and SHA-256. Standard WireGuard uses Curve25519, ChaCha20-Poly1305, and BLAKE2s—strong cryptography, but not the conventional FIPS-approved profile required by many federal programs. STRATUM created Continuum rather than forcing a federal infrastructure platform to inherit that limitation.

Why virtual UEFI matters

Open-source TianoCore/OVMF is powerful, but a stock OVMF package is not a federal-ready FIPS virtual-firmware stack. “KVM boots UEFI” is not the same as a controlled federal boot chain. EFI signing, PK/KEK/db enrollment, Microsoft compatibility certificates, revoked shims, FIPS-hardened guest kernels, firmware build provenance, and the exact Secure Boot path all affect approval. STRATUM controls that virtual firmware path instead of leaving it as an undocumented assembly exercise.

What FIPS actually means

FIPS is not a brand label for the entire datacenter. It is a validated cryptographic-module boundary used in an approved mode for the applicable protection function. Physical security, network separation, guest-native encryption, and defense-in-depth can still matter, but compensating controls must be documented and approved by the right authority.

STRATUM is built for this requirement. STRATUM is a U.S.-origin software platform developed, controlled, and released by Cyber Ballistics Inc. DBA STRATUMvisor—an independent United States company with no foreign parent or foreign-controlled product organization. STRATUM is offered as a TAA-compliant, U.S.-made software appliance for applicable federal, defense-contractor, and government-schedule procurements.

That matters because virtualization is not a minor line item. It becomes the operating foundation beneath compute, virtual networking, workload placement, storage access, GPU infrastructure, security boundaries, and mission applications. Selecting STRATUM can place a TAA-compliant American product at the center of that architecture instead of treating country-of-origin compliance as an afterthought.

The STRATUM advantage

• U.S.-origin core platform: STRATUM is developed and released by an American company without a foreign parent controlling the product.
• More capability under one compliant product: virtualization, virtual-datacenter networking, scheduling, encrypted Continuum connectivity, storage-fabric integration, GPU-fabric integration, and operational topology are delivered as one platform.
• Direct vendor accountability: procurement, engineering, product direction, and customer support trace back to the U.S. product company—not an overseas platform owner.
• OCI delivery: the approved STRATUM artifact can be versioned, scanned, signed, promoted, distributed, and replaced by digest through established DevSecOps and software-supply-chain processes.

A clear procurement boundary

STRATUM’s TAA representation applies to the STRATUM software product. Separately purchased servers, GPUs, switches, storage systems, network devices, third-party virtual appliances, and other products retain their own country of origin and should be verified by manufacturer part number. That is normal solution-level procurement practice—and it means the acquisition team can begin with a strong TAA-compliant software foundation rather than having to remediate the foundation later.

Applicable solicitation language, contract clauses, and contracting-officer determinations govern the final acquisition.

NIST SP 800-53’s audit and accountability controls require organizations to define which events are logged, ensure records contain useful information, review and analyze activity, protect records, and retain evidence. Manually opening individual logs is rarely enough at scale.

STRATUM can add infrastructure context around existing log platforms. A VM event can be correlated to its tenant, Virtual DataCenter (VDC), VM template lineage, disk, network attachments, worker placement, scheduler allocation, GPU dependency, and recent topology changes. That changes the question from “what did this host log?” to “what infrastructure dependency chain was involved?”

STRATUMOPS is designed to make this operational:

• surface desired-versus-running drift;
• show template blast radius;
• identify affected tenants and networks;
• trace an event through host, switch, fabric, storage, and workload relationships;
• export evidence to the organization’s SIEM, log-management, or assessment workflow.

STRATUM does not replace the SIEM or the organization’s AU control implementation. It improves the fidelity and explainability of the infrastructure evidence feeding those systems.

The Department of the Navy’s Containerization Technology Usage Memorandum established a software-container policy for new development and modernization across covered cloud environments, enterprise container platforms, and DevSecOps pipelines.

Most vendors hear “containerization” and answer: rewrite the application as microservices. STRATUM offers a more immediate and far more disruptive answer: containerize the virtual datacenter itself.

Existing VM-based mission applications, appliances, embedded-system toolchains, operating systems, and network assumptions can remain intact while the platform beneath them gains:

• OCI distribution and content-addressed releases;
• SBOMs, vulnerability scanning, signing, and provenance;
• Kubernetes deployment and mass scaling;
• portable virtual switches, routers, firewalls, wiring, and templates;
• repeatable deployment across cloud, lab, edge, shipboard, and disconnected environments.

Each STRATUM appliance keeps its normal AWS-managed interface and private address. That interface is the management path and the underlay endpoint for STRATUM-connect. VM-to-VM traffic is encapsulated between the EC2 instances rather than exposed to AWS as a separate interface for every guest.

EC2 instance private IPs
        ↓
STRATUM-connect encrypted peer mesh
        ↓
VXLAN-backed STRATUM virtual networks
        ↓
VMs, switches and virtual datacenters

Inside one VPC, no per-VM port-forwarding should be required for east-west STRATUM traffic when:

• the appliances are enrolled in the same fabric;
• security groups allow the required STRATUM control and fabric traffic between instances;
• the virtual network design avoids conflicting or ambiguous address ranges;
• MTU and routing are correct.

What about an Elastic IP or public ingress?

That is a separate routing problem. STRATUM-connect makes the internal fabric reachable between appliances (EC2 instances in Amazon AWS case); it does not automatically teach the public internet how to reach a VM subnet. Public ingress typically uses NAT, a load balancer, a proxy/firewall VM, or a VPC route that targets a STRATUM appliance ENI. When an EC2 instance forwards traffic that is not sourced from or destined to itself, AWS source/destination checking must be disabled for that appliance.

Physical bridge mode is the default for a conventional host. The physical NIC is attached to the STRATUM-created pnet0 bridge, giving VM and virtual-switch traffic the most direct path to the external Layer 2 network:

VM / tap → pnet0 bridge → physical NIC

Cloud-safe mode does not move the cloud-managed NIC under a Linux bridge. Instead, pnet0 remains a local attachment point and the host routes or NATs traffic to the physical interface:

VM / tap → pnet0 → host routing / NAT → cloud NIC

Cloud-safe mode is designed to reduce the chance of losing SSH, DHCP, metadata access, cloud-init behavior, or provider-managed routing during host preparation. This is critical in Cloud environments, where the IP is assigned by the cloud provider and it is not as easy to setup a bridged network device without dropping the network connection. The tradeoff is an extra Linux forwarding step. On modern systems that overhead is often modest, but packet rate, storage traffic, latency-sensitive workloads, and high-throughput east-west flows should be benchmarked.

Use physical bridge mode when you control the Layer 2 environment and need direct attachment. Use cloud-safe mode when preserving the provider-managed interface is more important than the last increment of raw network performance.

STRATUM Continuum is enabled by default because it provides the encrypted worker-to-worker mesh that carries the distributed virtual fabric, controller communication, console paths, and storage lanes across heterogeneous networks.

You can disable it where workers already share a trusted high-performance network, a Kubernetes CNI, a protected cloud underlay, or another approved transport. STRATUM can still use direct network reachability to the controller and participating services.

Turning off the mesh can reduce CPU overhead and increase throughput on CPU-constrained or already-protected networks. In Kubernetes or public cloud, evaluate the actual CNI/VPC encryption boundary, tenant model, compliance requirement, packet path, and threat model rather than assuming “the cloud encrypts it.”

Yes. STRATUM Live Wire applies network-topology changes to running systems. An operator can delete an existing wire and create a new connection from the selected VM interface to another STRATUMswitch, another switch port, or a different supported network attachment without shutting down the VM.

The guest operating system may briefly observe a link-down and link-up event while the connection changes. Existing sessions can be interrupted, and moving the interface to a different Layer 2 segment may require DHCP renewal, a compatible static address, updated routes, or other guest-network changes.

Live Wire changes the infrastructure connection immediately; it does not silently rewrite the guest’s IP configuration or application policy.

Current STRATUM storage supports both controller-hosted storage and dedicated storage-role STRATUM containers that join the platform and serve VM disks across the Continuum mesh.

A VM is bound to a storage owner and target. Compute placement can change without making the VM disk local to the worker. The storage path is carried over STRATUM’s iSCSI-aware Continuum Storage Lane, which adds queue protection, ordered storage batching, AF41 marking, and storage telemetry without introducing a second network.

Each storage role still needs a durable backend. Its /persistent path can be backed by mirrored NVMe, RAID, direct-attached flash, NAS, SAN-backed filesystems, or Kubernetes PersistentVolumes.

This design separates compute from storage while preserving portability: the scheduler can move a VM to another compatible worker, and the new worker reconnects to the VM’s assigned STRATUM storage target through the mesh.

Yes. STRATUM storage workers are designed as composable container roles. A storage worker can run beside a normal STRATUM compute worker, beside other STRATUM services, or beside additional storage workers on the same physical host.

This is useful when one server presents multiple independent host-level storage mounts—for example:

• a SAN-backed filesystem mounted for production VM disks;
• a direct-attached NVMe or RAID set for high-performance workloads;
• a second DAS volume for staging, replicas, or capacity-oriented storage;
• a NAS-mounted filesystem or another durable enterprise-storage tier.

Each container should receive its own role configuration, storage identity, persistent mount, service endpoint, and resource limits. This keeps the logical storage services separate even though they share the same Linux host and container runtime.

Running several storage workers on one host creates operational flexibility, but it does not create a separate physical failure domain. For high availability, replicas or redundant storage roles should also exist on other hosts or on an independently resilient backend.

A STRATUM VM is not permanently tied to the worker that launched it. Its durable disk remains on its assigned STRATUM storage service, while the worker supplies compute, memory, accelerators, TPM capability, CPU features, and network attachment.

Before using Move or Migrate, the VM must have no existing snapshots. Remove or consolidate the snapshot chain first, then retry the operation.

From the UI, an operator can:

• return the VM to the execution queue and let STRATUM choose an eligible worker;
• select a specific compatible worker;
• drain or disable a worker so supported workloads can be placed elsewhere.

Placement checks architecture, KVM support, CPU and RAM, GPU requirements, TPM support, CPU features, site, and other capability labels. Incompatible workers are excluded rather than presented as valid destinations.

Current production behavior is a controlled move: STRATUM stops the VM, reschedules it, reconnects its storage and Continuum networks, and restarts it on the destination worker.

We considered supporting migration with active snapshots, but chose the simpler architecture because it produces clearer behavior and fewer hidden dependencies at large scale. If snapshot-bearing migration is essential to your environment, contact STRATUMvisor so the requirement can be evaluated.

STRATUM does not make the browser schedule VMs. The UI expresses intent:

run at site aws-us-east-1
run on any x86_64 KVM worker
require an NVIDIA A100 capability
pin to this exact host only when requested

Workers advertise capabilities such as:

stratum_site_boston
stratum_site_aws_us_east_1
stratum_site_azure_eastus
stratum_kvm_x86_64
stratum_gpu_a100

The scheduler evaluates those facts as a high-performance compute grid. That distinction is what makes mass virtualization possible: the operator controls policy and intent, while the scheduler handles the combinatorial host choice.

A STRATUM worker has a deliberately small control footprint of 5 lightweight running processes. New workload processes are the VMs and virtual switches themselves. Compared to tradtional viruatlization solutions on the market, STRATUM is on another level with how much capabilities it delivers and how small and portable it is.

Real capacity still depends on polling cadence, database behavior, telemetry volume, topology size, VM launch rate, and storage/network load. The architectural point is that STRATUM worker count does not require a matching explosion of controller processes.

When a worker enrolls, it can identify a placement site such as boston, aws-us-east-1, azure-eastus, tokyo, or a customer-defined facility name.

A virtual datacenter can then set a default placement site. VMs deployed inside that Virtual DataCenter (VDC) inherit the site preference unless a more specific placement rule overrides it. This lets an organization carve one enterprise-wide STRATUM Continuum into operational regions without building a separate management plane for every location.

Site is a scheduling constraint, not magic data sovereignty. Storage location, backups, management traffic, logging, identity, keys, and external services must also be designed to respect regional or contractual boundaries.

Mass placement does not remove guest-level engineering. A thousand VMs still need unique identity, address assignment, service discovery, credentials, configuration, and workload behavior.

STRATUM supplies the infrastructure substrate: templates, virtual switches, fabric connectivity, host placement, and scheduling. The workload can then use familiar mechanisms:

• DHCP, DHCP reservations, IPAM, and authoritative DNS;
• PXE or first-boot provisioning;
• cloud-init or custom bootstrap scripts;
• configuration management and secrets delivery;
• bounded mDNS/Avahi discovery for lab or edge scenarios.

mDNS is convenient, but uncontrolled broadcast discovery across very large production segments is rarely the best design. At scale, prefer explicit DNS, service registration, and segmented failure domains.

Before enrolling a large worker fleet, apply consistent host settings through golden images, configuration management/automation, or stratum-host apply --yes. Every worker also needs a unique FQDN and reliable resolution of the controller’s FQDN.

ZERO-CONFIG begins after the trusted bootstrap bundle exists. Place the STRATUM container, controller CA, enrollment material, and host configuration on the system, then run:

./stratum-host plan
./stratum-host apply --yes
./stratum-host start --reconcile

STRATUM handles the platform configuration that normally becomes a multi-page runbook:

• detect host architecture, KVM, CPU features, memory, GPUs, and network capabilities;
• prepare the selected physical-bridge or cloud-safe pnet0 mode;
• enroll identity using the controller CA and entitlement;
• join the Continuum mesh and receive peer/fabric configuration;
• register the node as a worker, controller, or storage role;
• advertise scheduler capabilities and placement labels;
• reconcile the host back to the desired configuration.

stratum-host plan shows every intended host change before applying it. The same workflow can be automated through Ansible, Puppet, Chef, Terraform-driven provisioning, golden images, or an internal scripting framework.

A worker bundle typically contains:

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

Inspect the host plan before changing the system:

sudo ./stratum-host plan
sudo ./stratum-host apply --yes

apply may change networking and can interrupt connectivity, especially in physical-bridge mode. Use an out-of-band console or the cloud-safe pnet0 mode when loss of the management path would be unacceptable, often on Cloud instances.

Install the enrollment material with restricted permissions, then start reconciliation:

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
sudo stratum-host start --reconcile

Review the service output and deployment logs under the STRATUM persistent path (default location is /persistent). The same plan/apply workflow can be wrapped by Ansible, Puppet, Chef, Terraform-driven provisioning, image pipelines, or an internal scripting framework.

STRATUM containers include bootstrap orchestration material, while the active cluster orchestration key is preserved with the controller’s persistent state. Existing controllers and workers that are upgraded in place continue using the same active key.

A brand-new worker installed from a later STRATUM container may otherwise start with a different embedded key. Before enrolling that worker, copy the controller’s active orchestration key to it so every node uses the same trust material.

1. Stage the active key on the controller host

sudo install -m 0400 \
  /persistent/stratum/secure/munge.key \
  /tmp/stratum-munge.key

Transfer /tmp/stratum-munge.key to the new worker using the organization’s approved secure file-transfer method.

2. Install the key on the new worker

sudo install -d -m 0700 /etc/stratum/secure
sudo install -m 0400 \
  /tmp/stratum-munge.key \
  /etc/stratum/secure/munge.key

Complete the rest of the normal worker setup, including installation of the controller CA and enrollment key, then start STRATUM:

sudo stratum-host start

3. Remove the temporary copies

sudo rm -f /tmp/stratum-munge.key

Run the cleanup on both the controller and the worker after the transfer and installation are complete.

STRATUM runs on supported Arm64 and x86-64 hosts and can manage both in the same broader environment. Workers autonomously advertise their architecture, and templates or VM definitions declare the architecture they require.

An x86 guest image cannot simply execute on an Arm worker with native KVM acceleration, and the reverse is also true. STRATUM will run x86 on Arm and the reverse but it will go through STRATUM's hardware emulation and not be accelerated. The scheduler must place each workload on a compatible host. Multi-architecture operating systems, applications, and containerized services can publish separate artifacts under one logical release.

This matters as Arm expands in cloud, edge, energy-efficient computing, and AI infrastructure. Organizations can introduce Arm where it makes economic or performance sense without replacing the x86 estate or operating two unrelated virtualization control planes.

Modern datacenter CPUs can protect data while it is actively being processed. AMD EPYC processors are heavily used in AI and GPU servers, and AMD Secure Encrypted Virtualization—especially SEV-ES and SEV-SNP—can encrypt guest memory and reduce the ability of a compromised host or hypervisor to inspect or tamper with a VM.

Intel provides a parallel confidential-VM direction through Intel Trust Domain Extensions (Intel TDX) on supported Xeon platforms.

On eligible AMD EPYC hosts, STRATUM can expose SEV capability to compatible guests when the platform firmware, Linux kernel, KVM support, virtual UEFI, attestation components, and VM template are configured for it. Intel TDX follows the same capability-driven principle on supported hardware.

CANVAS is STRATUM’s virtualization engine.

The name reflects a product idea. A traditional hypervisor presents a list of isolated virtual machines. CANVAS is the surface on which an operator composes a larger system: compute, switches, routers, firewalls, storage attachments, GPUs, physical-network edges, and port-to-port wiring.

The “canvas” is not merely a diagram. It is an executable infrastructure definition. What appears visually in the virtual datacenter can be translated into real VM processes, virtual switches, network interfaces, fabric attachments, placement intent, and persistent state.

STRATUM can replace a VMware virtualization estate, but that is only the beginning. VMware, Proxmox, Nutanix, and traditional KVM management platforms are organized around hypervisor hosts and a vCenter-style control plane. STRATUM is organized around a versioned virtual datacenter, a compute grid, and a real network mesh.

The market keeps saying the future is Kubernetes and containerization, while enterprises remain trapped behind VMs, network appliances, legacy operating systems, fixed IP plans, and applications that cannot simply become pods. Companies trying to leave VMware often search for the nearest exact replacement. That preserves the past.

Instead of a collection of VM hosts, STRATUM creates one to thousands of worker containers operating as a high-performance compute grid and Continuum mesh. Datacenters, clouds, labs, edge systems, and Kubernetes clusters become one schedulable platform.

VMware has real strengths, including mature operations and validated FIPS modules. STRATUM’s disruption is different: simplicity, effortless scaling, zero-config enrollment, zero-border mesh networking, OCI immutability, AI/GPU-first infrastructure, and a federal-ready security path.

You can replace VMware with STRATUM. You are not replacing it with another copy of the same architecture. You are moving the datacenter into the container era.

When ESXi itself runs as a STRATUM VM, ESXi is a nested hypervisor. The physical host must expose usable Intel VMX/EPT or AMD SVM/NPT through KVM.

Check the host:

grep -Eo 'vmx|svm' /proc/cpuinfo | sort -u
ls -l /dev/kvm
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null
cat /sys/module/kvm_intel/parameters/ept 2>/dev/null
cat /sys/module/kvm_amd/parameters/nested 2>/dev/null

The first command should return vmx or svm. The KVM device must exist, firmware virtualization must be enabled, and the appropriate nested module option must be active. Modern kernels often enable nested virtualization by default, but distributions can override it. stratum-host command should plan and apply the supported host setting.

Inside ESXi, a normal 64-bit child VM does not need VMware’s “Expose hardware-assisted virtualization to the guest OS” option. That option is only for a child workload that will itself run another hypervisor. Triple nesting is outside the supported STRATUM configuration.

If ESXi appears to use the “second” adapter for management while STRATUM labels it eth0, map the adapters by MAC address. Device ordering in a guest UI is not a reliable substitute for MAC-based identification.

STRATUM supports GPU attachment because accelerators are central to its AI and HPC mission. General-purpose passthrough of arbitrary PCI and USB controllers is intentionally limited in the current product. Contact us if you require this capability.

Every host-bound device narrows placement options. A VM tied to a specific USB controller, HBA, capture card, or PCI function is harder to reschedule, evacuate, reproduce in cloud, or move across a thousand-node worker pool. It turns a portable workload back into a pet tied to one chassis.

Where possible, STRATUM favors network-delivered services: USB-over-IP, storage protocols, network-attached instruments, mediated devices, or remote accelerator services. These preserve the scheduler and virtual-datacenter model.

Additional passthrough can be implemented for a qualified requirement, but it should be an explicit policy choice with placement labels, isolation rules, recovery behavior, and operational consequences. Local GPU passthrough remains the deliberate exception because high-performance AI infrastructure often requires it.

Passing an InfiniBand HCA directly into every VM works, but it binds each VM to a specific PCI function, host, driver state, and failure domain. That is the legacy virtualization style: powerful, but hostile to cloud-scale placement and evacuation.

STRATUM normally configures InfiniBand or another high-speed network once on the host, exposes the usable network capability to the STRATUM container, and attaches it through pnet0, a related physical network, or a STRATUMswitch. VMs consume the network without individually owning the PCI device.

Direct HCA passthrough can still be appropriate where native verbs, deterministic latency, GPUDirect-class behavior, or specialized adapter features are mandatory. In that case STRATUM treats the HCA as a constrained capability and only schedules compatible VMs to the correct worker.

A STRATUM template plays a role similar to an OVF/OVA appliance or a container image. Existing VMDK-based operating-system images can be converted into the appropriate STRATUM template workflow.

The difference is operational emphasis. A template is a reusable, versioned base. Hundreds or thousands of VMs can descend from the same immutable source, while each deployed VM receives its own identity, configuration, writable disk state, and lifecycle.

This enables:

• repeatable deployment from a known base;
• template lineage and blast-radius analysis;
• promotion of tested child images;
• smaller operational variation between VMs;
• central vulnerability and patch decisions tied to a version.

It is the same principle that made container images powerful: define the common artifact once, then create runtime instances without copying and hand-customizing an entire golden machine for every deployment.

Disk drives in STRATUM follow an image-and-instance model. A deployed VM can write normally, install software, update files, and retain state. Underneath that guest-visible disk, STRATUM preserves the relationship to the versioned template from which the VM was created.

Conceptually, the template provides an immutable base and the running VM writes its changes into private writable storage. “Immutable” does not mean that Windows or Linux sees a read-only system disk. It means the base image, disk identity, virtual capacity, bus placement, and ancestry are not casually rewritten in place.

1. Template-derived disks

These disks originate in the Arsenal template, commonly as files such as virtioa.qcow2, virtiob.qcow2, and later template-defined disks.

• the guest can write to its private overlay;
• the disk cannot be added or removed in Node Editor;
• its virtual capacity cannot be resized there;
• its bus, slot, and boot order remain defined by the template;
• it retains template/base-image lineage;
• it participates in STRATUM promotion and image ancestry.

2. Deployment-added data disks

These are independent writable disks created for a deployed VM after the template instance exists.

• they can be added and deleted;
• they can be grown, but not shrunk;
• they are not part of the original template lineage;
• they may be captured if the VM is later promoted into a new template.

Boot order remains an image decision

Template-derived disks retain the boot order defined by the template. Deployment-added disks receive no explicit boot index, are treated as non-boot data disks, and cannot be marked bootable in Node Editor. A workload that requires a different boot arrangement should be promoted or rebuilt as a new Arsenal template.

VirtIO storage is designed for high-performance virtualization, but standard Windows installation media does not include every VirtIO block or VirtIO SCSI driver. If the system disk uses VirtIO, Windows Setup may reach the disk-selection page and display no available drive.

You can avoid the driver step by using SATA/AHCI—or another virtual controller for which that Windows release already includes an inbox driver. VirtIO is normally the better performance choice, so STRATUM makes the driver-loading path straightforward.

Two independent optical drives

Every newly started STRATUM VM can expose two virtual optical drives at the same time:

cdrom0      — Windows installer or boot ISO
guesttools0 — STRATUM Guest Tools / VirtIO driver ISO

The Windows installer continues running from cdrom0 while Setup reads the storage driver from guesttools0. There is no need to detach the Windows ISO midway through installation.

Windows 11 installation sequence

1. Boot the VM from the Windows installation ISO.
2. Continue until Windows Setup reaches the disk-selection screen.
3. Select Load driver.
4. Browse the second CD/DVD drive containing STRATUM Guest Tools.
5. Select the Windows 11 x86-64 driver matching the configured storage device—VirtIO Block or VirtIO SCSI.
6. After the driver loads, select, partition, and format the newly visible STRATUM disk.

After Windows is installed, use the Guest Tools image to install the remaining supported VirtIO network, balloon, serial, and device drivers required by the template.

STRATUM does not require an organization to discard its Veeam investment. There are two practical protection layers:

• Linux deployment: Veeam Agent for Linux can protect an entire machine, selected volumes, or selected directories. The important STRATUM scope is the persistent storage and configuration—not only the replaceable container image.
• Kubernetes deployment: Veeam Kasten can protect Kubernetes resources and supported PersistentVolumes used by the STRATUM deployment.

Back up the STRATUM controller’s persistent state, VM disks, certificates, configuration, and any external dependencies required to reconstruct the deployment. Coordinate snapshots or quiescing when application-consistent VM disk state matters.

The architectural advantage is that the platform binary is a replaceable OCI artifact. Disaster recovery focuses on restoring persistent state and redeploying the known platform version.

The clean boundary is:

• stratum-host, a node image, or configuration management prepares the worker operating system.
• Helm and Kubernetes schedule and run the STRATUM container.

The node must expose the capabilities a virtualization platform requires: KVM, TUN/TAP, required host networking, persistent storage, device access, and the approved privilege boundary. A locked-down managed Kubernetes service that forbids privileged workloads, host networking, device access, nested virtualization, or node preparation is not automatically a suitable STRATUM host.

This is not a Kubernetes flaw. It is a boundary decision. Kubernetes is excellent at scheduling containers; STRATUM is a container that intentionally operates infrastructure below ordinary application pods.

Kubernetes made application scaling fast because containers are small, declarative, and easy to reproduce. VMware and traditional virtualization made infrastructure manageable, but application scaling still tends to depend on guest boot time, configuration, and external automation.

Enterprises now face a split reality:

• the strategic platform is Kubernetes and containerization;
• the operational estate is still VMs, virtual appliances, VLANs, routers, firewalls, storage protocols, and legacy applications.

Most migration paths demand a rewrite before the customer receives cloud-scale operations. STRATUM reverses that order. Kubernetes can schedule and scale STRATUM worker containers, while STRATUM schedules and runs the VMs and virtual datacenters inside them.

This enables progressive modernization: lift the VM, isolate the Virtual DataCenter (VDC), add GPUs and automation, move data paths when it makes sense, and refactor only the services that justify the effort.

The AI infrastructure roadmap is real: accelerated computing, new data pipelines, model serving, RAG, observability, orchestration, and GPU economics are changing the datacenter. Where many neoclouds go wrong is making their Kubernetes API the product surface. The customer must retool applications, data paths, networking, identity, and operations before receiving the GPU.

STRATUM takes the opposite position:

• Keep the interface enterprises already know: VMs, disks, subnets, L2/L3 topology, routers, firewalls, and IP plans.
• Bring GPUs to the data: place GPU-capable workbenches near NAS, SAN, regulated datasets, or existing VLANs instead of forcing a bulk data migration.
• Make orchestration a choice: run Kubernetes, Slurm, Ray, vLLM, systemd, or existing deployment tools without making one framework the admission ticket.
• Observe the wires: topology and dependency intelligence can show where data can travel, not only which label was attached to a pod.

STRATUM changes the GPU-over-IP operating model. Traditional products require administrators to deploy a separate GPU service, configure remote GPU servers, assign endpoint addresses, open and track firewall ports, install a vendor client stack inside each workload, and maintain another management plane beside the hypervisor.

STRATUM collapses that machinery into the virtual-datacenter fabric. A VM receives a purpose-built STRATUM paravirtual GPU hardware device. To the guest, GPU acceleration is attached infrastructure. Behind the device, the STRATUM backend locates the appropriate GPU resource, coordinates access, carries GPU and management operations across the fabric, and hides the network transport from the operator.

Attach a device—not an integration project

• No separate third-party GPU-over-IP product to deploy for every virtual datacenter.
• No GPU-server IP addresses or remote endpoint inventory inside each guest workload.
• No per-VM transport design or manual mapping between applications and remote GPU hosts.
• No second infrastructure control plane competing with VM placement, networking, and lifecycle operations.
• Local and remote GPU resources can participate in one STRATUM scheduling and topology model.

This allows GPU capacity to be pooled, allocated, and shared across a virtual datacenter instead of remaining trapped behind the PCI slots of one server. A GPU may be local to the execution host, available elsewhere in the STRATUM Continuum, or supplied by a specialized GPU worker; the VM consumes the STRATUM device rather than being built around the physical location of the accelerator.

Guest integration may still include the approved STRATUM device driver and compatible GPU runtime, but the customer does not have to install, configure, address, and operate a separate GPU-over-IP client product inside every VM.

The industry’s move from general-purpose CPU scaling toward accelerated computing is not simply “add a GPU checkbox.” AI workloads may need specific accelerator generations, multiple devices, high-speed interconnect, large memory, local data paths, NUMA awareness, and sustained utilization.

That changes the virtualization control plane. A scheduler must understand more than vCPU and RAM. STRATUM workers can advertise GPU class and other capabilities, while the virtual-datacenter definition expresses the workload’s requirements. The scheduler then places the VM where those resources actually exist.

STRATUM also lets AI and conventional workloads share one infrastructure continuum. A database, firewall, Windows service, simulation VM, Kubernetes cluster, and GPU inference node can remain part of one explicit topology rather than being split across unrelated cloud and virtualization silos.

The goal is not to claim CPUs disappear. It is to make accelerated resources first-class, schedulable infrastructure while preserving the enterprise systems that feed, secure, and operationalize AI.

STRATUMOPS is designed around the fact that STRATUM operates the datacenter as an application. The graph therefore shows the whole operational dependency chain:

Template → VM → disk → network attachment
        → virtual switch → fabric → worker
        → scheduler allocation → GPU / TPM
        → tenant → VDC → site

Template blast radius

Select a template and see every descendant VM, running state, requested CPU and memory, hosts using the template, snapshots, and promoted child images. If the template contains a vulnerable package, the affected estate is immediately visible.

Worker evacuation intelligence

Select a worker and answer: Which VMs, VDCs, tenants, GPUs, local-state workloads, and console paths are affected? Which workloads are eligible for automated rescheduling, and which require manual recovery?

Desired state versus running state

Compare the VDC definition with runtime sessions and classify resources as DEFINED, RUNNING, ORPHANED, DRIFTED, COLD-STOPPED, or ERROR.

In one template-heavy STRATUM deployment, the apparent RAM requirement looked brutal: hundreds of VMs, each sized with several gigabytes of memory, all starting from the same operating-system image.

But assigned memory is not the same as unique memory. The fleet contained thousands of identical pages: kernel code, shared libraries, zero-filled regions, common services, and repeated boot state. Linux Kernel Samepage Merging identified those matching pages and replaced them with shared copy-on-write pages.

When a VM modifies a shared page, it receives a private copy. That makes deduplication especially effective for large homogeneous fleets launched from immutable STRATUM templates.

OCI images are built from content-addressed blobs. When a registry client already has an unchanged layer, it does not need to download that blob again. This makes updates efficient when releases preserve stable base and dependency layers and place frequently changing content in smaller upper layers.

STRATUM benefits from:

• shared layers across versions and architectures;
• digest verification and resumable transfers;
• registry replication to remote or disconnected sites;
• small, well-ordered release layers;
• optional specialized delta or chunked-distribution tooling where justified.

This is especially useful for edge facilities and low-bandwidth environments (even satellite-based or line-of-sight distribution).

STRATUM’s production releases currently use stop-and-restart migration. Development work is evaluating live migration, including high-speed transports suitable for large-memory and AI-adjacent workloads.

RDMA can move memory through an InfiniBand or appropriately configured converged fabric with lower CPU overhead and latency than a conventional kernel TCP path. That can improve migration predictability when a VM has a large memory footprint or dirties pages quickly.