El 14 de octubre de 2026, Steve Karam, del equipo de Product Assurance de Oxide, presentó Virtual OXidE Labs, conocido como Voxel. El proyecto responde a una dificultad práctica de las pruebas. Los sistemas completos a escala de rack son escasos y los racks terminados llegan rápidamente a los centros de datos de los clientes. Oxide necesita probar el software actual, las topologías de red de los clientes, los switches, los microcontroladores y el plano de control real sin mantener versiones especiales.

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

Oxide ya utiliza cuatro racklettes. Cada una tiene cuatro sleds y dos switches. La empresa prevé llegar a ocho. Omicron también ofrece varios modos de simulación, que permiten ejecutar gran parte del plano de control de forma independiente o combinada. Voxel sucede a los antiguos laboratorios virtuales a4x2 y sigue la «Prime Directive» de Oxide, que exige ejecutar el software estándar de la compañía sin modificaciones.

La pila está escrita en Rust y funciona sobre illumos. Propolis proporciona los sleds virtuales. Debian y FRR gestionan BGP numerado o no numerado, además del networking estático. SoftNPU aporta switches virtuales basados en P4. Los procesadores de servicio y las Roots of Trust se representan mediante simulación y emulación.

Voxel requiere Helios y una unidad NVMe rápida. Karam informa de una configuración con seis sleds en un Minisforum MS-A2 equipado con 32 hilos, un AMD Ryzen 9 9955HX y 96 GB de RAM. Los sleds pueden formar un solo rack o dos racks separados con un plano de gestión compartido. Un rack completo arranca en unos diez minutos. El ejemplo utiliza seis VM de Propolis, tres para la red y tres como sleds de Oxide.

La creación de imágenes comienza con una instantánea ZFS reutilizable. Los sleds de Oxide son sleds normales, llamados gimlet en la primera generación y cosmo en la actual, o scrimlets conectados a switches laterales que ejecutan una switch zone. Un sled virtual recibe Omicron desde un repositorio clonado, compilado con cargo, o desde un paquete TUF creado con Tufaceous y Buildomat.

El archivo TUF del ejemplo es `5d176e0be7e5cc0d3288c1bef10005ec31f2cd7c.zip`. Incluye la versión del sistema `23.0.0-0.ci+git5d176e0be7e`, la revisión de Omicron `5d176e0be7e`, 12 zonas, tres artefactos del corpus de mediciones, una imagen de arranque del host de 1.258.295.296 bytes, una ROM de fase 1 de 33.554.432 bytes y firmware SP/RoT. La instantánea resultante se llama `voxel-cp-5d176e0be7e-tuf`. El ejemplo registra 18 artefactos desempaquetados y una compilación con fecha `2026-09-06T21:37:58`.

El arranque necesita una imagen de FRR, una imagen del plano de control y `voxel-init`. El proceso genera el material PKI de sprockets, graba firmware Hubris en microcontroladores STM32H753 y LPC55 emulados y utiliza la suite de topologías Falcon para conectar los nodos mediante pares simnet y VNIC. Después, Propolis inicia las seis VM. En el ejemplo, los nodos se llaman g0, g1 y g2.

`voxel-init` configura NAT y los enlaces ascendentes, prepara el underlay de los sleds, escribe las particiones M.2, etiqueta cinco discos de datos U.2 y prepara en los M.2 la imagen de fase 2 del host y el conjunto de datos de instalación. El agente asigna los scrimlets, inicia un switch enforcer que conserva su identidad tras los reinicios y activa `sled-agent`. Después contacta con la API de commission usada por `wicketd` para inicializar el rack. El proceso recorre 16 etapas, entre ellas DNS, NTP, sincronización temporal, base de datos, clúster, zonas y la entrega final a Nexus. En el ejemplo, la ruta `198.51.100.0/24` se publica a través de `192.168.68.170` y el DNS externo está disponible en `198.51.100.20`.

Algunos detalles todavía difieren del hardware de producción. Voxel crea los certificados de sprockets durante la preparación. En los racks de producción, esos certificados se instalan durante la fabricación y proceden de la RoT. La diferencia no afecta al funcionamiento del rack. Las conexiones de hardware se describen en código. Un nuevo interconnect virtual puede añadirse en `rack.rs`.

La emulación de los procesadores de servicio es una parte importante del diseño. El antiguo `SpSim` de Oxide devolvía respuestas esperadas siguiendo un recorrido prefijado. El proyecto open source `sp-emu` ejecuta dispositivos Cortex-M7 y Cortex-M33 emulados en illumos y Linux, tanto en x86 como en ARM. Cada dispositivo utiliza un hilo y reproduce instrucciones, tiempo e interrupciones. El firmware Hubris puede grabarse directamente en el dispositivo emulado, que se comunica mediante un socket normal. Voxel accede a él a través del Management Gateway Service y del Inter-Processor Communication Channel.

El emulador no utiliza el tiempo de pared. Hubris programa sus tareas con un SysTick de 1 ms. Por eso `sp-emu` cuenta instrucciones usando el valor de recarga del kernel y genera la excepción SysTick cuando el contador llega a cero. Un acceso a un periférico cuesta un tick emulado, aunque el silicio real pueda tardar muchos ciclos de bus. El modelo procesa la entrada en excepciones ARMv7-M y consulta `PRIMASK`, `FAULTMASK` y `BASEPRI` al entregar interrupciones.

El kernel de Hubris no es apropiable, aunque sus tareas se planifican de forma preventiva. SVCall, PendSV, SysTick y las IRQ normales comparten nivel de prioridad. Los fallos tienen una prioridad superior. Por eso el emulador no anida esos handlers. Un PendSV pendiente ejecuta el cambio de contexto diferido del kernel. El bucle principal procesa una instrucción Thumb-2, avanza el reloj artificial, entrega interrupciones y mueve tráfico Ethernet y UART cada 4096 ciclos artificiales. El campo `cycles` también forma parte del modelo de emulación.

Voxel incluye además herramientas para acceder al rack virtual. `voxel host login g0` abre la zona global de un sled. `voxel tp login switch0` entra en la zona `oxz_switch` mediante `zlogin`. `tp` reproduce el flujo de los puertos técnicos de los racks físicos. Otros comandos administran imágenes y configuran la topología de red, el tamaño de los sleds y las instalaciones multi-rack.

Voxel está disponible en GitHub bajo la licencia MPL 2.0. Helios es obligatorio como sistema operativo anfitrión. Oxide recomienda al menos 16 hilos, 64 GB de RAM y una unidad NVMe premium rápida con DRAM integrada.