Le 14 octobre 2026, Steve Karam, membre de l’équipe Product Assurance d’Oxide, a présenté Virtual OXidE Labs, ou Voxel. Le projet répond à une contrainte concrète de test. Les systèmes complets à l’échelle d’un rack sont rares et les racks terminés partent rapidement dans les centres de données des clients. Oxide doit tester ses versions actuelles, des topologies réseau client, les switches, les microcontrôleurs et le plan de contrôle réel sans maintenir de versions spéciales.

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

Oxide dispose déjà de quatre racklettes. Chacune contient quatre sleds et deux switches. Leur nombre doit passer à huit. Omicron peut aussi fonctionner avec plusieurs modes de simulation, de manière indépendante ou combinée. Voxel succède aux anciens laboratoires virtuels a4x2 et respecte la « Prime Directive » d’Oxide, qui impose l’utilisation du logiciel standard de l’entreprise sans modification.

La pile est écrite en Rust et fonctionne sur illumos. Propolis fournit les sleds virtuels. Debian et FRR assurent le BGP numéroté ou non numéroté ainsi que le routage statique. SoftNPU fournit des switches virtuels basés sur P4. Les processeurs de service et les Roots of Trust sont simulés ou émulés.

Voxel requiert Helios et un SSD NVMe rapide. Steve Karam indique faire fonctionner six sleds sur un Minisforum MS-A2 équipé de 32 threads, d’un AMD Ryzen 9 9955HX et de 96 Go de RAM. Les sleds peuvent former un rack unique ou deux racks séparés partageant un même plan de gestion. Un rack complet démarre en une dizaine de minutes. L’exemple utilise six VM Propolis, dont trois pour le réseau et trois pour les sleds Oxide.

La création d’une image commence par un snapshot ZFS réutilisable. Les sleds Oxide sont soit des sleds classiques, appelés gimlet pour la première génération et cosmo pour la génération actuelle, soit des scrimlets reliés aux switches latéraux et chargés d’une switch zone. Un sled virtuel reçoit Omicron depuis un dépôt cloné, compilé avec cargo, ou depuis un paquet TUF produit avec Tufaceous et Buildomat.

L’archive TUF de l’exemple est `5d176e0be7e5cc0d3288c1bef10005ec31f2cd7c.zip`. Elle contient la version système `23.0.0-0.ci+git5d176e0be7e`, la révision Omicron `5d176e0be7e`, 12 zones, trois artefacts de mesure, une image de démarrage hôte de 1 258 295 296 octets, une ROM de phase 1 de 33 554 432 octets et le firmware SP/RoT. Le snapshot produit s’appelle `voxel-cp-5d176e0be7e-tuf`. L’exemple signale 18 artefacts décompressés et une compilation datée du `2026-09-06T21:37:58`.

Le lancement nécessite une image FRR, une image du plan de contrôle et `voxel-init`. Le processus génère le matériel PKI de sprockets, flashe le firmware Hubris dans des microcontrôleurs STM32H753 et LPC55 émulés, puis utilise la suite de topologie Falcon pour relier les nœuds avec des paires simnet et VNIC. Propolis démarre ensuite six VM. Dans l’exemple, les nœuds s’appellent g0, g1 et g2.

`voxel-init` configure le NAT et les liaisons montantes, prépare l’underlay des sleds, écrit les partitions M.2, étiquette cinq disques de données U.2 et place l’image de phase 2 de l’hôte ainsi que le jeu de données d’installation sur les M.2. Il attribue les scrimlets, lance un switch enforcer qui conserve leur identité après un redémarrage et active `sled-agent`. L’agent contacte ensuite l’API de commission utilisée par `wicketd` pour initialiser le rack. Le parcours comprend 16 étapes, avec le DNS, NTP, la synchronisation temporelle, la base de données, le cluster, les zones et le passage final à Nexus. Dans l’exemple, la route `198.51.100.0/24` passe par `192.168.68.170` et le DNS externe est accessible sur `198.51.100.20`.

Quelques éléments restent différents du matériel de production. Voxel crée les certificats sprockets pendant la préparation. Sur les racks de production, les certificats sont installés à la fabrication et proviennent du RoT. Cette différence ne change pas le fonctionnement du rack. Les connexions matérielles sont décrites dans le code. Un nouvel interconnect virtuel peut être ajouté dans `rack.rs`.

L’émulation des processeurs de service constitue une partie essentielle du système. L’ancien `SpSim` d’Oxide renvoyait les réponses attendues selon un parcours prédéfini. Le projet open source `sp-emu` exécute des Cortex-M7 et Cortex-M33 émulés sur illumos et Linux, en x86 comme en ARM. Chaque appareil utilise un thread et reproduit les instructions, le temps et les interruptions. Le firmware Hubris peut être flashé directement sur l’appareil émulé, qui communique par socket. Voxel y accède via le Management Gateway Service et l’Inter-Processor Communication Channel.

L’émulateur ne se base pas sur l’horloge réelle. Hubris planifie avec un SysTick de 1 ms. `sp-emu` compte donc les instructions à partir de la valeur de rechargement du noyau et déclenche l’exception SysTick lorsque le compteur arrive à zéro. Un accès périphérique coûte un tick émulé, alors que le silicium peut prendre plusieurs cycles de bus. Le modèle gère l’entrée dans les exceptions ARMv7-M et tient compte de `PRIMASK`, `FAULTMASK` et `BASEPRI` pour livrer les interruptions.

Le noyau Hubris n’est pas préemptif, mais ses tâches sont planifiées de façon préemptive. SVCall, PendSV, SysTick et les IRQ ordinaires partagent un niveau de priorité. Les fautes ont une priorité supérieure. L’émulateur ne fait donc pas s’imbriquer ces handlers. Un PendSV en attente réalise le changement de contexte différé du noyau. Sa boucle principale exécute une instruction Thumb-2, avance l’horloge artificielle, livre les interruptions et traite le trafic Ethernet et UART toutes les 4096 cycles artificiels. Le champ `cycles` fait lui aussi partie du modèle d’émulation.

Voxel fournit également des outils d’accès au rack virtuel. `voxel host login g0` ouvre la zone globale d’un sled. `voxel tp login switch0` entre dans la zone `oxz_switch` via `zlogin`. `tp` reproduit le fonctionnement des ports technicien des racks physiques. D’autres commandes gèrent les images et configurent la topologie réseau, la taille des sleds et les déploiements multi-racks.

Voxel est disponible sur GitHub sous licence MPL 2.0. Helios doit être utilisé comme système hôte. Oxide recommande au moins 16 threads, 64 Go de RAM et un SSD NVMe haut de gamme avec DRAM intégrée.