On 14 October 2026, Steve Karam from Oxide’s Product Assurance team described Virtual OXidE Labs, known as Voxel. The project addresses a practical testing problem: complete rack-scale systems are scarce, and finished racks quickly move into customer data centers. Oxide needs to test current software, customer network layouts, switches, microcontrollers, and the real control plane without maintaining special test builds.

pfexec ./target/debug/voxel launch --emu

Oxide already uses four smaller racklettes, each with four sleds and two switches. The company plans to have eight. Omicron also supports several simulated operating modes, allowing much of the control plane to run independently or in combination. Voxel is the successor to the earlier a4x2 virtual labs and follows Oxide’s “Prime Directive”: the lab should run stock Oxide software without modifications.

The stack is written in Rust and runs on illumos. Propolis provides virtual sleds. Debian and FRR handle numbered or unnumbered BGP and static networking. Oxide’s SoftNPU supplies P4-based virtual switching. Service Processors and Roots of Trust are represented through emulation and simulation.

Voxel runs on Helios and needs a fast NVMe drive. Karam reports running six sleds on a Minisforum MS-A2 with a 32-thread AMD Ryzen 9 9955HX and 96GB of RAM. The sleds can form one rack or two separate racks sharing one management plane. A complete rack starts in about ten minutes. The example launch uses six Propolis VMs, with three for networking and three for Oxide sleds.

Image creation begins with a reusable ZFS snapshot. Oxide sleds are either regular sleds, called gimlet in the first generation and cosmo in the current generation, or scrimlets connected to sidecar switches and running a switch zone. A virtual sled receives Omicron, which is installed from a cloned repository and compiled with cargo, or from a TUF package built with Tufaceous and Buildomat.

The example TUF archive is `5d176e0be7e5cc0d3288c1bef10005ec31f2cd7c.zip`. It contains system version `23.0.0-0.ci+git5d176e0be7e`, Omicron revision `5d176e0be7e`, 12 zones, three measurement corpus artifacts, a 1,258,295,296-byte host boot image, a 33,554,432-byte phase 1 ROM, and SP/RoT firmware. The resulting snapshot is named `voxel-cp-5d176e0be7e-tuf`; the example records 18 unpacked artifacts and a build time of `2026-09-06T21:37:58`.

A launch needs an FRR image, a control-plane image, and `voxel-init`. The process creates sprockets PKI material, flashes Hubris firmware into emulated STM32H753 and LPC55 microcontrollers, and uses the Falcon topology suite to connect nodes with simnet and VNIC pairs. Propolis then starts the six VMs. In the example, the nodes are named g0, g1, and g2.

`voxel-init` configures NAT and uplinks, prepares the sled underlay, writes M.2 layouts, labels five U.2 data disks, and stages the host phase 2 image and installation dataset. It assigns scrimlets, starts a switch enforcer that preserves switch identity across restarts, and activates `sled-agent`. The agent then reaches the commission API used by `wicketd` to initialize the rack. The recorded run moves through 16 stages, including DNS, NTP, time synchronization, database setup, cluster initialization, zone setup, and the final handoff to Nexus. The example exposes `198.51.100.0/24` through `192.168.68.170` and reaches external DNS at `198.51.100.20`.

Some details still differ from production hardware. Voxel creates the sprockets certificates during setup, while production certificates are installed during manufacturing and originate from the RoT. The difference does not affect rack runtime. Hardware relationships are represented in code, so a new virtual interconnect can be added in `rack.rs`.

Service Processor emulation is a major part of the design. Oxide’s older `SpSim` returned expected responses on a predefined path. The open-source `sp-emu` project runs actual emulated Cortex-M7 and Cortex-M33 devices on illumos and Linux for x86 and ARM. Each device uses one thread and models instructions, time, and interrupts. Hubris firmware can be flashed directly into the emulated device, which communicates through a regular socket. Voxel connects to it through the Management Gateway Service and the Inter-Processor Communication Channel.

The emulator does not use wall-clock time. Hubris schedules from a 1ms SysTick, so `sp-emu` counts instructions against the kernel reload value and raises the SysTick exception when the counter expires. Peripheral access costs one emulated tick, even though physical hardware can spend many bus cycles on the same operation. The model handles ARMv7-M exception entry and checks `PRIMASK`, `FAULTMASK`, and `BASEPRI` when delivering interrupts.

Hubris has a non-preemptible kernel with preemptive task scheduling. SVCall, PendSV, SysTick, and regular IRQs share one priority level, while faults have higher priority. The emulator therefore does not nest those handlers. A pending PendSV performs the deferred kernel context switch. Its main loop steps one Thumb-2 instruction, advances the synthetic clock, delivers interrupts, and pumps Ethernet and UART traffic every 4096 synthetic cycles. The `cycles` field is itself part of the emulation model.

Voxel also provides access tools for the virtual rack. `voxel host login g0` opens the global zone on a sled. `voxel tp login switch0` enters the `oxz_switch` zone through `zlogin`; `tp` represents the technician-port workflow used on physical racks. Other commands manage images and configure network topology, sled sizing, and multi-rack layouts.

Voxel is available under the MPL 2.0 license from GitHub. Helios is required as the host operating system. Oxide recommends at least 16 threads, 64GB of RAM, and a fast premium NVMe drive with onboard DRAM.