← 返回信息流
AI 资讯Hacker News·1 天前

Proxmox VE 轻松运行 MicroVMs 指南

原标题：Running MicroVMs in Proxmox VE, the Easy Way

速览

本文详细阐述了如何在 Proxmox VE 虚拟化平台上轻松实现 MicroVMs 的运行。通过简化的配置流程，用户能够更高效地利用轻量级虚拟机技术。这一方法有助于提升资源利用率并简化基础设施管理。

AI 深度解读

在 Proxmox VE 中轻松运行 MicroVMs：深度解读 pve-microvm

背景

作者多年来一直维护着一个混合配置的 Proxmox VE 集群，节点硬件跨度极大：从仅配备 Atom x5-Z8350 处理器和 2 GB 内存的老旧设备（如 z83ii，曾作为基准压力测试设备服役多年），到拥有 i7-12700 处理器和 128 GB 内存的主力家庭实验室服务器（borg）。

随着近期围绕“代理沙箱”（agentic sandboxes）的热潮以及作者开发 agentbox 的经历，他意识到在传统的 LXC 容器和完整虚拟机（Full VMs）之间长期存在的妥协已难以满足需求。为了在安全性与启动速度之间找到平衡，作者开发了 pve-microvm——一个 Debian 软件包，它将 QEMU 的 microvm 机器类型作为一等公民的管理客户机引入 Proxmox VE。

这并非一个临时的修补程序。虽然初版确实如此，但该项目已发展为包含自定义内核、修补 Perl 内部以集成 Proxmox Web UI，并支持从 Debian 到 NetBSD 再到 Plan9 等 21 种客户机操作系统的成熟项目。目前，该项目已成为作者日常运行 Gitea、Caddy 反向代理、微型防火墙以及辅助整理文章的 AI 代理的主力环境。

核心内容

传统方案的局限性

Proxmox 原生提供两种主要虚拟化选项，但各有痛点：

  1. LXC 容器：
    • 优势：启动瞬间完成，共享宿主机内核，效率极高。
    • 劣势：隔离性不足，一个容器的内核漏洞可能导致整个宿主机沦陷；无法运行不同的操作系统；在容器内嵌套 Docker 需要处理复杂的 fuse-overlayfs 配置；无法加载自定义内核模块或需要 CAP_SYS_ADMIN 权限的高权限工作负载。
  2. 完整虚拟机（Full VMs）：
    • 优势：通过 KVM/VT-x 提供硬件级别的隔离。
    • 劣势：启动缓慢（通常需 5-10 秒），需经历 SeaBIOS/OVMF 固件引导、GRUB 加载、探测大量模拟的遗留设备（IDE 控制器、VGA、USB 集线器等），且每个虚拟机都在内存中承载整个模拟芯片组的开销。

MicroVM 的解决方案

作者追求的是虚拟机的安全边界与容器的启动特性的结合。QEMU 的 microvm 机器类型（最初为 Firecracker 风格的工作负载开发）通过剥离所有不必要的组件来解决这一问题：

  • 无 BIOS、无 GRUB、无遗留设备。
  • 直接内核引导进入最小化的 virtio 环境。
  • 结果：在 KVM 硬件隔离边界内，带有 QEMU 代理的完全网络化的客户机可在 300 毫秒内 启动。

技术实现细节

pve-microvm 是一个单一的 .deb 包，在安装时修补 Proxmox 的 qemu-server Perl 模块。当 VM 配置中设置 machine: microvm 时，标准的 config_to_command 函数会委托给作者的 MicroVM.pm，构建一个几乎完全不同的 QEMU 命令行参数：

qemu-system-x86_64 -M microvm,x-option-roms=off,pit=off,pic=off,\
isa-serial=on,rtc=on,acpi=on,pcie=on \
-kernel /usr/share/pve-microvm/vmlinuz \
-initrd /usr/share/pve-microvm/initrd \
-append "console=ttyS0 root=/dev/vda rw quiet" \
-device virtio-blk-pci-non-transitional,drive=drive-scsi0 \
-device virtio-net-pci-non-transitional,netdev=net0 \
...

关键特征：

  • 无芯片组模拟：无 PCI 桥接、无 VGA。
  • 极简接口：客户机仅获得一个串行控制台（PVE 的 xterm.js 原生连接）、virtio 块设备和 virtio 网络接口。
  • 传输协议：所有设备通过 PCIe 传输，使用非过渡模式（modern-only）的 virtio 设备，而非 microvm 最初设计的 MMIO 传输。

软件包组成

  1. 定制内核：12MB 大小的预构建 Linux 6.12.22 内核，基于 x86_64_defconfig 编译，包含最小化覆盖层（virtio, vsock, virtiofs, 9p）以及 Docker 所需的模块（overlay, veth, bridge, netfilter, BPF）。
  2. 微型 Initrd：1MB 大小，用于探测 virtio 设备，通过标签或设备路径查找根文件系统，并在约 150 毫秒内执行 switch_root。
  3. 模板工具 (pve-microvm-template)：从 12 种支持的 OCI 基础镜像（如 Debian, Alpine, Fedora 等）构建根文件系统，可选安装 SSH、Docker 和客户机代理。
  4. 镜像导入 (pve-oci-import)：直接将 OCI 镜像拉取并转换为 PVE 管理的磁盘。
  5. Web UI 扩展：提供“创建 µVM”按钮、机器类型下拉菜单、无关设置的动态隐藏，以及在资源树中显示琥珀色闪电图标。
  6. 系统服务：pve-microvm-early.service 确保在 pvedaemon 启动前应用补丁，这对于设置 onboot=1 的 VM 至关重要。

启动序列与性能

  • SmolBSD (NetBSD)：使用 virtio-mmio 传输，启动仅需 31 毫秒。
  • Debian with Docker：首次启动（含 apt 包安装）需不到 8 秒；后续启动稳定在 300 毫秒左右。

关于传输协议的技术细节： microvm 支持两种 virtio 设备传输方式：原始的 MMIO 接口或 PCIe。

  • MMIO：更轻量，无需 PCIe 主机桥接或 ACPI，是 NetBSD 实现极速启动的原因。
  • PCIe：在 QEMU 10.x 版本中，作者发现 Linux 客户机在 MMIO 路径上存在设备探测 Bug（仅 virtio-blk 绑定，网络和串行设备未被驱动声明）。因此，Linux 客户机回退到使用非过渡模式 virtio 设备的 PCIe 传输，虽然增加了约 50 毫秒的启动时间，但保证了可靠性。

“一个内核，多个客户机”架构

这种直接内核引导机制带来了一个关键后果：内核并不存在于客户机内部。

  • 内核位于 Proxmox 宿主机上的 /usr/share/pve-microvm/vmlinuz。
  • 客户机磁盘仅包含根文件系统（用户空间），没有 /boot、没有 GRUB、没有每客户机独立的内核包、也没有独立的 initramfs。

这种内核与根文件系统的解耦使得大规模运行成为可能：

  1. 节点上的每个 Linux microVM 都引导相同的 vmlinuz。
  2. 只需在宿主机上更新一次内核，重启客户机即可生效。
  3. 客户机永远不会因为 apt upgrade 拉取损坏的内核，因为客户机没有可升级的内核。
  4. 根文件系统镜像保持极小且与内核无关。

这实现了容器式的内核一致性与虚拟机式的隔离性。

关键要点

  • 平衡点：pve-microvm 解决了 LXC 隔离性不足和传统 VM 启动慢、资源开销大的问题，提供了接近容器的启动速度（<300ms）

相关推荐

查看原文 →taoofmac.com