One machine can hold a rack
Oxide's Voxel project launches an emulated Oxide rack on one Helios host. Its public README names the pieces: Omicron control-plane software, Propolis virtual machines managed by Falcon, SoftNPU switches, and FRR routers. A configuration chooses the sled count, network shape, and single-rack or multi-rack layout.
Oxide's launch account adds the embedded layer. The lab can flash production Hubris firmware into emulated service processors and roots of trust. The rack then follows the normal initialization path through networking, storage labels, control-plane services, and handoff to Nexus.
The useful trick is not making every part real. It is running the same software against replacements whose limits are named.
Stock software is the center rail
Voxel builds a reusable control-plane image from an Omicron commit or a packaged TUF repository. The README says Voxel links Omicron's own rack-initialization configuration types. A schema change can fail at compile time instead of becoming a handwritten test-only format.
That is a strong contract. It does not make the host equivalent to a physical rack. It means a test can identify the production software revision and the emulated parts around it.
The clock is a declared substitute
The sp-emu repository says it boots unmodified production firmware on interpreted Cortex-M7 and Cortex-M33 devices. It models the memory, interrupts, Ethernet, SPI, I2C, sensors, flash slots, and management traffic that this firmware touches.
The same README states that timing is not real. Peripheral access costs one interpreted instruction. Oxide's article explains that the emulator counts instructions to decide when to deliver a system tick. This supports firmware behavior tests. It cannot prove silicon timing, bus stalls, thermal behavior, or real interrupt latency.
Write down the cut lines
The article names one manufacturing difference. Voxel generates trust material at launch instead of receiving it from a physical root of trust during manufacturing. The article says this does not affect the rack runtime they are testing. That scope statement matters more than a claim that the lab is simply "high fidelity."
The public project also has real host demands. Its operator guidance requires Helios. The article recommends at least 16 threads, 64 GB of memory, and a fast NVMe drive with onboard DRAM. We reviewed the public sources and exact repository revisions listed below. We did not install Helios, build the images, or launch Voxel.
Build a fidelity card per test
- Pin the production software, firmware, and configuration revision.
- Name each replacement for hardware, network, storage, trust material, and time.
- Choose a claim that the replacement can support. Keep physical timing and fault claims out unless the lab can reproduce them.
- Attach one failure case, one cleanup path, and the host resource envelope.