Am 14. Oktober 2026 beschrieb Steve Karam aus dem Product-Assurance-Team von Oxide Virtual OXidE Labs, kurz Voxel. Das Projekt löst ein praktisches Testproblem: Vollständige Rack-Systeme sind knapp, fertige Racks stehen schnell in den Rechenzentren der Kunden. Oxide muss aktuelle Software, Kundennetze, Switches, Mikrocontroller und die echte Steuerung testen können, ohne eigene Test-Builds zu pflegen.

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

Bisher nutzt Oxide vier kleinere Racklettes mit jeweils vier Sleds und zwei Switches. Bald sollen es acht sein. Für Omicron gibt es außerdem mehrere Simulationsmodi, in denen große Teile der Steuerung unabhängig oder gemeinsam laufen. Voxel ist der Nachfolger der früheren a4x2-Labore und folgt der „Prime Directive“ von Oxide: Im Labor soll unveränderte Standardsoftware des Unternehmens laufen.

Der Stack ist in Rust geschrieben und läuft auf illumos. Propolis stellt virtuelle Sleds bereit. Debian und FRR übernehmen nummeriertes oder unnummeriertes BGP sowie statisches Routing. Oxides SoftNPU emuliert P4-basierte Switches. Service-Prozessoren und Roots of Trust werden simuliert und emuliert.

Voxel benötigt Helios und ein schnelles NVMe-Laufwerk. Karam betreibt sechs Sleds auf einem Minisforum MS-A2 mit 32 Threads, einem AMD Ryzen 9 9955HX und 96 GB RAM. Die Sleds können ein einzelnes Rack oder zwei getrennte Racks mit gemeinsamer Management-Ebene bilden. Ein vollständiges Rack startet in ungefähr zehn Minuten. Der gezeigte Aufbau verwendet sechs Propolis-VMs, davon drei für das Netzwerk und drei als Oxide-Sleds.

Für Images wird zunächst ein wiederverwendbarer ZFS-Snapshot erzeugt. Oxide-Sleds sind entweder normale Sleds, in der ersten Generation gimlet und aktuell cosmo genannt, oder Scrimlets. Diese sind mit den seitlichen Switches verbunden und führen eine Switch-Zone aus. Ein virtuelles Sled erhält Omicron entweder aus einem geklonten Repository, das mit cargo kompiliert wird, oder aus einem TUF-Paket von Tufaceous und Buildomat.

Das Beispiel verwendet das TUF-Archiv `5d176e0be7e5cc0d3288c1bef10005ec31f2cd7c.zip`. Es enthält die Systemversion `23.0.0-0.ci+git5d176e0be7e`, die Omicron-Revision `5d176e0be7e`, zwölf Zonen, drei Messkorpus-Artefakte, ein 1.258.295.296 Byte großes Host-Boot-Image, ein 33.554.432 Byte großes Phase-1-ROM sowie SP/RoT-Firmware. Der fertige Snapshot heißt `voxel-cp-5d176e0be7e-tuf`. Im Beispiel werden 18 entpackte Artefakte und der Build-Zeitpunkt `2026-09-06T21:37:58` protokolliert.

Für den Start braucht Voxel ein FRR-Image, ein Control-Plane-Image und `voxel-init`. Der Ablauf erzeugt Sprockets-PKI-Material, schreibt Hubris-Firmware in emulierte STM32H753- und LPC55-Mikrocontroller und verbindet die Topologie mit simnet- und VNIC-Paaren aus der Falcon-Suite. Danach startet Propolis sechs VMs. Im Beispiel heißen die Knoten g0, g1 und g2.

`voxel-init` richtet NAT und Uplinks ein, konfiguriert das Underlay der Sleds, schreibt M.2-Layouts, beschriftet fünf U.2-Datenlaufwerke und hinterlegt Host-Phase-2 sowie Installationsdaten auf den M.2-Laufwerken. Der Agent weist Scrimlets zu, startet einen Switch-Enforcer für die Identität über Neustarts hinweg und aktiviert `sled-agent`. Anschließend verbindet er sich mit der Commission-API von `wicketd`, die das Rack initialisiert. Der Lauf durchläuft 16 Schritte, darunter DNS, NTP, Zeitsynchronisation, Datenbank, Cluster, Zonen und die Übergabe an Nexus. Im Beispiel wird `198.51.100.0/24` über `192.168.68.170` erreichbar. Der externe DNS-Dienst liegt auf `198.51.100.20`.

Einige Details weichen noch von Produktionshardware ab. Voxel erzeugt die Sprockets-Zertifikate beim Setup. Bei Produktionsracks werden sie während der Fertigung installiert und stammen aus dem RoT. Die Abweichung beeinflusst den Rack-Betrieb nicht. Hardwareverbindungen sind Code. Ein neues virtuelles Interconnect lässt sich in `rack.rs` ergänzen.

Die Emulation der Service-Prozessoren ist ein zentraler Bestandteil. Oxides früheres `SpSim` lieferte erwartete Antworten auf einem festgelegten Pfad. Das Open-Source-Projekt `sp-emu` emuliert echte Cortex-M7- und Cortex-M33-Geräte auf illumos und Linux für x86 und ARM. Jedes Gerät läuft in einem Thread und bildet Instruktionen, Zeit und Interrupts nach. Hubris-Firmware kann direkt auf das emulierte Gerät geflasht werden. Die Kommunikation erfolgt über einen normalen Socket. Voxel nutzt dafür den Management Gateway Service und den Inter-Processor Communication Channel.

Der Emulator verwendet keine Wandzeit. Hubris plant mit einem 1-ms-SysTick. Deshalb zählt `sp-emu` Instruktionen anhand des Reload-Werts des Kernels und löst beim Ablauf den SysTick-Exception aus. Ein Peripheriezugriff kostet einen emulierten Tick, obwohl echte Hardware dafür viele Buszyklen benötigen kann. Bei Interrupts berücksichtigt das Modell die ARMv7-M-Exception-Logik sowie `PRIMASK`, `FAULTMASK` und `BASEPRI`.

Hubris besitzt einen nicht präemptiven Kernel und präemptives Task-Scheduling. SVCall, PendSV, SysTick und normale IRQs liegen auf einer Prioritätsstufe, Fehler auf einer höheren. Der Emulator verschachtelt diese Handler deshalb nicht. Ein ausstehendes PendSV führt den verzögerten Kontextwechsel des Kernels aus. Die Hauptschleife verarbeitet eine Thumb-2-Instruktion, erhöht die künstliche Zeit, liefert Interrupts aus und pumpt alle 4096 künstlichen Zyklen Ethernet- und UART-Daten. Auch das Feld `cycles` gehört zur Emulation.

Voxel dient zugleich als Zugangs- und Verwaltungswerkzeug. `voxel host login g0` öffnet die globale Zone eines Sleds. `voxel tp login switch0` wechselt über `zlogin` in die Zone `oxz_switch`. `tp` bildet dabei den Technikerport physischer Racks nach. Weitere Befehle verwalten Images und konfigurieren Netzwerktopologie, Sled-Größen und Multi-Rack-Layouts.

Voxel steht unter der MPL 2.0 auf GitHub zur Verfügung. Als Host-Betriebssystem ist Helios erforderlich. Oxide empfiehlt mindestens 16 Threads, 64 GB RAM und ein schnelles Premium-NVMe-Laufwerk mit eigenem DRAM.