# 在普通腾讯云 OpenCloudOS 9.4 上把 Cube Sandbox PVM 整套打通——5 条命令、3 分钟，含 76 ms 冷启动 + 隔离实测

> 腾讯云普通云服务器（非裸金属、`/proc/cpuinfo` 没有 vmx/svm、`/dev/kvm` 不存在），靠 `dnf install kernel-*.cubesandbox.oc9` + 一行 `online-install.sh CUBE_PVM_ENABLE=1`，3 分钟搞定 Cube Sandbox PVM 部署，**实测冷启动 avg 68.4 ms / p90 72.9 ms / min 61.6 ms**，全程 5 条核心命令。

## 0. 我手里这台机器到底有没有资格跑

很多文章一上来就 `docker run`，但 Cube Sandbox 不是 Docker——它要 **KVM**。所以第一步必须先体检：我这台机器到底"开不开得动"？

```bash
ssh root@1.13.163.22  # 本次测试的腾讯云服务器 IP

cat /etc/os-release | head -8
uname -r
lscpu | egrep "Model name|^CPU\(s\)|Hypervisor|Virtualization"
free -h
ls -l /dev/kvm 2>&1
egrep -o "vmx|svm" /proc/cpuinfo | sort -u
df -h /
```

![preflight](https://developer.qcloudimg.com/http-save/yehe-10730009/dd12b900ba36b946aa9d0d2cfd562cf5.png)

读一下这张图里**最关键的两行**：

```
===== 5) /dev/kvm =====
ls: cannot access '/dev/kvm': No such file or directory

===== 6) CPU 虚拟化标志 =====
（空）
```

也就是说：
- ✅ **OpenCloudOS 9.4 / 内核 6.6.119 / 8 vCPU / 15Gi RAM / 200G 磁盘**——硬件够用；
- ❌ **`/dev/kvm` 不存在**、`/proc/cpuinfo` 里**没有 `vmx` 也没有 `svm`**——云厂商把硬件虚拟化扩展屏蔽了。

按官方 README 上来直接 `online-install.sh` 必定挂在 preflight。让我顺手验证一下这件事——读一下官方一键脚本里的 KVM 检查：

```bash
grep -n -E "kvm|pvm" /root/online-install.sh | head -10
```

```text
71:  if [[ ! -e /dev/kvm ]]; then
73:      echo "ERROR: PVM mode is enabled (CUBE_PVM_ENABLE=1), but /dev/kvm was not found."
77:      echo "For the full setup flow, see: .../guide/pvm-deploy.html"
80:      echo "ERROR: KVM is not supported or not enabled (/dev/kvm not found)."
```

预检查会硬卡。但官方文档里其实给了**第三条路**：「普通云服务器用户：无需裸金属——安装 PVM 宿主机内核即可在普通云服务器上启用 KVM 能力」。这就是我们要走的路线。

---

## 1. 五分钟看懂 PVM 是个什么玩意

PVM = **Pagetable-based Virtual Machine**，是腾讯云开源到 OpenCloudOS 内核里的「**基于页表的嵌套虚拟化**」实现。它的精髓在：

> **不依赖宿主 hypervisor 把 vmx/svm 暴露给 guest**，而是通过共享内存 + 影子页表，在内核态做特权切换。对外层 hypervisor 完全透明。

通俗一句话：你的云服务器即使被云厂商屏蔽了硬件虚拟化，PVM 内核也能在里面"偷偷"虚拟出一层，把 `/dev/kvm` 自己造出来。这层之上 Cube Sandbox 才能跑 MicroVM。

而最爽的是：**PVM 宿主机内核包已经直接进 OpenCloudOS 9 官方 yum 仓库**，一行 `dnf install` 搞定，不用去 Releases 页面右键复制链接：

```bash
dnf list available "kernel*cube*"
```

![dnf 列出 cubesandbox 内核](https://developer.qcloudimg.com/http-save/yehe-10730009/dc025495696570ecc494de2c5aa88c1a.png)

`extras` 仓库里有现成的 `kernel-6.6.69-1.1.cubesandbox.oc9`，正好对应 PVM 宿主内核。这就是 OpenCloudOS 9 的"快捷路径"——其它发行版还得 wget rpm + grubby 一通操作。

---

## 2. 装内核 → 切默认 → 配 GRUB → reboot（三条命令）

```bash
# 1) 装 PVM 宿主内核
dnf install -y kernel-6.6.69-1.1.cubesandbox.oc9 \
               kernel-core-6.6.69-1.1.cubesandbox.oc9 \
               kernel-modules-6.6.69-1.1.cubesandbox.oc9

# 2) grubby 自动把默认指向新内核（dnf 已经帮我们做了）
grubby --default-kernel
# /boot/vmlinuz-6.6.69-1.1.cubesandbox.oc9.x86_64    ✅

# 3) 给 grub 配 PVM 必需的启动参数（iommu=pt / cgroup.memory=nokmem 等）
curl -sL https://cnb.cool/CubeSandbox/CubeSandbox/-/git/raw/master/deploy/pvm/grub/host_grub_config.sh | bash

# 4) 重启
reboot
```

重启回来——内核切到 cubesandbox，但 `/dev/kvm` 还没有，因为 `kvm_pvm` 模块没自动加载。手动 `modprobe` + 写 `/etc/modules-load.d/`：

```bash
modprobe kvm_pvm
lsmod | grep kvm
ls -l /dev/kvm
echo 'kvm_pvm' > /etc/modules-load.d/kvm-pvm.conf
```

![modprobe kvm_pvm 后 /dev/kvm 出现](https://developer.qcloudimg.com/http-save/yehe-10730009/fd3168768437550aee421d830a76581e.png)

看到没——`kvm_pvm 49152 0` 加载成功，`crw-rw-rw- 1 root kvm 10, 232 /dev/kvm` 凭空出现。**普通云服务器从此有了 KVM 能力**。这一刻其实就是整个部署最魔幻的瞬间。

---

## 3. 一键安装 Cube Sandbox（关键就一个环境变量）

普通版安装命令：

```bash
curl -sL https://cnb.cool/CubeSandbox/CubeSandbox/-/git/raw/master/deploy/one-click/online-install.sh | MIRROR=cn bash
```

PVM 版只多一个 `CUBE_PVM_ENABLE=1`：

```bash
curl -sL https://cnb.cool/CubeSandbox/CubeSandbox/-/git/raw/master/deploy/one-click/online-install.sh \
  | CUBE_PVM_ENABLE=1 MIRROR=cn bash
```

为什么这个变量必须传？官方文档讲得很清楚：

> 发布包里有两份 guest 内核——`vmlinux`（普通版）和 `vmlinux-pvm`（PVM 版）。`CUBE_PVM_ENABLE=1` 告知安装脚本将 PVM guest 内核覆盖安装为运行时使用的 `vmlinux`。不设置则默认普通 guest 内核，PVM 不会生效。

我把这条放后台跑，本地轮询日志（不然 SSH 卡 3 分钟太难受）：

```bash
nohup /root/run_install.sh </dev/null >/dev/null 2>&1 &
# 大约 3 分钟后 …
cat /root/install.done   # 0  ✅
```

![一键安装关键阶段](https://developer.qcloudimg.com/http-save/yehe-10730009/f778109479877f72a714d549629c0c81.png)

这张图摘录了安装日志里的关键里程碑：
- `Pre-download preflight checks passed` —— PVM 模式下 `/dev/kvm` 检查通过
- `CN mirror latest asset: …v0.2.2/cube-sandbox-one-click-46424e7.tar.gz` —— 走 CDN 镜像（438 MB）
- `installed PVM guest kernel as …/cube-kernel-scf/vmlinux` —— **关键日志**：PVM guest 内核已就位
- `Container cube-sandbox-mysql / redis / cube-proxy-coredns Started` —— 控制面组件起来
- `started cubemaster pid=7884 / cube-api pid=7885 / cubelet pid=7886` —— 数据面组件起来
- `[quickcheck] OK` + `webui listening on 12088`
- `[one-click] install complete (role=control)`

整个 v0.2.2 包从下载到 5/5 quickcheck OK，**实测 3 分钟整**，比裸金属买机器的速度快。

装完看一眼"健康体检"：

![安装后体检](https://developer.qcloudimg.com/http-save/yehe-10730009/c261befb1ddc6b6409a594a3e9e54568.png)

四件该有的全有：
- `CUBE_PVM_ENABLE=1` 写进了 `.one-click.env`
- `kvm_pvm` 在 `lsmod` 里
- 4 个 cli 命令链接到 `/usr/local/bin/`：`cubecli` / `cubemastercli` / `cube-runtime` / `containerd-shim-cube-rs`
- 4 个端口正常监听：cubemaster:8089 / cube-api:3000 / network-agent:19090 / webui:12088

---

## 4. 制作代码解释器模板（18 秒到 READY）

模板就是「沙箱启动时用的镜像 + 配置」，可以理解为 Docker 里的 image，但底层是 MicroVM 的 rootfs + snapshot：

```bash
cubemastercli tpl create-from-image \
  --image cube-sandbox-cn.tencentcloudcr.com/cube-sandbox/sandbox-code:latest \
  --writable-layer-size 1G \
  --expose-port 49999 \
  --expose-port 49983 \
  --probe 49999

cubemastercli tpl watch --job-id <job_id>
```

![模板 18 秒到 READY](https://developer.qcloudimg.com/http-save/yehe-10730009/a703487fbf334e662931d5acb27ad9af.png)

我这次拿到的 `template_id = tpl-6c8afd4059dc4736ac327a11`，watch 走完 7 个阶段（PULLING → DOWNLOADING → EXTRACTING → CREATING_TEMPLATE → READY）只花了 18 秒，比 docker pull 同等大小的镜像还快——因为底层用的是 RustVMM 的 rootfs 增量分发，不是 docker layer。

---

## 5. 第一个沙箱 + 10 次冷启动 benchmark

官方文档说"`E2B_API_KEY=dummy`"——但 **e2b SDK 2.25.1 已经强校验格式**，dummy 会被前端校验拦下。这是文档没跟上 SDK 升级的真实坑：

```python
e2b.exceptions.AuthenticationException:
  Invalid API key format: expected "e2b_" followed by hex characters
```

把 key 改成 `e2b_` + 40 个 0 就能过：

```bash
export E2B_API_URL="http://127.0.0.1:3000"
export E2B_API_KEY="e2b_0000000000000000000000000000000000000000"
export CUBE_TEMPLATE_ID="tpl-6c8afd4059dc4736ac327a11"
export SSL_CERT_FILE="/root/.local/share/mkcert/rootCA.pem"
```

然后跑 hello + 10 次连续冷启动：

```python
import os, time
from e2b_code_interpreter import Sandbox

# 1) 单次 hello
t0 = time.time()
with Sandbox.create(template=os.environ["CUBE_TEMPLATE_ID"]) as sb:
    print(f"created in {(time.time()-t0)*1000:.0f} ms")
    print(sb.run_code("import platform; print(platform.release())").logs.stdout)

# 2) 10 次冷启动取分位
costs = []
for _ in range(10):
    t0 = time.time()
    sb = Sandbox.create(template=os.environ["CUBE_TEMPLATE_ID"])
    costs.append((time.time()-t0)*1000)
    sb.kill()
```

实测结果：

![76ms 冷启动 + N=10 benchmark](https://developer.qcloudimg.com/http-save/yehe-10730009/fe6fc8f5c924fa60a7e106424641053c.png)

| 指标 | 实测值 | 官方宣称 |
|---|---|---|
| 单次冷启动 | **76 ms** | < 60 ms（裸金属） |
| min | **61.6 ms** | — |
| avg | **68.4 ms** | 60 ms (单并发) / 67 ms (50 并发裸金属) |
| p50 | **69.5 ms** | — |
| p90 | **72.9 ms** | 90 ms (P95) |
| max | **77.0 ms** | — |
| guest 内核 | `6.6.69-cube.pvm.guest.005.x` | — |
| guest hostname | `tpl-6c8a` | — |
| guest pid in init | `9` | — |

注意第二行 guest 内核——它跟我宿主机的 `6.6.69-1.1.cubesandbox.oc9.x86_64` **不是同一个内核版本**。`-cube.pvm.guest` 后缀说明这是裁剪过的 guest 内核，跟 PVM host 内核分别编译。这是「真·内核级隔离」的硬证据。

**这组数据是普通腾讯云 CVM (`AMD EPYC 9K65 / 8 vCPU / 15 GiB`) 上跑出来的，不是裸金属**，能压到 60-80 ms 的区间，已经基本兑现了官方的 60 ms 承诺。

---

## 6. evil.py：4 项隔离实战，看 PVM 拦得住什么

光有性能不是沙箱的卖点，**隔离才是**。我写了一个小脚本，往沙箱里灌 4 类"恶意"操作，看宿主有没有被穿透：

| 测试 | 操作 | 期望 |
|---|---|---|
| T1 | 读自己的 hostname / kernel / cpu count | guest 是独立身份 |
| T2 | 写 `/etc/hostname`、读 `/host`、读 `/proc/1/root/etc/shadow` | rootfs 只读、宿主路径不可见 |
| T3 | `bytearray(4 GiB)`（模板只配 2 GiB） | 触发 OOM |
| T4 | `connect()` 169.254.169.254（云元数据）/ 宿主 10.206.0.11 / 8.8.8.8 / baidu.com | 内网拦、公网通 |

![evil.py 4 项隔离测试](https://developer.qcloudimg.com/http-save/yehe-10730009/0b552f46dd66cf5099fc4b6c5882e3c5.png)

逐条解读：

```text
[host]   宿主 hostname: VM-0-11-opencloudos
[host]   宿主 kernel  : 6.6.69-1.1.cubesandbox.oc9.x86_64

>>> T1 沙箱内部身份 <<<
[guest] hostname  = tpl-6c8a                       ← 完全不是宿主名
[guest] kernel    = 6.6.69-cube.pvm.guest.005.x    ← 不同内核版本！
[guest] cpu count = 2                              ← 不是宿主的 8
```

T1：**身份完全隔离，连 cpuinfo 看到的核数都被裁到 2**——和模板规格 `2C2000M` 对得上。

```text
>>> T2 试图触碰宿主敏感文件 <<<
[guest] / 下：['.container_ro', '.container_rw', '.dockerenv', 'bin', ...]
[guest] 写 /etc/hostname：被拒 -> OSError [Errno 30] Read-only file system
[guest] 读 /host: 被拒 -> FileNotFoundError
[guest] 读 /proc/1/root/etc/shadow: ok? 'root:*:20486:0:99999:7:::\n…'
```

T2：rootfs 默认 RO，要写得显式申请 writable layer；`/host` 这种"经典逃逸路径"根本不存在；`/proc/1/root/etc/shadow` **能读出来**——但仔细看那是 guest 自己的 init 进程的 root 视图，里面是 guest 的 shadow（密码字段全是 `*` 占位锁定状态），不是宿主的。这恰好印证了：**guest 是独立内核 + 独立 /proc，不是 namespace 共享**。

```text
>>> T3 内存炸弹 (malloc 4 GiB，模板只给 2 GiB) <<<
[guest] MemoryError ->
```

T3：4 GiB 直接 `MemoryError`，OOM 没有泄漏到宿主——硬性内存上限，是 hypervisor 层强制的。

```text
>>> T4 网络越权探测 <<<
[guest] 169.254.169.254:80  -> TimeoutError: timed out    ← 云元数据，被拦
[guest] 10.206.0.11:22       -> TimeoutError: timed out    ← 宿主 SSH，被拦
[guest] 8.8.8.8:53           -> 可达
[guest] baidu.com:80         -> 可达
```

T4 是**最值得展开**的一条。CubeSandbox 默认通过 CubeVS（基于 eBPF 的虚拟交换机）实现了一份"开箱即用"的 deny 列表：`10.0.0.0/8` `100.64.0.0/10` `172.16.0.0/12` `192.168.0.0/18`，等于把整个内网（包括云元数据和宿主自身）默认堵死。所以：

- 169.254.169.254（云元数据，AWS/腾讯云通用）→ ⛔ 拦下
- 10.206.0.11（我宿主自己）→ ⛔ 拦下
- 8.8.8.8 / baidu.com → ✅ 公网放行

LLM 生成的代码即使想试探"我跑在哪个云、有没有 IAM 凭证可偷"，都没辙。这一条对 Agent 场景太关键了——很多 prompt injection 的攻击面，第一步都是去摸云元数据。

---

## 7. 5 条命令复盘：在普通云服务器上把 Cube Sandbox 跑起来

回到开头的承诺——「**5 条命令，3 分钟**」。把所有正餐操作捋一遍，确实就是 5 条：

```bash
# 1) 装 PVM 宿主内核（dnf install kernel-...cubesandbox.oc9）
dnf install -y kernel-6.6.69-1.1.cubesandbox.oc9 kernel-core-6.6.69-1.1.cubesandbox.oc9 kernel-modules-6.6.69-1.1.cubesandbox.oc9

# 2) 配 grub + reboot
curl -sL https://cnb.cool/CubeSandbox/CubeSandbox/-/git/raw/master/deploy/pvm/grub/host_grub_config.sh | bash && reboot

# 3) 加载 kvm_pvm 模块（一次性 + 开机自加载）
modprobe kvm_pvm && echo 'kvm_pvm' > /etc/modules-load.d/kvm-pvm.conf

# 4) 一键安装（CUBE_PVM_ENABLE=1）
curl -sL https://cnb.cool/CubeSandbox/CubeSandbox/-/git/raw/master/deploy/one-click/online-install.sh | CUBE_PVM_ENABLE=1 MIRROR=cn bash

# 5) 创建模板 + watch
cubemastercli tpl create-from-image --image cube-sandbox-cn.tencentcloudcr.com/cube-sandbox/sandbox-code:latest --writable-layer-size 1G --expose-port 49999 --expose-port 49983 --probe 49999
```

跑完这 5 条，本机就有了一个 E2B 兼容的、**60-80 ms 冷启动**、**硬件级 + eBPF 网络隔离**的代码沙箱服务。

---

## 8. 几个值得记下来的"踩坑笔记"

| # | 现象 | 根因 | 解决 |
|---|---|---|---|
| 1 | `/dev/kvm` 不存在 | 普通云服务器屏蔽了硬件虚拟化扩展（lscpu 看不到 vmx/svm） | 装 PVM 宿主内核 |
| 2 | `uname -r` 切到 cubesandbox 后 `/dev/kvm` 还没有 | `kvm_pvm` 模块没自动加载 | `modprobe kvm_pvm` + 写 `modules-load.d` |
| 3 | install 日志看到 `using ordinary guest kernel` | `.env` 里 `CUBE_PVM_ENABLE=0` 覆盖了环境变量 | 用 online-install 走 `CUBE_PVM_ENABLE=1`；或 `sed -i 's/=0/=1/' .env` |
| 4 | `Sandbox.create()` 报 `Invalid API key format` | e2b SDK 2.25.x 升级后强校验 `e2b_<40hex>` | 把 `dummy` 换成 `e2b_0000…0000` |
| 5 | 第一次 create 报 `template have no kernel component` | 模板池 `2C2000M.tmp` 预热的瞬态错误 | 重试一次即可，后续都 60-80 ms 稳定 |

---

## 9. 写在最后

我对这次部署最大的"意外感"在于两件事：

1. **OpenCloudOS 9 把 PVM 内核包直接进了 yum 仓库**，省掉了"去 Releases 页面右键复制 wget 链接"的整段操作。这是 Cube Sandbox 团队和 OpenCloudOS 社区把工程化做透了的体现。其它发行版还需要手动下 rpm/deb，OpenCloudOS 只要 `dnf install` 一行——这是真正的"快捷路径"。
2. **PVM 在普通云服务器上的代价几乎为零**。我以为嵌套虚拟化会有 30-50% 的性能损耗，但 60-80 ms 的冷启动数据告诉我：**PVM 的影子页表方案，在 Sandbox 这种"短生命周期 + 高密度"的场景下，性能反而比传统嵌套虚拟化好得多**。

如果你也在做 AI Agent，正纠结"代码到底跑在哪儿才安全"——别再让大模型生成的脚本直接跑在你机器上了，也别再为了上 Firecracker 去找裸金属了。一台 50 块钱一个月的普通腾讯云轻量服务器，5 条命令，3 分钟，你就能拥有一个产线级的硬件隔离沙箱。

> 文中所有日志、命令、截图均为本次实测真实记录；服务器规格 `1.13.163.22 / OpenCloudOS 9.4 / AMD EPYC 9K65 / 8 vCPU / 15 GiB RAM`，部署时间 2026-06-01 20:00 ~ 20:08（含 reboot 和模板下载）。


腾讯云普通云服务器（非裸金属、/proc/cpuinfo 没有 vmx/svm、/dev/kvm 不存在），靠 dnf install kernel-*.cubesandbox.oc9 + 一行 online-install.sh CUBE_PVM_ENABLE=1，3 分钟搞定 Cube Sandbox PVM 部署，实测冷启动 avg 68.4 ms  p90 72.9 ms  min 61.6 ms，全程 5 条核心命令。

在普通腾讯云 OpenCloudOS 9.4 上把 Cube Sandbox PVM 整套打通——5 条命令、3 分钟，含 76 ms 冷启动 + 隔离实测

腾讯云普通云服务器（非裸金属、/proc/cpuinfo 没有 vmx/svm、/dev/kvm 不存在），靠 dnf install kernel-*.cubesandbox.oc9 + 一行 online-install.sh CUBE_PVM_ENABLE=1，3 分钟搞定 Cube Sandbox PVM 部署，实测冷启动 avg 68.4 ms  p90 72.9 ms  min 61.

服务端开发

架构设计

在腾讯云OpenCloudOS 9.4普通云服务器上，只需5条命令、3分钟即可完成CubeSandbox PVM整套部署，实现硬件虚拟化能力。实测冷启动平均68.4ms，P90仅72.9ms，提供内核级隔离和eBPF网络防护，有效阻挡云元数据探测等安全威胁。无需裸金属服务器，快速构建安全可靠的AI代码沙箱环境。

云服务器

服务器

虚拟化

解释器

Agent

GRUB

2026年中大促 | AI 领航 智绘未来

4核4G3M云服务器 新用户低至38元/年！

CDN免费试用


lighthouse

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在普通腾讯云 OpenCloudOS 9.4 上把 Cube Sandbox PVM 整套打通——5 条命令、3 分钟，含 76 ms 冷启动 + 隔离实测-腾讯云开发者社区-腾讯云

在普通腾讯云 OpenCloudOS 9.4 上把 Cube Sandbox PVM 整套打通——5 条命令、3 分钟，含 76 ms 冷启动 + 隔离实测

在普通腾讯云 OpenCloudOS 9.4 上把 Cube Sandbox PVM 整套打通——5 条命令、3 分钟，含 76 ms 冷启动 + 隔离实测

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐