AtomOS Docs

Appearance

Glossary ​

Shared vocabulary for AtomOS documentation, Electros, and C4. Terms reflect product usage; where platform behavior depends on your release build, confirm on the installed host.

Documentation revision

Docs revision: 2026-10-25. Capability labels in Feature availability may change when Elemento confirms a stable public release.

Host ​

A physical server or cloud instance running a supported Linux distribution with AtomOS services installed via atomos-cli. The host exposes compute, storage, or both depending on the install role.

Target ​

An AtomOS host registered in Electros under Connections → Targets. Operators enable targets (or the scenarios that contain them) under Active Connections before organization users can schedule workloads on that capacity.

Scenario ​

In Electros, a scenario groups cloud resources and targets under a policy boundary (for example a lab, tenant, or environment). Enabling a scenario authorises use of the targets and resources it contains for that session.

Vault ​

A POSIX storage area under /mnt managed by AtomOS storage services. Vaults hold volumes (vid.<id>.elimg trees). Create and edit vaults with atomos-cli --vault-creator and --vault-editor, not by hand-editing settings.json.

Volume ​

A virtual disk backed by AtomOS storage inside a vault. Volumes are referenced in VM specfiles and Electros; metadata and payload live under the vault mount (default example path: /mnt/elemento-vault/).

Specfile ​

A portable JSON description of workload requirements (vCPU, memory, devices, networks, and related fields) used to form a pledge for C4 scheduling. Specfiles do not bind a VM to a specific host name.

C4 ​

Elemento's protocol for discovery, capacity advertisement, and scheduling among AtomOS nodes on reachable network paths. C4 helps match pledges to hosts; it does not by itself guarantee failover or uptime. See Core concepts (C4).

Compute node ​

A host with the compute (or full) role: KVM/QEMU/libvirt guests, compute APIs, and cluster client membership. May use remote vaults on storage nodes when not running local storage.

Storage node ​

A host with the storage role: vault services and volume placement. Required on Ubuntu/Debian topologies that split storage from compute. Other hosts consume vaults over the network.

Full node ​

A host with the full role: compute and storage on one machine. Typical for single-node labs and hyperconverged footprints.

Hyperconverged infrastructure (HCI) ​

A deployment pattern where compute and storage roles coexist on the same hosts (often full nodes), with cluster networking between peers. Contrasts with dedicated compute and storage tiers.

Live migration ​

Moving a running guest from one AtomOS host to another without a full power-off, when CPU features, storage reachability, networking, and guest configuration allow it. GPU/PCIe passthrough and some device models usually block migration. See Availability & recovery and Migration & import.

High availability (HA) ​

An operational outcome: workloads remain reachable or are restored within your RTO when a component fails. AtomOS multi-host design and C4 help re-place pledges, but HA requires your storage, networking, procedures, and (where used) load-balancing policy — not a single switch in the product.

Confidential computing ​

Techniques that protect data in use inside a guest or enclave (for example memory encryption and remote attestation). On AtomOS, Intel TDX is an in-progress direction; see Confidential computing (TDX). Distinct from Secure Boot and vTPM, which address boot integrity and guest secrets respectively.

IOMMU ​

CPU and firmware feature (Intel VT-d, AMD-Vi) that enables safe DMA isolation for PCIe passthrough. Required for GPU passthrough and most dedicated device assignment. Enable in firmware and kernel command line per your platform docs before passing devices to guests.

GPU passthrough ​

Assigning a physical GPU (or other PCIe device) to a guest via passthrough, commonly declared in specfiles with PCI vendor/model identifiers. See GPU / PCI passthrough. Typically incompatible with seamless live migration.

AtomOS GUI ​

On-host web UI installed with the atomosgui role (from AtomOS 0.9 milestone). Provides an Electros-like workflow for local users and groups (storage, compute, admin). Complements fleet-wide Electros; see Architecture.

Electros ​

Elemento's organization-wide control plane for targets, VMs, networks, storage, and scenarios. Documentation: docs.electros.cloud.

Cluster secret ​

Shared material used among AtomOS cluster members to authenticate peer relationships (exact rotation and storage location depend on your release). Treat cluster secrets like other infrastructure credentials: limited access, backup, and documented rotation. Confirm behavior on your build with atomos-cli --info and Elemento support if you harden multi-site clusters.

br0 ​

Default Linux bridge name created during AtomOS install or atomos-cli --bridge-setup, attaching guest virtual NICs to your LAN. Prefer a NIC dedicated to the bridge and keep management SSH/Electros on a separate interface when possible. See Networking & certificates and VLANs.