这里先说明一下，以下内容是按官方文档中的TestbedOS来写的。官方把它定义为一个用于在抽象拓扑上启动虚拟机、支撑研究与测试的testbed平台，并且把安装、依赖、服务启动和集群运行拆成了完整文档。也正因为这样，安装问题通常不是“软件本体坏了”，而是依赖链、运行权限和配置文件没有接顺。

　　一、Testbed怎么安装

　　Testbed怎么安装，先不要一上来就直接跑启动命令。官方安装页已经把顺序写得很清楚，真正稳的做法是先把主机依赖补齐，再执行安装脚本，随后补权限和配置文件，最后再启动服务。按这条线做，返工会少很多。

　　1、先准备主机依赖

　　官方安装页把Host Dependencies单独列了出来，基础依赖至少包括Rust、Poetry、Python 3.10相关环境和pip3。文档还明确说明，Poetry依赖Python 3.10这一档，并建议在Ubuntu环境里先确认pip3已安装，所以第一步不是装Testbed，而是先把Python和Rust这一层打通。

　　2、再补运行时和虚拟化相关依赖

　　官方文档里，运行时依赖至少包括genisoimage和virt-manager。前者用于生成云镜像启动配置所需的iso文件，后者用于查看libvirt guests的图形界面和网络配置。如果这两项没装，后面就算服务能起来，很多来宾镜像和虚拟化操作也跑不顺。

　　3、网络侧依赖按官方要求补齐

　　TestbedOS官方要求OVN和OVS从源码构建，并且文档示例直接给出了ovn版本23.03.0的编译流程。也就是说，网络侧不是只装一个系统包就结束，而是要把OVN、OVS这一层按官方文档走完，否则后面网络拓扑和虚拟交换部分会直接断掉。

　　4、容器和安卓环境按需安装

　　如果你的测试环境要跑容器，官方要求补Docker；如果要跑Android模拟器，还要额外安装openjdk-17-jdk、adb以及Android command line tools，并设置ANDROID_HOME、ANDROID_SDK_ROOT这些环境变量，然后执行sdkmanager的license接受和emulator、platform-tools安装。也就是说，Android相关依赖不是自动随主程序带上的。

　　5、依赖齐了以后再执行安装脚本

　　官方文档给出的正式安装动作是在源码根目录执行setup.sh。这个脚本会编译Rust代码、构建Poetry虚拟环境并生成项目文档，所以它更像完整初始化步骤，而不是简单的二进制安装。若你前面的依赖没装齐，这一步通常就会直接报错。

　　6、安装完还要补权限和配置

　　官方说明里，除了setup.sh之外，还要修改libvirt的qemu.conf，把运行用户和组改成当前用户与libvirt组，并重启libvirtd。随后还要创建host.json，先把参与testbed的主机信息写进去，因为官方明确指出，如果没有这个文件，Testbed就不知道有哪些主机可以参与运行。

　　7、最后再启动Testbed服务

　　官方给了三种启动方式，可以走systemctl启动testbedos-server.service，也可以直接运行sudo testbedos-server main，或者在源码目录里通过cargo run启动。正常情况下，先成功启动一次main模式，后面再决定是否转成daemon方式，会更稳。

　　二、Testbed安装失败与依赖缺失怎么排查

　　Testbed安装失败与依赖缺失怎么排查，重点不是反复重跑setup.sh，而是先判断卡在依赖阶段、权限阶段还是配置阶段。官方安装文档虽然没有单独列一个“错误码表”，但它已经把最容易断开的节点写得很清楚，所以排查时最好按依赖、脚本、权限、配置这四层来拆。

　　1、先看是不是依赖链没有补齐

　　如果在setup.sh阶段就失败，最先该怀疑的是Rust、Poetry、Python 3.10、pip3这一层。因为官方已经明确把它们列为主机依赖，而且setup.sh还要编译Rust代码并构建Poetry虚拟环境，所以只要这些前提缺一个，后面就很难真正跑通。

　　2、再看是不是用了不匹配的系统环境

　　官方说明里明确说，依赖安装脚本pre-req-setup.sh是为Ubuntu或Debian系设计的，而且项目测试套件也是以fresh ubuntu install为基线。也就是说，如果你当前环境不是这一类系统，或者系统版本和包管理方式差得很大，安装失败就不能简单按“脚本有问题”去理解。

　　3、如果网络相关步骤报错，优先查OVN和OVS

　　因为官方要求OVN和OVS都从源码构建，而且还是按匹配版本一起编译，所以网络部分一旦没装对、没编译完或版本不一致，后面很容易出现测试床能装但网络起不来的情况。这里的问题常常不在主程序，而在OVN、OVS这一层本身。

　　4、如果服务能装但启动报权限错误，先查libvirt配置

　　官方文档在Configure Libvirt User Permissions里直接要求修改qemu.conf的user和group，并重启libvirtd。这说明很多启动期错误不是程序本身坏了，而是当前用户根本没有被正确授权去操作libvirt daemon。

　　5、如果程序能启动但跑不起来，先查host.json

　　这是非常高频的一类问题。官方明确写到，运行testbed之前必须先创建host.json，并填入参与testbed的主机信息，否则服务并不知道有哪些testbed hosts。也就是说，这类问题不是依赖缺失，而是配置缺失。

　　6、如果前后混用sudo，先查文件所有权

　　官方安装页在Limitations里专门提醒，如果你在某些阶段用了sudo，后续创建出来的文件可能会带高权限所有权，导致你之后不得不继续用sudo。官方还指出，云镜像下载目录会因为是否使用sudo而落在不同home目录下，这就很容易造成看起来“同一个环境”却重复下载、重复初始化或权限混乱。

　　7、Android相关功能异常时先查环境变量和licenses

　　如果问题集中在安卓模拟器一侧，最先要回头看的不是主程序，而是Android SDK环境。官方明确要求设置PATH、ANDROID_HOME、ANDROID_SDK_ROOT，并执行sdkmanager的licenses接受与组件安装，所以这类依赖缺失往往和环境变量没加载、license没接受或emulator没装齐有关。

　　三、Testbed依赖链路怎么理顺

　　Testbed依赖链路怎么理顺，真正要解决的不是“这次装成功”，而是后面换机器、换人、换环境时也能稳定复现。官方文档本身已经把依赖、配置和启动方式分层写开了，所以更稳的做法，是把这些层级固定成一套标准安装链，而不是每次靠人工临时判断。

　　1、先把依赖分成基础层和功能层

　　基础层是Rust、Poetry、Python、pip3这些让setup.sh能跑起来的前提；功能层则是Docker、OVN、OVS、Android Emulator这些按场景启用的依赖。把这两层拆开以后，后面就不会为了一个纯虚拟机测试环境去强装一整套安卓工具，也不会在基础层没补齐时就去怀疑业务组件。

　　2、把setup.sh和pre-req-setup.sh分开使用

　　官方已经明确说明，pre-req-setup.sh用来自动化安装前置依赖，而setup.sh则负责编译代码和构建项目环境。真正稳定的做法，是先把前置依赖脚本跑通，再执行setup.sh，而不是把两者混成同一层操作。这样一旦失败，也更容易定位。

　　3、把权限和配置放在安装后固定步骤里

　　很多环境不是依赖没装，而是装完后忘了改qemu.conf、忘了重启libvirtd、忘了建host.json。更稳的方式是把这几步写成固定checklist，让它们永远跟在setup.sh后面执行。这样后面即便换新主机，流程也不会散。

　　4、启动方式先统一，不要多种方式混跑

　　官方给了systemctl、CLI和cargo三种方式，但在实际环境里，最好先固定一种主方式。例如先统一用CLI跑通main模式，再决定后续是不是切systemctl。这样排错时，至少可以先排除“是启动方式不一致导致的差异”。

　　总结

　　Testbed怎么安装，关键是先按官方文档把主机依赖、功能依赖、权限配置和host.json这几层补齐，再执行setup.sh并启动服务。Testbed安装失败与依赖缺失怎么排查，关键则是按依赖、系统环境、网络组件、权限配置和sudo影响逐层拆开看，而不是一味重跑安装脚本。等这两步都走顺以后，再把Testbed依赖链路怎么理顺固定成标准流程，后面的安装和迁移通常会比临时试错稳很多。