Infrastructure, explained.

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 a supported CPU architecture, the required Linux capabilities, TUN/TAP, storage, networking, devices, and privilege boundary. The QEMU/KVM execution path-and the current Kubernetes Helm chart-uses /dev/kvm for hardware acceleration. STRATUMVMM can also execute supported same-architecture workloads without KVM through STRATUM’s proprietary dynamic-binary-translation software-virtualization engine. Cross-architecture execution is a separate hardware-emulation path and is not hardware accelerated. OCI makes the artifact portable; stratum-host and STRATUM determine which execution path the destination can actually support.

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 second queueing subsystem. 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, native execution, 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.

STRATUM treats administrative accountability as a platform function, not an afterthought. User and administrator actions are recorded as audit events. Authorized operators can review the audit trail in the STRATUM Administration interface, while automation, external evidence pipelines, and assessment tooling can query the same information through STRATUM APIs and the SDK.

That capability directly supports implementation and evidence for several controls in the NIST SP 800-53 Audit and Accountability (AU) family:

Infrastructure context makes the audit trail more useful

STRATUM can correlate platform activity with the virtual infrastructure around it: tenant, Virtual DataCenter (VDC), VM and template lineage, disk and storage relationship, network attachment, STRATUMswitch path, worker placement, GPU dependency, and recent topology or configuration changes. That changes the investigation from “what did this host log?” to “what action changed this virtual datacenter, who performed it, and what infrastructure was affected?”

STRATUMOPS extends that evidence model with desired-versus-running drift, template blast radius, affected tenants and networks, worker dependencies, and infrastructure path analysis. Audit data can also be exported or queried for SIEM, log-management, RMF, and assessment workflows.

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.

STRATUM deliberately separates authentication from authorization. Microsoft Active Directory Domain Services, Microsoft Entra Domain Services (formerly Azure Active Directory Domain Services / Azure AD DS), or a generic LDAP directory can establish the user's identity and directory group membership. STRATUM then applies its own roles, workspace access, and platform permissions.

Normal directory user flow

1. Configure the directory service in STRATUM Administration.
2. The user signs in with the username and password maintained by the external directory.
3. STRATUM receives the authenticated username and directory group membership.
4. Create a matching username on the STRATUM Users page.
5. Assign that STRATUM user the appropriate role, group, workspace, and other authorization settings.

While directory authentication is active, the password stored on a matching local STRATUM user record is not used to authenticate that directory-backed login. The local record exists to define authorization.

The administrative recovery exception

STRATUM reserves the directory group stratum-admin as a special administrative path. A directory-authenticated user who is a member of stratum-admin can receive STRATUM administrative access without first requiring a matching local STRATUM user record.

This is intentional. It allows an authorized administrator to be created completely in the enterprise directory and still recover or administer STRATUM if local authorization records are missing, damaged, or not yet provisioned.

Microsoft Entra terminology

For LDAP-based Azure identity integration, the relevant Microsoft service is Microsoft Entra Domain Services. Microsoft Entra ID is the cloud identity service; Entra Domain Services provides the managed LDAP, Kerberos/NTLM, and domain-services interface used by applications that require traditional directory protocols.

STRATUM's current administrative group matcher recognizes these configured administrative group names:

• platform-admins
• admins
• stratum-admin

For a new Active Directory Domain Services, Microsoft Entra Domain Services, or generic LDAP integration, the directory group you need to create and manage for STRATUM administrative recovery is stratum-admin.

What each group means operationally

• stratum-admin - documented directory administration and recovery group. A directory-authenticated member can obtain STRATUM administrative access without a pre-existing local STRATUM user record.
• platform-admins and admins - recognized configured administrative group names. They are not additional directory groups that a normal new STRATUM LDAP deployment needs to create when standardizing on stratum-admin.

What about everybody else?

Ordinary directory users do not need a STRATUM-specific AD/LDAP group just to use the platform. Their directory account provides authentication. Create the same username in STRATUM Administration → Users, then assign the STRATUM role, group, workspace access, and other permissions that identity should receive.

External directory
  user: alice
  password: managed by AD / Entra Domain Services / LDAP
        ↓ authentication
STRATUM Users
  username: alice
  role / groups / workspaces: managed by STRATUM
        ↓ authorization
STRATUM access

This design is intentional: the enterprise directory remains the authority for identity and credentials, while STRATUM remains the authority for STRATUM-specific authorization.

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

For the current STRATUM release, treat one STRATUM Continuum as one common MTU domain. Every participating host should configure stratum0 to a value supported end-to-end by every site in that Continuum. A controlled datacenter can deliberately use a larger value; once a cloud or remote site with a smaller path MTU joins the same Continuum, the safe common value is limited by the lowest-capability path.

What traffic does this govern?

This MTU policy applies to traffic that actually traverses the STRATUM Continuum: stretched virtual-datacenter networks between workers, STRATUMstore/storage-lane traffic, remote console paths, and applicable STRATUM worker management/control traffic carried across the mesh.

Host-local physical networks are different

A host-local physical network is not automatically capped by the Continuum MTU. If a VM or STRATUM Switch is attached only to a local pnet backed by a 9000-byte jumbo network, that local path can use the MTU supported by the physical network. MTU, routing, and reachability on that path remain properties of that local network.

A dual-homed VM is the important current-release limitation. If one interface uses a Continuum-stretched network and another uses a local jumbo network, STRATUM currently applies one conservative common guest MTU rather than independent per-NIC values. Per-NIC MTU policy is not available in the current release. If that capability is important to your environment, let us know.

Why there is no single “Virtual DataCenter MTU” field

A virtual datacenter is not necessarily an MTU boundary. The same topology can contain a local jumbo storage network, a conventional 1500-byte physical network, and a lower-MTU Continuum-stretched network. One datacenter-wide value would be too coarse-and could imply safety that does not exist if the topology can reach a lower-MTU worker.

Community Edition / LAN-only note: direct-local VM and STRATUM Switch paths do not incur the Continuum VXLAN overhead discussed above, so STRATUM does not subtract that overlay overhead from those local-only paths.

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.

Yes. VMware supports VLANs and guest trunking, but a hypervisor port group is not the same operational object as dropping a managed Ethernet switch into a test topology and configuring each port independently. STRATUM Switch is designed for the latter.

interface port1
 switchport mode access
 switchport access vlan 100

interface port2
 switchport mode access
 switchport access vlan 200

interface port3
 switchport mode trunk
 switchport trunk native vlan 10
 switchport trunk allowed vlan 10,100,200

interface port4
 switchport mode trunk
 switchport trunk allowed vlan 300-399

That matters when the system under test is a router, firewall, switch, appliance, or embedded platform that expects conventional Ethernet behavior. A STRATUM trunk can present VLAN 10 untagged as the native VLAN while VLANs 100 and 200 remain 802.1Q tagged-without turning the guest into the switch configuration interface.

True stacked VLAN / 802.1ad Q-in-Q

STRATUM Switch supports normal single-tag 802.1Q and true stacked 802.1ad Q-in-Q, including the provider-style 0x88a8 outer tag. Broadcom documents that VMware's distributed switch does not support that true 802.1ad outer-tag form; its supported double-tag construction uses an 802.1Q 0x8100 outer tag instead.

Overlapping VLANs across disposable test bays

Test Bay A, Test Bay B, and Test Bay C can each contain VLANs 10, 20, and 30 without becoming the same Ethernet segment. STRATUM keeps the test topology's VLAN namespace separate from the transport used to carry that topology between workers:

TEST BAY A / VLAN 10  →  STRATUM logical network / VNI 10001
TEST BAY B / VLAN 10  →  STRATUM logical network / VNI 10002
TEST BAY C / VLAN 10  →  STRATUM logical network / VNI 10003

This is especially useful for nested network appliances. Instead of depending on a collection of hypervisor port-group security exceptions for tagged frames and downstream MAC addresses, the virtual appliance can connect to a STRATUM Switch port whose switching behavior is explicit in the topology.

Current STRATUM storage supports controller-hosted storage and dedicated storage-role STRATUM containers in standalone stratum-host deployments. Those storage roles join the platform and serve VM disks across the Continuum fabric.

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

Each storage role still needs a durable backend. The default standalone persistent root is /persistent/stratum, and a dedicated storage container receives its own storage-role subtree beneath that root. The underlying filesystem may be backed by mirrored NVMe, RAID, direct-attached flash, NAS, SAN-backed filesystems, or another qualified persistent platform.

This design separates compute from storage while preserving portability: the STRATUM Execution Fabric can restart a movable VM on another compatible worker, and that worker reconnects to the VM's assigned storage target.

Yes, in a standalone stratum-host deployment. STRATUM storage roles are composable containers. A storage container can run beside a normal STRATUM compute worker or beside additional storage-role containers on the same Linux host.

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

• a SAN-backed filesystem 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.

Several logical storage roles on one host do not create several physical failure domains. High availability still requires resilient storage, replicas on other systems, or another architecture that survives loss of the host.

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 choose a host one VM at a time. The UI and APIs express placement intent:

run at site aws-us-east-1
run on a compatible x86_64 KVM worker
require the requested GPU capability
pin to an exact worker only when policy requires it

Workers advertise architecture, site, CPU and memory capacity, KVM readiness, GPU inventory, and other execution capabilities. The native STRATUM Execution Fabric evaluates that inventory and selects an eligible worker for each workload.

CPU sharing can increase aggregate density while RAM and physical GPUs remain hard resources. Placement still respects the topology and capabilities required by an individual VM.

Real capacity depends on controller sizing, execution/accounting cadence, telemetry volume, topology size, VM launch rate, storage I/O, and network load. Large-fleet qualification should therefore test the customer's actual workload profile rather than relying on an a legacy process-count benchmark.

A VM or virtual appliance can remain pending when the native STRATUM Execution Fabric cannot yet complete an acceptable placement. The useful question is which requirement is not currently satisfiable?

The VM is larger than any eligible worker

CPU sharing increases aggregate density; it does not invent a larger CPU topology for one VM. A 6-vCPU VM still needs an eligible worker capable of presenting at least six vCPUs to that guest.

Compatible capacity exists, but it is busy

CPU shares may be available while RAM, a physical GPU, or another hard resource is already allocated. STRATUM keeps the workload pending until compatible capacity becomes available or the request changes.

A site, architecture, GPU, or other capability constraint cannot be met

Check the VM's architecture, site, KVM requirement, GPU class, TPM/CPU feature requirements, and any explicit worker selection. A valid constraint can intentionally leave work pending when no worker currently matches it.

The selected worker is unavailable or stale

A pinned worker may be offline, not enrolled, unhealthy, or outside the controller's worker-loss grace interval. The current native execution setting execution.workerTimeoutSeconds defaults to 180 seconds.

The worker cannot complete native execution enrollment

Remote workers require STRATUM Continuum enrollment, controller TLS trust, and a working authenticated outbound HTTPS command channel to the controller. Check the controller hostname, CA, enrollment token, 8443/TCP, Continuum connectivity, and worker status.

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 placement 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 native execution. 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 enrollment material;
• join the Continuum fabric and receive peer/fabric configuration;
• register the standalone host as a controller, worker, or dedicated storage role;
• advertise native execution capabilities and placement metadata;
• maintain the worker's authenticated outbound execution channel when the role is worker;
• 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 standalone worker bundle typically contains:

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

Inspect the host plan before changing the system:

chmod +x ./stratum-host
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 cloud-safe pnet0 when loss of the management path would be unacceptable.

Install the binary and enrollment material with restricted permissions:

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

Then start and verify the native worker relationship:

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

The worker needs a unique FQDN and must resolve the controller FQDN. Remote execution requires connect.enabled=true; Continuum enrollment supplies worker identity, TLS trust, execution admission, and the per-worker agent token.

Adding a new worker after an upgrade uses the normal enrollment path. STRATUM 1.0 uses native execution. A remote worker authenticates through STRATUM Continuum enrollment and maintains an outbound HTTPS execution channel to the controller.

Standalone worker after an upgrade

Use bootstrap material issued for the current controller environment:

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

Install the controller CA and enrollment token under /etc/stratum/secure, then use the normal workflow:

sudo stratum-host plan
sudo stratum-host apply --yes
sudo stratum-host start --reconcile
sudo stratum-host status --deep

Do not copy controller execution databases, old authentication-daemon keys, or another worker's identity to the new host. Each worker receives its own authenticated execution identity during enrollment.

Kubernetes worker after an upgrade

The Helm chart requires workers.existingSecret whenever workers are enabled. That Secret contains:

stratum-enroll
controller-ca.crt

Create or refresh the enrollment Secret from current controller-issued material, then run the normal helm upgrade. Workers initiate HTTPS to the controller; there is no worker-side execution-control listener to configure.

Custom icon images used by Arsenal templates and the STRATUM interface are stored in the controller container under /stratum/html/images/icons/. They do not need to be copied to worker containers because the controller provides the management interface and template assets.

Use PNG files and keep a persistent master copy

Custom icons should use PNG format. Keep the exact filenames referenced by your templates, and retain the original files somewhere outside the replaceable container. A convenient location is a customer-created directory under /persistent:

sudo install -d -m 0755 /persistent/custom-assets/icons
sudo install -m 0644 youricon.png \
  /persistent/custom-assets/icons/youricon.png

Copy the icon into the running controller container with the OCI engine selected for the host:

docker cp /persistent/custom-assets/icons/youricon.png \
  stratum:/stratum/html/images/icons/

Examples below use Docker. If stratum-host selected Podman, use the equivalent podman cp command.

For a single file already in the current directory, the shorter form also works:

docker cp youricon.png \
  stratum:/stratum/html/images/icons/

Restore all saved icons after an upgrade

After the upgraded controller container is running, restore the saved icon set with:

docker cp /persistent/custom-assets/icons/. \
  stratum:/stratum/html/images/icons/

Reload the STRATUM interface after copying the files. If the browser still displays an older image, perform a hard refresh to clear the cached asset.

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 STRATUM Execution Fabric 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.

STRATUM includes two virtualization engines. QEMU remains part of STRATUM for broad guest and device compatibility and for workloads that benefit from its mature ecosystem. STRATUMVMM is STRATUMvisor’s own proprietary virtual machine monitor and hypervisor stack, built so STRATUM can directly control VM execution, device behavior, firmware integration, networking, graphics, snapshots/checkpoints, tracing, and Execution Fabric integration.

KVM is an accelerator-not the STRATUM hypervisor

On Linux systems with /dev/kvm, STRATUMVMM can use the Linux KVM subsystem and VT-x/AMD-V hardware virtualization to accelerate guest execution. KVM is part of the Linux kernel; it supplies the hardware-virtualization primitive. The user-space VMM, execution policy, virtual hardware model, lifecycle, and STRATUM integration around that accelerator are STRATUM-controlled code.

How can STRATUMVMM run without KVM?

For supported same-architecture x86-64 workloads on x86-64 hosts, STRATUMVMM uses a proprietary dynamic binary translation (DBT) software-virtualization engine. This is not slow instruction-by-instruction interpretation. STRATUM translates privileged guest basic blocks into safe host-executable sequences, caches the translated blocks, virtualizes privileged CPU and memory-management operations, and directly executes eligible guest user-space code where it is safe to do so.

With hardware virtualization
Guest VM → STRATUMVMM → KVM / VT-x / AMD-V → CPU

Without hardware virtualization
Guest VM → STRATUMVMM DBT → translated privileged execution → CPU

The result is a KVM-less virtualization path intended to keep a workload operational on systems where /dev/kvm, VT-x, AMD-V, or equivalent virtualization extensions are unavailable. Hardware-assisted execution remains the fastest path for many workloads, while software virtualization trades some privileged-execution overhead for far greater deployment freedom.

Why build STRATUMVMM when STRATUM already includes QEMU?

QEMU gives STRATUM a very broad compatibility engine. STRATUMVMM gives the product an execution engine STRATUM can shape around its own requirements: a smaller dependency boundary, tightly integrated virtual devices and networking, deterministic control over execution, deeper tracing, and deployment modes that do not assume a conventional hypervisor stack already exists on the target machine.

That becomes especially important in the TACTICALvisor mission profile. Instead of asking an integrator to design a mission system around a particular embedded hypervisor and certified computer, the goal is the inverse: take the mission VM and run it on the computer that is available. The deployment model can be reduced to a signed STRATUMVMM/TACTICALvisor binary plus the mission disk, one process per VM, with embedded UEFI/BIOS support, virtio devices, networking, graphics, snapshot/checkpoint support, and execution tracing rather than a chain of host packages, daemons, firmware packages, dependency repositories, and hypervisor-management services.

Mission Forensics Mode

Owning the execution path also enables a forensic execution profile in which STRATUMVMM can record guest execution transitions, virtual-device events, network events, and VM state changes for later investigation. Combined with checkpoints and deterministic record/replay, that creates evidence below the guest operating system instead of relying only on logs produced inside the workload.

STRATUM is not another VMware, Nutanix, or OpenNebula competitor with a different dashboard. Those platforms are fundamentally designed to build, organize, place, and operate infrastructure objects: hosts, clusters, networks, datastores, virtual machines, and services. STRATUM starts from a different object model.

STRATUM treats the virtual datacenter itself as the deployable unit. Compute definitions, VM and appliance relationships, switches, networks, storage relationships, GPU topology, identities, policy, placement intent, and the control environment can move together as a versioned STRATUM artifact.

The OCI mental model, applied to infrastructure

Application era
source → container image → registry → deploy anywhere

STRATUM
virtual datacenter design → STRATUM artifact → registry → instantiate anywhere

The artifact is not “a VM inside a container.” It packages the environment around the workloads-the topology and operating relationships that normally have to be reconstructed in a cloud manager after the software arrives.

This is a generational difference, not a feature-count argument

VMware, Nutanix, and OpenNebula have years of production maturity around conventional infrastructure operations, high availability, VM lifecycle, storage, networking, resilience, and their surrounding ecosystems. STRATUM is not claiming that it duplicates every individual capability in those products-or that every feature-for-feature comparison favors STRATUM.

The disruption is the question underneath the comparison: why are we still assembling datacenters out of individually administered infrastructure objects in the first place?

Docker did not change computing because it was a better process manager than every process manager that came before it. It changed the unit people packaged, distributed, and deployed. STRATUM changes that unit again-from the VM, workload, or cluster to the datacenter.

OpenNebula's current architecture illustrates the traditional model clearly: its front end is the central orchestrator for cluster nodes, VMs, virtual networks, and datastores; hosts are registered for scheduling; and virtual networks are mapped over physical networks. VMware Cloud Foundation and Nutanix Cloud Infrastructure likewise describe integrated platforms for operating compute, storage, networking, virtualization, security, and management. They modernize the operation of infrastructure. STRATUM changes what the infrastructure is packaged as.

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 Execution Fabric 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.

Yes. The current STRATUM Helm chart requires Kubernetes 1.25+ and deploys one controller StatefulSet plus an optional worker DaemonSet.

The clean boundary is:

• stratum-host, a golden image, or site automation prepares each selected node before STRATUM is scheduled there: KVM, TUN, pnet0 when required, IOMMU/VFIO and GPU drivers when used, kernel/sysctl settings, and firewall policy.
• Helm and Kubernetes render the role configuration, mount Secrets and persistence, and schedule the STRATUM pods.

This is an infrastructure workload, not a restricted application pod. The cluster must permit privileged execution, hostNetwork, hostPID, selected hostPath mounts, /dev/kvm, and /dev/net/tun.

Controller and workers

kubectl label node <controller-node> stratum.io/role=controller
kubectl label node <worker-node>     stratum.io/role=worker

The controller uses a persistent PVC for STRATUM state. Remote workers require stratum.connect.enabled=true and a workers.existingSecret containing stratum-enroll and the controller CA. Workers authenticate through enrollment and keep an outbound HTTPS command channel to the controller on 8443/TCP.

Kubernetes made application scaling fast because containers are declarative and reproducible. Traditional virtualization made infrastructure manageable, but the application estate is still full of VMs, virtual appliances, VLANs, routers, firewalls, storage protocols, and systems that are not being rewritten as pods.

STRATUM separates those concerns. In the current Helm chart, Kubernetes runs the controller StatefulSet and a worker DaemonSet. Add a prepared, worker-labeled Kubernetes node and the DaemonSet can place a STRATUM worker there; remove the node and Kubernetes reconciles the pod-level infrastructure.

The result is progressive modernization: gain OCI delivery, immutable releases, Kubernetes reconciliation, DevSecOps, and node-level scale without requiring the workload itself to become Kubernetes-native first.

Remote STRATUM workers still use the same native Continuum enrollment and outbound HTTPS execution relationship whether the worker is launched on Kubernetes or on a standalone prepared Linux host.

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, Ray, vLLM, systemd, batch frameworks, 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 did not stop at forwarding GPU APIs across a network. We created a STRATUM virtual GPU hardware device. The VM sees an emulated PCI function with device identity, PCI configuration space, BAR-backed MMIO regions, driver-visible registers, and a purpose-built command/data path. The guest interacts with an attached device; STRATUM handles where the physical accelerator actually lives.

With the STRATUM guest driver and compatible CUDA/NVML environment, that device provides a local-appearing, CUDA/NVML-capable accelerator interface. Behind it, the STRATUM GPU backend locates the assigned physical GPU, coordinates the session, and carries the device operations across the STRATUM Continuum when the accelerator is remote.

Attach a device-not an integration project

• No separate third-party GPU-over-IP product to deploy beside every virtual datacenter.
• No GPU-server IP addresses or remote endpoint inventory embedded in each workload.
• No per-VM transport design or manual mapping between applications and remote accelerator hosts.
• No second infrastructure control plane competing with VM placement, networking, storage, and lifecycle.
• Local and remote GPU resources participate in the same STRATUM placement and topology model.

This changes the abstraction. Traditional GPU-over-IP products expose a remote service and ask the workload to connect to it. STRATUM exposes hardware and lets the platform resolve the service behind it.

The guest still needs the approved STRATUM device driver and a compatible GPU runtime. Physical GPU capability, bandwidth, latency, licensing, and workload suitability still matter. The difference is that the application is no longer responsible for discovering and operating the remote-GPU transport.

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. The STRATUM Execution Fabric must understand more than vCPU and RAM. Workers advertise GPU class and other capabilities, while the virtual-datacenter definition expresses the workload's requirements. Native placement then selects a worker 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 placement capabilities 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
        → Execution Fabric placement → 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.