测试和开发机架规模硬件的问题在于，机架规模并不是那么容易获得。我的意思是，别谈什么DDR5作为货币的事情；即使所有部件都丰富可用，任何完成的机架都会迅速送往前线（也就是我们客户的数据中心）。作为Oxide产品保障团队的一员，我觉得这完全不公平，但又完全合理。因此，我们必须变得有些创造性。我们需要能够：复制多样的客户网络拓扑，运行我们实际的控制平面，测试我们软件的最新版本，表示硬件组件（毕竟我们制造机架），包括我们的交换机和微控制器。而最重要的是：我们需要在不发布特殊“测试版本”的情况下做到这一点。因为我们希望保持CI的简洁，但也因为这样才算公平。现在，别误会——我们并非没有我们的诀窍。去年我加入Oxide时，我被介绍给我们的“机架小套件”；也就是比平均机架小的每个有四个滑动板和两个交换机的机架。这些机架小套件可以像真正的机架一样初始化和运行，正因为它们就是一个真正的机架。只不过在经济上没有适合销售的形态。但对于测试来说，它们效果很好。今天我们有四个，快要增加到八个，在那里我们可以测试任何组合的硬件/软件需求。我们还有各种模拟手段来运行Omicron。你可以在《如何运行模拟》和更完整的《运行指南》中阅读更多关于这些内容。我在这里不会详细介绍，但可以说我们控制平面的大部分（以及更多）可以独立、协同运行，并以各种程度的模拟运行。那么，什么是体素？你还记得游戏Q*bert吗？它是最早流行的等距游戏之一，看起来像这样：为什么我给你展示一个极小的游戏截图呢？好吧，图中的每个立方体代表一个“体素”，或者说3D空间中的一个点。它其实是像素的3D版本。体积元 + 像素 = 体素。很酷吧？无论如何，对于Oxide来说，虚拟氧化物实验室（或体素）意味着极高的保真度被打包到一个硬件单元中。它是我们之前虚拟实验室（叫做a4x2）的精神继承者，该实验室允许我们在虚拟机中创建良好的机架。顺便提一下，要注意那个“保真度”一词。正如Bryan Cantrill所言，这是基本原则：实验室应该使用原版Oxide软件，而不需要黑客或修改。这就是体素给我们的东西。一个完整的软件仿真堆栈，基于Rust的illumos构建，我们可以构建和测试各种现实的配置：由Propolis提供的滑动虚拟化（编号和未编号）或通过Oxide自己的SoftNPU（软件P4交换机）实现Debian和FRR P4驱动的静态网络，服务处理器（SP）和信任根（RoT）的微控制器仿真和仿真。而且，更重要的是，它在相对较小的占地面积内提供了所有这些功能。在家中，我在一台拥有32线程AMD Ryzen 9 9955HX和96GB RAM的Minisforum MS-A2迷你PC上运行体素实验室。在那台计算机上，我可以轻松启动6个滑动板，无论是以一个机架的形式，还是在多机架配置中（两个独立的机架，一个管理平面）。所需的只是Oxide Helios和一个相对快速的NVMe驱动器。启动后，大约10分钟后，你就会拥有一个完整的Oxide机架，每个“滑动板”都在自己的Propolis虚拟机中——以及交换机（也在Propolis中）和其他基础设施。图像创建记得我说过我们必须使用原版Oxide软件吗？这实际上使事情变得更简单。我们做的第一件事（遵循超管理员工具的常见做法）是创建一个可重用的快照。Oxide滑动板只能是两种状态之一：普通滑动板（第一代的“gimlet”，当前的“cosmo”）或“scrimlet”，这是一个与侧车交换机连接的滑动板，运行交换机区域。它的复杂性优雅得令人难以置信，你应该在我们的网络文档中阅读更多关于它的内容。要为体素创建快照，我们必须做的就是创建一个“滑动板”（虚拟机），在其上安装我们的控制平面（Omicron），在配置点之前快照，它就准备好启动了。控制平面可以通过两种方式安装：从源代码，体素从GitHub克隆Omicron仓库（或使用本地定义的源以快速开发），然后使用cargo进行编译；从TUF仓库。我们使用Tufaceous将Omicron发行版打包，使用更新框架（TUF）和我们的CI工具Buildomat。以第二种选项为例，这里是体素图像创建开始的过程，其中提取出构成滑动板配置的关键部分：$ pfexec ./target/debug/voxel image create --from-tuf ../5d176e0be7e5cc0d3288c1bef10005ec31f2cd7c.zip 5d176e0be7e5cc0d3288c1bef10005ec31f2cd7c [ voxel ] TUF source ../5d176e0be7e5cc0d3288c1bef10005ec31f2cd7c.zip：系统版本23.0.0-0.ci+git5d176e0be7e