Oxide's Voxel emulates a full Oxide rack on a single machine
Oxide makes racks, and the post opens with the problem that follows from that: rack-scale hardware is hard to get for testing, because finished racks go straight to customers' data centers. The author, a member of Oxide's Product Assurance Team, lists what testing has to do anyway: replicate diverse customer networking topologies, run the actual control plane, test up to date versions of the software, and represent the hardware, including switches and microcontrollers. All of it without cutting special "test version" releases.
Oxide already has two partial answers. One is the racklettes: smaller racks of four sleds and two switches each, which run just like a real rack because they are a real rack, only not in a form factor that would be economical to sell. Oxide has four today, soon to be eight. The other is a set of simulated ways to run Omicron, the control plane, where most parts can run independently, in tandem, and at various degrees of simulation.
Voxel, short for Virtual OXidE Labs (a play on the 3D pixel, volume element plus pixel), is the third. It is the spiritual successor to Oxide's earlier virtual labs, known as a4x2, which ran decent racks in VMs. The design rule is fidelity, which the author calls, in Bryan Cantrill's words, the Prime Directive: labs should use stock Oxide software without hack or modification.
Voxel is a complete software emulation stack built on illumos in Rust. Sleds are virtualized with Propolis. Networking is BGP (numbered and unnumbered) or static, using Debian and FRR. Switches are P4-powered, through Oxide's own SoftNPU, a software P4 switch. The Service Processor (SP) and Root of Trust (RoT) microcontrollers are simulated and emulated.
The footprint is small. At home the author runs Voxel on a Minisforum MS-A2 mini-PC with a 32-thread AMD Ryzen 9 9955HX and 96GB of RAM, and can spin up 6 sleds with ease, as one rack or as two separate racks under one management plane. The requirements are Oxide Helios and a decently fast NVMe drive. After launch, in about 10 minutes there is a full Oxide rack, each sled in its own Propolis VM, with the switches (also in Propolis) and other infrastructure alongside.
The first step is image creation, a reusable snapshot in the style of common hypervisor tooling. Oxide sleds are either a normal sled (a "gimlet" in the first generation, "cosmo" in the current one) or a "scrimlet", a sled wired to the sidecar switches that runs a switch zone. To build the snapshot, Voxel creates a virtual sled, installs Omicron on it, and snapshots it before configuration, which yields a ready-to-launch sled. Omicron can be installed from source (Voxel clones the repo from GitHub, or uses a local source for rapid development, and compiles with cargo) or from a TUF repo (releases packaged with Tufaceous and Oxide's CI tool Buildomat).
The post shows the TUF route. Running voxel image create --from-tuf on a zip reports system version 23.0.0-0.ci+git5d176e0be7e, extracts 12 zones and 3 measurement corpus artifacts, then pulls host artifacts (a host boot image of 1258295296 bytes, a phase 1 ROM of 33554432 bytes) and SP/RoT firmware. After unpacking and staging it launches a VM to install into, and ends with a ready line showing unpacked_artifacts=18 and built=2026-09-06T21:37:58. The resulting image is a zfs snapshot that can be reused to create racks.
Launching needs three things: an "frr" image (the Debian VMs for networking), a control plane image like the one just built, and the voxel-init agent that gives each virtual sled its assignment. The author pastes a long log of voxel launch --emu. It writes sprockets key pairs and certificates, then starts the SP emulator for rack 0, flashing Hubris archives into slot A for four SPs (ports 33300, 33310, 33320, 33330), each with its own seed, SP UID and RoT UUID. A runner then starts at 22:15:47 on Sep 06, creates simnet and vnic links, launches nodes g0, g1 and g2 as Propolis instances, mounts /opt/cargo-bay on nodes ce, cr1 and cr2, and by 22:16:12 voxel-init has pinned DHCP client IDs, set up NAT for rack egress and brought the routers up. The visible text breaks off in the middle of that log.
Key facts
- Voxel (Virtual OXidE Labs) is a complete software emulation stack, built on illumos in Rust, that runs a full Oxide rack with stock Oxide software, including emulated switches and service processors.
- The author, a member of Oxide's Product Assurance Team, runs it at home on a Minisforum MS-A2 mini-PC (32-thread Ryzen 9 9955HX, 96GB RAM) and can spin up 6 sleds, as one rack or two racks under one management plane.
- Launch to a full rack with each sled in its own Propolis VM takes about 10 minutes; the requirements are Oxide Helios and a decently fast NVMe drive.
- Voxel is the successor to Oxide's a4x2 virtual labs and complements physical racklettes (four sleds and two switches each; four today, soon eight).
- The control plane, Omicron, is installed into a reusable zfs snapshot image either from source or from a TUF repo built with Tufaceous and Buildomat.
Why it matters
Real racks are scarce for testing, since finished ones go to customers. Voxel gives Oxide a way to run the actual control plane and up to date software against a representative rack, including switches and microcontrollers, without special test-version releases. Its governing rule is fidelity: labs should use stock Oxide software without hack or modification. It follows the earlier a4x2 virtual labs, which ran decent racks in VMs.
Who it affects
Primarily Oxide's own engineers and the Product Assurance Team, whose CI and development work depends on realistic racks. Anyone interested in how a vendor tests rack-scale hardware and a control plane without a physical rack will find the approach instructive. The post is written from the author's own use of Voxel at home on a mini-PC.
How to use it
The post shows two commands: voxel image create --from-tuf
How solid is it
This is a first-hand engineering write-up by an Oxide team member, with concrete image-creation and launch logs from a build dated 2026-09-06. The figures for home hardware, 6 sleds and about 10 minutes are the author's own account. The text available for this retelling is truncated in the middle of the launch log, so the rest of the article, any conclusion and any availability or open-sourcing statement are not covered here.
Risks and caveats
Voxel is described as coexisting with the physical racklettes, not replacing them. The only scale figure given is the author's 6-sled home setup; no performance, cost or limit beyond that is stated. The log shown uses a CI build version (23.0.0-0.ci+git5d176e0be7e) and a debug build of the voxel tool, so it illustrates a working flow rather than a released product.
“labs should use stock Oxide software without hack or modification”
— The post's author, on the Prime Directive as Bryan Cantrill puts it