Cloud Hypervisor学习笔记 – Learning Cloud Hypervisor

Docs: 概述

Sat, 15 Nov 2025 00:00:00 +0000

cloud hypervisor 用户文档放在 github 代码仓库中, 地址为:

https://github.com/cloud-hypervisor/cloud-hypervisor/tree/main/docs

在官方网站上有一个入口:

https://www.cloudhypervisor.org/docs/prologue/introduction/#user-documentation

Docs: 概述

Sat, 15 Nov 2025 00:00:00 +0000

cloud hypervisor 用户文档放在 github 代码仓库中, 地址为:

https://github.com/cloud-hypervisor/cloud-hypervisor/tree/main/docs

在官方网站上有一个入口:

https://www.cloudhypervisor.org/docs/prologue/introduction/#user-documentation

Optimize: 概述

Sat, 15 Nov 2025 00:00:00 +0000

内核参数调优：

调整 vm.swappiness , dirty_ratio 参数，减少内存抖动

Optimize: 概述

Sat, 15 Nov 2025 00:00:00 +0000

使用 vhost-blk 或者 virtio-scsi ，避免复杂的磁盘模拟

Optimize: 启动加速

Mon, 01 Dec 2025 00:00:00 +0000

Practices: 在腾讯安全容器Cube的落地实践

Sun, 23 Nov 2025 00:00:00 +0000

公开资料

Cloud Hypervisor 在腾讯安全容器Cube的落地实践: 2023-08-30
技术解读：Cube 安全容器高并发低延时实践之路:2023-07-04
Cube轻量虚拟化如何做到100ms交付一个安全容器: 2023-08-09, 内容和上面 infoq 的基本相同。可以当是一个文章。

咨询gemini

问题：帮我在网络上深度搜索一下腾讯云 Cube 这个产品在 microvm / cloud hypervisor 上的实践，包括技术博客，文档，技术峰会的演讲，官方宣传资料等。我想理解这个产品在这个技术上的发展情况，尤其我发现我找到的资料基本都是2023年的，帮我重点看看有没有最新的资料。

答复如下：

根据你提供的 Bilibili 视频链接以及对腾讯云 Cube（Serverless 容器） 在 MicroVM / Cloud Hypervisor 领域实践的深度搜索，我为你整理了如下内容。

第一部分：视频内容总结 (BV1ku4y1C7d8)

该视频主要来自腾讯云在技术峰会（如 OpenInfra 或 KubeCon 相关活动）上的演讲，题目通常围绕 《腾讯云 Serverless 容器高性能实践》。

核心内容总结：

产品定位：介绍 Cube 作为腾讯云 Serverless 容器（类似 AWS Fargate）的底层引擎，旨在提供“强隔离、秒级启动、免运维”的容器服务。
痛点解决：
- 传统虚拟机（KVM/QEMU）启动慢、内存开销大。
- 普通容器（Docker）共享内核，隔离性不足，无法承载多租户不可信代码。
技术演进：
- Cube 经历了从 QEMU 到 Firecracker，再到最终选择 Cloud Hypervisor 的路线演进。
- Cloud Hypervisor (Rust)：视频重点介绍了为什么选择基于 Rust 编写的 Cloud Hypervisor。因为它比 QEMU 更轻量，比 Firecracker 具有更好的通用设备支持（如 Virtio-blk/net/fs）。
关键优化技术：
- 启动加速：通过精简内核模板、减去不必要的枚举过程，使 MicroVM 启动达到毫秒级。
- 内存优化：利用 Virtio-mem 和内存气球技术，实现容器内存的按需分配。
- 存储与网络：采用高性能的 virtio-fs 和私有化网络协议栈加速方案。

第二部分：腾讯云 Cube 在 MicroVM / Cloud Hypervisor 上的深度实践

腾讯云在 MicroVM 领域的实践是国内最激进且最成熟的之一。以下是技术细节的深度拆解：

1. 技术栈：Kata Containers + Cloud Hypervisor

腾讯云 Cube 深度参与了 Kata Containers 社区，并将其作为 Runtime 的标准。

弃用 QEMU：因为 QEMU 代码库庞大（数百万行），安全攻击面广，且内存常驻开销（Overhead）高达 50MB+。
拥抱 Cloud Hypervisor (CH)：CH 是 Intel 发起、基于 Rust 编写的 VMM。腾讯云是 CH 社区的核心贡献者。CH 相比 Firecracker 的优势在于它支持 Live Migration（热迁移） 和更完整的 PCI 设备支持，这对于企业级容器场景至关重要。

2. 核心技术实践

Rust 语言的安全性：利用 Rust 的内存安全性，规避了传统 C/C++ 模拟器常见的缓冲区溢出等安全漏洞，这在多租户 Serverless 环境中是安全底线。
高性能 I/O (Virtio-fs)：在 Serverless 容器挂载数据卷时，腾讯云对 virtio-fs 进行了深度优化，解决了小文件读写性能差的问题。
设备热插拔：Cube 实现了在 MicroVM 运行过程中动态增减 CPU 和内存，这在 Serverless 自动扩缩容场景下表现卓越。

第三部分：2023 年以后的最新动态（重点关注 2024-2025）

你提到的资料多为 2023 年，这主要是因为 Cloud Hypervisor 已经在腾讯云内部进入了“大规模生产成熟期”。但在 2024 年及 2025 年初，有一些新的演进方向：

1. 社区地位升级 (2024)

加入 Linux 基金会项目：Cloud Hypervisor 已正式从 Intel 孵化并成为 Linux 基金会的关键项目。腾讯云作为 Advisory Board（咨询委员会）成员，目前在社区的话语权极大，持续将内部的补丁（如异步 I/O 增强、特定的虚拟化中断优化）推向主线。

2. 重点方向：机密计算 (Confidential Computing) - 2024 热门

最新进展：2024 年腾讯云 Cube 的研究重点转向了 机密容器 (Confidential Containers)。
实践：结合 Cloud Hypervisor 支持 Intel TDX 和 AMD SEV-SNP。这意味着 Cube 不仅提供隔离，还能提供“硬件级加密内存”，使得即便是腾讯云的系统管理员也无法查看用户容器内的运行数据。这是 2024 年高端政企客户和金融客户的主打方向。

3. 与 AI 算力的结合 (2024-2025)

GPU 穿透与虚拟化：最新的 Cube 实践正在解决 MicroVM 挂载 GPU 的问题。传统 MicroVM 对复杂 PCI 设备（如 H100/L40s）支持较弱，腾讯云通过定制 Cloud Hypervisor 的 PCI 模拟层，实现了 Serverless 容器秒级调用 GPU 资源，支持 AI 推理任务的快速拉起。

4. 架构整合：从 Cube 到 TKE Serverless

产品趋势：腾讯云正在将 Cube 的能力完全融入到 TKE (Tencent Kubernetes Engine) Serverless 节点中。你现在看到的最新文档可能不再单独强调 “Cube” 品牌，而是作为 TKE 的“原生节点（Native Node）”或“虚拟节点”存在。

总结与建议

目前的现状是：

技术成熟度：Cube 使用 Cloud Hypervisor 的方案已经从“实验室探索”完全进入“大规模工业化应用”。
最新资料去向：
1. GitHub 提交：如果你想看最硬核的进展，可以查看 Cloud Hypervisor GitHub 的 Commits，搜索腾讯邮件地址（@tencent.com），你会发现他们在 2024 年依然活跃于 Memory Hotplug 和 Vhost-user 的优化。
2. 机密计算文档：搜索“腾讯云 TDX 机密实例”或“机密容器”，这是 Cube 底层技术的最新延伸。
3. 2024 演讲：建议关注 2024 OpenInfra Days China 以及 KubeCon China 2024，腾讯云在这些会议上分享了关于“高性能机密计算容器”的最新实践。

结论：你找不到太多 2024 年后的“Cube”品牌宣传，是因为这项技术已经化作腾讯云底层的基础设施资产，现在的演进重心已从“怎么跑起来”变成了“怎么跑 AI 任务”和“怎么跑得更安全（机密计算）”。

Optimize: 共享只读文件

Sun, 23 Nov 2025 00:00:00 +0000

Shared Read-Only Rootfs (共享只读根文件系统):

方案：所有 MicroVM 共享同一个基础镜像作为只读层（通过 Virtio-fs DAX 挂载）。

写操作：对于需要写的目录（如 /var, /tmp），挂载一个极小的、基于内存的 tmpfs，或者使用 OverlayFS 挂载一个空的 Host 目录。

效果：磁盘 I/O 几乎全部转化为内存映射操作，极大降低存储带宽压力。

Docs: API

Sat, 15 Nov 2025 00:00:00 +0000

https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/docs/api.md

cloud hypervisor API 由两个不同的接口组成：

外部 API / External API

这是面向用户的 API。用户和运维可以通过多种选项（包括 REST API、命令行界面（CLI）或基于 D-Bus 的 API）控制和管理Cloud Hypervisor，其中基于 D-Bus 的 API 默认情况下不会被编译到 Cloud Hypervisor 中。
内部 API / internal API

内部 API 基于 rust 的多生产者、单消费者（MPSC）模块。此 API 由云虚拟机线程内部使用，用于线程之间的通信。

本文档的目标是全面描述 Cloud Hypervisor API，并概述内部和外部 API 在架构上的关系。

外部 API

Cloud Hypervisor 管理器 REST API 触发特定于虚拟机(VM)和虚拟机管理器(VMM)的操作，因此它被设计为一系列 RPC 风格的静态方法。

该 API 符合 OpenAPI 3.0 标准。有关 API 负载和响应的更多详细信息，请参阅 Cloud Hypervisor OpenAPI 文档。

位置和可用性

如果启用了 REST API，则 Cloud Hypervisor 二进制文件启动后即可通过 UNIX 套接字（如 Cloud Hypervisor 选项 –api-socket path=… 中指定的）或 –api-socket fd=… 的文件描述符使用。

$ cloud-hypervisor --api-socket path=/tmp/cloud-hypervisor.sock

REST API 端点

虚拟机管理器（VMM）操作

操作	端点	请求体	响应体	前提条件
检查 REST API 的可用性	`/vmm.ping`	N/A	`/schemas/VmmPingResponse`	N/A
关闭 VMM	`/vmm.shutdown`	N/A	N/A	VMM 正在运行

虚拟机（VM）操作

操作	端点	请求体	响应体	前提条件
创建虚拟机	`/vm.create`	`/schemas/VmConfig`	N/A	虚拟机尚未创建
删除虚拟机	`/vm.delete`	N/A	N/A	N/A
启动虚拟机	`/vm.boot`	N/A	N/A	虚拟机已创建但未启动
关闭虚拟机	`/vm.shutdown`	N/A	N/A	虚拟机已启动
重启虚拟机	`/vm.reboot`	N/A	N/A	虚拟机已启动
触发虚拟机电源按钮	`/vm.power-button`	N/A	N/A	虚拟机已启动
暂停虚拟机	`/vm.pause`	N/A	N/A	虚拟机已启动
恢复虚拟机	`/vm.resume`	N/A	N/A	虚拟机已暂停
对虚拟机进行快照任务	`/vm.snapshot`	`/schemas/VmSnapshotConfig`	N/A	虚拟机已暂停
对虚拟机进行 coredump *	`/vm.coredump`	`/schemas/VmCoredumpData`	N/A	虚拟机已暂停
从快照恢复虚拟机	`/vm.restore`	`/schemas/RestoreConfig`	N/A	虚拟机已创建但未启动
向/从虚拟机添加/移除 CPU	`/vm.resize`	`/schemas/VmResize`	N/A	虚拟机已启动
向虚拟机添加/删除内存	`/vm.resize`	`/schemas/VmResize`	N/A	虚拟机已启动
向 zene 添加/删除内存	`/vm.resize-zone`	`/schemas/VmResizeZone`	N/A	虚拟机已启动
导出(Dump)虚拟机信息	`/vm.info`	N/A	`/schemas/VmInfo`	虚拟机已创建
向虚拟机添加 VFIO PCI 设备	`/vm.add-device`	`/schemas/VmAddDevice`	`/schemas/PciDeviceInfo`	虚拟机已启动
向虚拟机添加磁盘设备	`/vm.add-disk`	`/schemas/DiskConfig`	`/schemas/PciDeviceInfo`	虚拟机已启动
向虚拟机添加文件系统设备	`/vm.add-fs`	`/schemas/FsConfig`	`/schemas/PciDeviceInfo`	虚拟机已启动
向虚拟机添加持久内存设备	`/vm.add-pmem`	`/schemas/PmemConfig`	`/schemas/PciDeviceInfo`	虚拟机已启动
向虚拟机添加网络设备	`/vm.add-net`	`/schemas/NetConfig`	`/schemas/PciDeviceInfo`	虚拟机已启动
向虚拟机添加用户空间 PCI 设备	`/vm.add-user-device`	`/schemas/VmAddUserDevice`	`/schemas/PciDeviceInfo`	虚拟机已启动
向虚拟机添加 vdpa 设备	`/vm.add-vdpa`	`/schemas/VdpaConfig`	`/schemas/PciDeviceInfo`	虚拟机已启动
为虚拟机添加 vsock 设备	`/vm.add-vsock`	`/schemas/VsockConfig`	`/schemas/PciDeviceInfo`	虚拟机已启动
从虚拟机中移除设备	`/vm.remove-device`	`/schemas/VmRemoveDevice`	N/A	虚拟机已启动
转储(Dump)虚拟机计数器	`/vm.counters`	N/A	`/schemas/VmCounters`	虚拟机已启动
注入 NMI	`/vm.nmi`	N/A	N/A	虚拟机已启动
准备接收迁移	`/vm.receive-migration`	`/schemas/ReceiveMigrationData`	N/A	N/A
开始向目标发送迁移	`/vm.send-migration`	`/schemas/SendMigrationData`	N/A	虚拟机已启动，并启用了（共享内存或大页）

vmcoredump 操作仅适用于 x86_64 架构，并且只有在 guest_debug 功能启用时才能执行。如果没有此功能，相应的 REST API 或 D-Bus API 端点将不可用。

REST API 示例

注意要先确保 cloud-hypervisor 有 net_admin 特权:

# 确保 cloud-hypervisor 有 net_admin 特权
# which cloud-hypervisor
# /home/sky/work/soft/cloudhypervisor/bin/cloud-hypervisor
sudo setcap cap_net_admin+ep /home/sky/work/soft/cloudhypervisor/bin/cloud-hypervisor

不然涉及到网络操作时会报错 Operation not permitted, 例如:

$ curl --unix-socket /tmp/cloud-hypervisor.sock -i -X PUT 'http://localhost/api/v1/vm.boot'
HTTP/1.1 500 
Server: Cloud Hypervisor API
Connection: keep-alive
Content-Type: application/json
Content-Length: 226

["Error from API","The VM could not boot","Error from device manager","Cannot create virtio-net device","Failed to open taps","Open tap device failed","Unable to configure tap interface","Operation not permitted (os error 1)"]%

对于以下示例集，我们假设 Cloud Hypervisor 已启动，并且 REST API 在 /tmp/cloud-hypervisor.sock 可用:

cloud-hypervisor --api-socket /tmp/cloud-hypervisor.sock

备注: 这里启动的是 cloud-hypervisor VMM 进程, 后面可以通过 /tmp/cloud-hypervisor.sock 进行 unix domain socket 通讯.

可以开启两个终端, 一个执行上面的命令启动 cloud-hypervisor VMM 进程, 稍后 vm 启动之后可以登录和操作这个新启动的 vm. 另一个终端上执行各种操作命令.

创建虚拟机

我们想要创建一个具有以下特征的虚拟机：

4 vCPUs 4 个 vCPU
1 GB 内存
1 个基于 virtio 的网络接口
从位于 /opt/clh/kernel/vmlinux-virtio-fs-virtio-iommu 的定制 5.6.0-rc4 Linux 内核直接内核启动
使用一个位于 /opt/clh/images/focal-server-cloudimg-amd64.raw 的 Ubuntu 镜像作为其 rootfs

在另外一个终端中执行:

curl --unix-socket /tmp/cloud-hypervisor.sock -i \
     -X PUT 'http://localhost/api/v1/vm.create'  \
     -H 'Accept: application/json'               \
     -H 'Content-Type: application/json'         \
     -d '{
         "cpus":{"boot_vcpus": 4, "max_vcpus": 4},
         "payload":{"kernel":"/home/sky/work/code/cloud-hypervisor/linux-cloud-hypervisor/arch/x86/boot/compressed/vmlinux.bin", "cmdline":"console=ttyS0 console=hvc0 root=/dev/vda1 rw"},
         "disks":[{"path":"/home/sky/work/soft/cloudhypervisor/fireware/focal-server-cloudimg-amd64.raw"}],
         "rng":{"src":"/dev/urandom"},
         "net":[{"ip":"192.168.10.10", "mask":"255.255.255.0", "mac":"12:34:56:78:90:01"}]
         }'

这里重用了之前文档中构建的 linux 内核 6.12 内核和 Ubuntu image:

https://www.cloudhypervisor.org/docs/prologue/quick-start/#custom-kernel-and-disk-image

如果成功,则返回 response:

HTTP/1.1 204 
Server: Cloud Hypervisor API
Connection: keep-alive

启动虚拟机

创建虚拟机后，我们可以启动它：

curl --unix-socket /tmp/cloud-hypervisor.sock -i -X PUT 'http://localhost/api/v1/vm.boot'

如果成功,则返回 response (和前面一样):

HTTP/1.1 204 
Server: Cloud Hypervisor API
Connection: keep-alive

此时启动 cloud hypervisor vmm 的终端会显示 vm 创建并开始启动 ubuntu 虚拟机, 出现如下内容:

cloud-hypervisor:  24.616571s: <vcpu0> WARN:devices/src/legacy/debug_port.rs:77 -- [Debug I/O port: Kernel code 0x40] 0.018741 seconds
[    0.092310] Non-volatile memory driver v1.3
[    0.092879] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds).
[    0.094172] brd: module loaded
[    0.094994] loop: module loaded
[    0.095309] virtio_blk virtio1: 1/0/0 default/read/poll queues
[    0.095785] virtio_blk virtio1: [vda] 4612096 512-byte logical blocks (2.36 GB/2.20 GiB)
[    0.097155]  vda: vda1 vda14 vda15
[    0.097392] zram: Added device: zram0
[    0.097816] null_blk: disk nullb0 created
[    0.098028] null_blk: module loaded
[    0.098308] tun: Universal TUN/TAP device driver, 1.6
[    0.099701] VFIO - User Level meta-driver version: 0.3
[    0.100014] mousedev: PS/2 mouse device common for all mice
[    0.100549] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev
[    0.101084] device-mapper: multipath round-robin: version 1.2.0 loaded
[    0.101401] intel_pstate: CPU model not supported
[    0.101686] hid: raw HID events driver (C) Jiri Kosina
[    0.102023] Initializing XFRM netlink socket
[    0.102242] NET: Registered PF_PACKET protocol family
[    0.102502] NET: Registered PF_KEY protocol family
[    0.102875] NET: Registered PF_VSOCK protocol family
[    0.103105] IPI shorthand broadcast: enabled
[    0.103400] AES CTR mode by8 optimization enabled
[    0.105347] sched_clock: Marking stable (72001308, 32049962)->(118964763, -14913493)
[    0.105809] registered taskstats version 1
[    0.106657] Demotion targets for Node 0: null
[    0.106949] Key type .fscrypt registered
[    0.107137] Key type fscrypt-provisioning registered
[    0.108865] clk: Disabling unused clocks
[    0.116017] EXT4-fs (vda1): mounted filesystem 0101c7fc-3b92-405d-87d1-ab167be30b9d r/w with ordered data mode. Quota mode: disabled.
[    0.117105] VFS: Mounted root (ext4 filesystem) on device 254:1.
[    0.117843] devtmpfs: mounted
[    0.118491] Freeing unused decrypted memory: 2028K
[    0.119130] Freeing unused kernel image (initmem) memory: 2820K
[    0.119570] Write protecting the kernel read-only data: 18432k
[    0.120403] Freeing unused kernel image (rodata/data gap) memory: 2044K
cloud-hypervisor:  24.756056s: <vcpu2> WARN:devices/src/legacy/debug_port.rs:77 -- [Debug I/O port: Kernel code 0x41] 0.158220 seconds
[    0.120848] Run /sbin/init as init process
[    0.154021] systemd[1]: systemd 245.4-4ubuntu3.24 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[    0.155677] systemd[1]: Detected virtualization kvm.
[    0.156071] systemd[1]: Detected architecture x86-64.

Welcome to Ubuntu 20.04.6 LTS!

[    0.202215] systemd[1]: Set hostname to <cloud>.
[    0.292433] systemd[1]: Configuration file /run/systemd/system/netplan-ovs-cleanup.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
[    0.297285] systemd[1]: /lib/systemd/system/snapd.service:23: Unknown key name 'RestartMode' in section 'Service', ignoring.
[    0.314391] systemd[1]: Created slice system-modprobe.slice.
[  OK  ] Created slice system-modprobe.slice.
[    0.314830] systemd[1]: Created slice system-serial\x2dgetty.slice.
[  OK  ] Created slice system-serial\x2dgetty.slice.
[    0.315183] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[  OK  ] Created slice system-systemd\x2dfsck.slice.
[    0.315458] systemd[1]: Created slice User and Session Slice.
[  OK  ] Created slice User and Session Slice.
[    0.315699] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[  OK  ] Started Forward Password Requests to Wall Directory Watch.
[    0.316017] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[  OK  ] Set up automount Arbitrary Executa…le Formats File System Automount Point.
[    0.316261] systemd[1]: Reached target User and Group Name Lookups.
[  OK  ] Reached target User and Group Name Lookups.
[    0.316436] systemd[1]: Reached target Slices.
[  OK  ] Reached target Slices.
[    0.316564] systemd[1]: Reached target Mounting snaps.
[  OK  ] Reached target Mounting snaps.
[    0.316700] systemd[1]: Reached target Swap.
[  OK  ] Reached target Swap.
[    0.316858] systemd[1]: Listening on Device-mapper event daemon FIFOs.
[  OK  ] Listening on Device-mapper event daemon FIFOs.
[    0.317077] systemd[1]: Listening on LVM2 poll daemon socket.
[  OK  ] Listening on LVM2 poll daemon socket.
[    0.317244] systemd[1]: Listening on multipathd control socket.
[  OK  ] Listening on multipathd control socket.
[    0.317440] systemd[1]: Listening on Syslog Socket.
[  OK  ] Listening on Syslog Socket.
[    0.317598] systemd[1]: Listening on fsck to fsckd communication Socket.
[  OK  ] Listening on fsck to fsckd communication Socket.
[    0.317781] systemd[1]: Listening on initctl Compatibility Named Pipe.
[  OK  ] Listening on initctl Compatibility Named Pipe.
[    0.318037] systemd[1]: Listening on Journal Audit Socket.
[  OK  ] Listening on Journal Audit Socket.
[    0.318221] systemd[1]: Listening on Journal Socket (/dev/log).
[  OK  ] Listening on Journal Socket (/dev/log).
[    0.318433] systemd[1]: Listening on Journal Socket.
[  OK  ] Listening on Journal Socket.
[    0.318616] systemd[1]: Listening on Network Service Netlink Socket.
[  OK  ] Listening on Network Service Netlink Socket.
[    0.318803] systemd[1]: Listening on udev Control Socket.
[  OK  ] Listening on udev Control Socket.
[    0.318952] systemd[1]: Listening on udev Kernel Socket.
[  OK  ] Listening on udev Kernel Socket.
[    0.348268] systemd[1]: Mounting Huge Pages File System...
         Mounting Huge Pages File System...
[    0.349953] systemd[1]: Mounting POSIX Message Queue File System...
         Mounting POSIX Message Queue File System...
[    0.351493] systemd[1]: Mounting Kernel Debug File System...
         Mounting Kernel Debug File System...
[    0.352253] systemd[1]: Condition check resulted in Kernel Trace File System being skipped.
[    0.353759] systemd[1]: Starting Journal Service...
         Starting Journal Service...
[    0.355227] systemd[1]: Starting Set the console keyboard layout...
         Starting Set the console keyboard layout...
[    0.355804] systemd[1]: Condition check resulted in Create list of static device nodes for the current kernel being skipped.
[    0.356820] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling...
         Starting Monitoring of LVM2 mirror…. using dmeventd or progress polling...
[    0.358029] systemd[1]: Starting Load Kernel Module chromeos_pstore...
         Starting Load Kernel Module chromeos_pstore...
[    0.358902] systemd[1]: Starting Load Kernel Module drm...
         Starting Load Kernel Module drm...
[    0.359573] systemd[1]: Starting Load Kernel Module efi_pstore...
         Starting Load Kernel Module efi_pstore...
[    0.360210] systemd[1]: Starting Load Kernel Module pstore_blk...
         Starting Load Kernel Module pstore_blk...
[    0.360821] systemd[1]: Starting Load Kernel Module pstore_zone...
         Starting Load Kernel Module pstore_zone...
[    0.361651] systemd[1]: Starting Load Kernel Module ramoops...
         Starting Load Kernel Module ramoops...
[    0.361935] systemd[1]: Condition check resulted in OpenVSwitch configuration for cleanup being skipped.
[    0.362638] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped.
[    0.362956] systemd[1]: Condition check resulted in File System Check on Root Device being skipped.
[    0.363610] systemd[1]: Starting Load Kernel Modules...
         Starting Load Kernel Modules...
[    0.364029] systemd[1]: Starting Remount Root and Kernel File Systems...
         Starting Remount Root and Kernel File Systems...
[    0.364482] systemd[1]: Starting udev Coldplug all Devices...
         Starting udev Coldplug all Devices...
[    0.365174] systemd[1]: Starting Uncomplicated firewall...
         Starting Uncomplicated firewall...
[    0.365928] systemd[1]: Mounted Huge Pages File System.
[  OK  ] Mounted Huge Pages File System.
[    0.366163] systemd[1]: Mounted POSIX Message Queue File System.
[  OK  ] Mounted POSIX Message Queue File System.
[    0.366362] systemd[1]: Mounted Kernel Debug File System.
[  OK  ] Mounted Kernel Debug File System.
[    0.366557] systemd[1]: modprobe@chromeos_pstore.service: Succeeded.
[    0.366762] systemd[1]: Finished Load Kernel Module chromeos_pstore.
[  OK  ] Finished Load Kernel Module chromeos_pstore.
[    0.367005] systemd[1]: modprobe@drm.service: Succeeded.
[    0.367183] systemd[1]: Finished Load Kernel Module drm.
[  OK  ] Finished Load Kernel Module drm.
[    0.367415] systemd[1]: modprobe@efi_pstore.service: Succeeded.
[    0.367625] systemd[1]: Finished Load Kernel Module efi_pstore.
[  OK  ] Finished Load Kernel Module efi_pstore.
[    0.367882] systemd[1]: modprobe@pstore_blk.service: Succeeded.
[    0.368113] systemd[1]: Finished Load Kernel Module pstore_blk.
[  OK  ] Finished Load Kernel Module pstore_blk.
[    0.368360] systemd[1]: modprobe@pstore_zone.service: Succeeded.
[    0.368563] systemd[1]: Finished Load Kernel Module pstore_zone.
[  OK  ] Finished Load Kernel Module pstore_zone.
[    0.368801] systemd[1]: modprobe@ramoops.service: Succeeded.
[    0.368991] systemd[1]: Finished Load Kernel Module ramoops.
[  OK  ] Finished Load Kernel Module ramoops.
[    0.369206] systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
[    0.369449] systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
[    0.369681] systemd[1]: Failed to start Load Kernel Modules.
[FAILED] Failed to start Load Kernel Modules.
See 'systemctl status systemd-modules-load.service' for details.
[    0.370099] systemd[1]: Finished Uncomplicated firewall.
[  OK  ] Finished Uncomplicated firewall.
[    0.370580] systemd[1]: Mounting FUSE Control File System...
         Mounting FUSE Control File System...
[    0.370969] systemd[1]: Mounting Kernel Configuration File System...
         Mounting Kernel Configuration File System...
[    0.371325] systemd[1]: Starting Apply Kernel Variables...
         Starting Apply Kernel Variables...
[    0.372044] systemd[1]: Mounted FUSE Control File System.
[  OK  ] Mounted FUSE Control File System.
[    0.372315] systemd[1]: Mounted Kernel Configuration File System.
[  OK  ] Mounted Kernel Configuration File System.
[    0.374224] systemd[1]: Started Journal Service.
[  OK  ] Started Journal Service.
[  OK  ] Finished Apply Kernel Variables.
[  OK  ] Finished udev Coldplug all Devices.
         Starting udev Wait for Complete Device Initialization...
[  OK  ] Finished Remount Root and Kernel File Systems.
         Starting Flush Journal to Persistent Storage...
         Starting Load/Save Random Seed...
         Starting Create System Users...
[  OK  ] Finished Set the console keyboard layout.
[  OK  ] Finished Create System Users.
         Starting Create Static Device Nodes in /dev...
[  OK  ] Finished Create Static Device Nodes in /dev.
         Starting udev Kernel Device Manager...
[  OK  ] Finished Load/Save Random Seed.
[  OK  ] Finished Flush Journal to Persistent Storage.
[  OK  ] Started udev Kernel Device Manager.
[  OK  ] Started Dispatch Password Requests to Console Directory Watch.
[  OK  ] Reached target Local Encrypted Volumes.
         Starting Network Service...
[  OK  ] Started Network Service.
         Starting Wait for Network to be Configured...
[  OK  ] Found device /dev/ttyS0.
[  OK  ] Found device /dev/hvc0.
         Mounting Arbitrary Executable File Formats File System...
[  OK  ] Mounted Arbitrary Executable File Formats File System.
[  OK  ] Found device /dev/disk/by-label/UEFI.
[  OK  ] Finished Wait for Network to be Configured.
[  OK  ] Finished udev Wait for Complete Device Initialization.
         Starting Device-Mapper Multipath Device Controller...
[  OK  ] Finished Monitoring of LVM… dmeventd or progress polling.
[  OK  ] Started Device-Mapper Multipath Device Controller.
[  OK  ] Reached target Local File Systems (Pre).
         Mounting Mount unit for core20, revision 2599...
         Mounting Mount unit for lxd, revision 32662...
         Mounting Mount unit for snapd, revision 24671...
         Starting File System Check on /dev/disk/by-label/UEFI...
[  OK  ] Started File System Check Daemon to report status.
[  OK  ] Finished File System Check on /dev/disk/by-label/UEFI.
         Mounting /boot/efi...
[FAILED] Failed to mount Mount unit for core20, revision 2599.
See 'systemctl status snap-core20-2599.mount' for details.
[  OK  ] Mounted /boot/efi.
[FAILED] Failed to mount Mount unit for lxd, revision 32662.
See 'systemctl status snap-lxd-32662.mount' for details.
[DEPEND] Dependency failed for Serv…snap application lxd.activate.
[DEPEND] Dependency failed for Sock…r snap application lxd.daemon.
[FAILED] Failed to mount Mount unit for snapd, revision 24671.
See 'systemctl status snap-snapd-24671.mount' for details.
[  OK  ] Reached target Mounted snaps.
[  OK  ] Reached target Local File Systems.
         Starting Set console font and keymap...
         Starting Create final runt…dir for shutdown pivot root...
         Starting Tell Plymouth To Write Out Runtime Data...
         Starting Create Volatile Files and Directories...
[  OK  ] Finished Create final runtime dir for shutdown pivot root.
[  OK  ] Finished Set console font and keymap.
[  OK  ] Finished Create Volatile Files and Directories.
         Starting Network Name Resolution...
         Starting Network Time Synchronization...
         Starting Update UTMP about System Boot/Shutdown...
[  OK  ] Finished Tell Plymouth To Write Out Runtime Data.
[  OK  ] Finished Update UTMP about System Boot/Shutdown.
[  OK  ] Started Network Time Synchronization.
[  OK  ] Reached target System Initialization.
[  OK  ] Started Daily Cleanup of Temporary Directories.
[  OK  ] Reached target Paths.
[  OK  ] Reached target System Time Set.
[  OK  ] Reached target System Time Synchronized.
[  OK  ] Started Daily apt download activities.
[  OK  ] Started Daily apt upgrade and clean activities.
[  OK  ] Started Periodic ext4 Online Metadata Check for All Filesystems.
[  OK  ] Started Discard unused blocks once a week.
[  OK  ] Started Refresh fwupd metadata regularly.
[  OK  ] Started Daily rotation of log files.
[  OK  ] Started Daily man-db regeneration.
[  OK  ] Started Message of the Day.
[  OK  ] Reached target Timers.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Listening on Open-iSCSI iscsid Socket.
         Starting Socket activation for snappy daemon.
[  OK  ] Listening on UUID daemon activation socket.
[  OK  ] Listening on Socket activation for snappy daemon.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Basic System.
         Starting Accounts Service...
[  OK  ] Started D-Bus System Message Bus.
[  OK  ] Started Save initial kernel messages after boot.
         Starting Remove Stale Online ext4 Metadata Check Snapshots...
         Starting Record successful boot for GRUB...
[  OK  ] Started irqbalance daemon.
         Starting Dispatcher daemon for systemd-networkd...
         Starting Authorization Manager...
         Starting System Logging Service...
[  OK  ] Reached target Login Prompts (Pre).
         Starting Wait until snapd is fully seeded...
         Starting Snap Daemon...
         Starting Login Service...
         Starting Disk Manager...
         Starting Rotate log files...
         Starting Daily man-db regeneration...
[  OK  ] Started Network Name Resolution.
[  OK  ] Reached target Network.
[  OK  ] Reached target Network is Online.
[  OK  ] Reached target Host and Network Name Lookups.
[  OK  ] Reached target Remote File Systems (Pre).
[  OK  ] Reached target Remote File Systems.
         Starting LSB: automatic crash report generation...
         Starting Deferred execution scheduler...
         Starting Availability of block devices...
[  OK  ] Started Regular background program processing daemon.
         Starting Pollinate to seed…udo random number generator...
         Starting Permit User Sessions...
[  OK  ] Finished Remove Stale Onli…ext4 Metadata Check Snapshots.
[  OK  ] Finished Availability of block devices.
[  OK  ] Started Deferred execution scheduler.
[  OK  ] Finished Permit User Sessions.
         Starting Hold until boot process finishes up...
         Starting Terminate Plymouth Boot Screen...
[  OK  ] Finished Hold until boot process finishes up.
[  OK  ] Started Serial Getty on hvc0.
[  OK  ] Started Serial Getty on ttyS0.
         Starting Set console scheme...
[  OK  ] Started System Logging Service.
[  OK  ] Finished Set console scheme.
[  OK  ] Created slice system-getty.slice.
[  OK  ] Started Getty on tty1.
[  OK  ] Reached target Login Prompts.
[  OK  ] Finished Record successful boot for GRUB.
         Starting GRUB failed boot detection...
[  OK  ] Finished Terminate Plymouth Boot Screen.
[  OK  ] Started Login Service.
[  OK  ] Started Unattended Upgrades Shutdown.
[  OK  ] Started LSB: automatic crash report generation.
[  OK  ] Started Authorization Manager.
         Starting Modem Manager...
[  OK  ] Finished GRUB failed boot detection.
[  OK  ] Started Accounts Service.
[  OK  ] Started Disk Manager.
[  OK  ] Finished Rotate log files.
[  OK  ] Started Modem Manager.
[  OK  ] Finished Pollinate to seed the pseudo random number generator.
         Starting OpenBSD Secure Shell server...
[  OK  ] Started Dispatcher daemon for systemd-networkd.
[  OK  ] Started OpenBSD Secure Shell server.
[  OK  ] Started Snap Daemon.
         Starting Time & Date Service...
[  OK  ] Started Time & Date Service.
[  OK  ] Finished Wait until snapd is fully seeded.
[  OK  ] Reached target Multi-User System.
[  OK  ] Reached target Graphical Interface.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Finished Update UTMP about System Runlevel Changes.
[  OK  ] Finished Daily man-db regeneration.

Ubuntu 20.04.6 LTS cloud hvc0

cloud login:

用默认帐号 cloud/cloud123 登录之后, 可以看到一些系统信息:

$ uname -a
Linux cloud 6.12.8+ #1 SMP Tue Nov 18 15:50:32 CST 2025 x86_64 x86_64 x86_64 GNU/Linux

这是 ubuntu 20.04 跑在了 linux 6.12 内核上. 查看网络信息:

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 12:34:56:78:90:01 brd ff:ff:ff:ff:ff:ff
    altname enp0s3

网卡创建了, ens3 的 mac 地址 12:34:56:78:90:01 是之前创建 microvm 时指定的 mac 地址.

但这里网络没能生效, "ip":"192.168.10.10" 没能设置成功, 稍后再看.

pci 设备非常的少:

$ lspci
00:00.0 Host bridge: Intel Corporation Device 0d57
00:01.0 Unassigned class [ffff]: Red Hat, Inc. Virtio console (rev 01)
00:02.0 Mass storage controller: Red Hat, Inc. Virtio block device (rev 01)
00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device (rev 01)
00:04.0 Unassigned class [ffff]: Red Hat, Inc. Virtio RNG (rev 01)

一块 Virtio network device 网卡, 一个 Virtio block device 的 mass 存储.

查看内存信息:

$ free -h
              total        used        free      shared  buff/cache   available
Mem:          473Mi        94Mi       208Mi       0.0Ki       171Mi       357Mi
Swap:            0B          0B          0B

查看 cpu 信息:

lscpu
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Byte Order:                           Little Endian
Address sizes:                        46 bits physical, 48 bits virtual
CPU(s):                               4
On-line CPU(s) list:                  0-3
Thread(s) per core:                   1
Core(s) per socket:                   4
Socket(s):                            1
NUMA node(s):                         1
Vendor ID:                            GenuineIntel
CPU family:                           6
Model:                                186
Model name:                           Genuine Intel(R) 0000
Stepping:                             2
CPU MHz:                              2611.200
BogoMIPS:                             5222.40
Virtualization:                       VT-x
Hypervisor vendor:                    KVM
Virtualization type:                  full
L1d cache:                            96 KiB
L1i cache:                            64 KiB
L2 cache:                             1.3 MiB
L3 cache:                             24 MiB
NUMA node0 CPU(s):                    0-3
Vulnerability Gather data sampling:   Not affected
Vulnerability Itlb multihit:          Not affected
Vulnerability L1tf:                   Not affected
Vulnerability Mds:                    Not affected
Vulnerability Meltdown:               Not affected
Vulnerability Mmio stale data:        Not affected
Vulnerability Reg file data sampling: Mitigation; Clear Register File
Vulnerability Retbleed:               Not affected
Vulnerability Spec rstack overflow:   Not affected
Vulnerability Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer san
                                      itization
Vulnerability Spectre v2:             Vulnerable: eIBRS with unprivileged eBPF
Vulnerability Srbds:                  Not affected
Vulnerability Tsx async abort:        Not affected
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cm
                                      ov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdp
                                      e1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop
                                      _tsc cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 
                                      sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xs
                                      ave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cp
                                      uid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow fle
                                      xpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 sme
                                      p bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni 
                                      xsaveopt xsavec xgetbv1 xsaves avx_vnni arat vnmi umip pku 
                                      waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm m
                                      d_clear serialize flush_l1d arch_capabilities

因为创建 vm 时的 cpu 参数设置的是 "cpus":{"boot_vcpus": 4, "max_vcpus": 4}, 设置了 4 个 cpu. 目前 4 个 cpu 都是 online 状态:

CPU(s):                               4
On-line CPU(s) list:                  0-3
Thread(s) per core:                   1
Core(s) per socket:                   4

dump 虚拟机信息

我们可以获取任何虚拟机创建后的信息：

curl --unix-socket /tmp/cloud-hypervisor.sock -i \
     -X GET 'http://localhost/api/v1/vm.info' \
     -H 'Accept: application/json'

返回应答:

HTTP/1.1 200 
Server: Cloud Hypervisor API
Connection: keep-alive
Content-Type: application/json
Content-Length: 3329

http body 为 json, 将格式转为可读格式后, 内容为:

{
  "config": {
    "cpus": {
      "boot_vcpus": 4,
      "max_vcpus": 4,
      "topology": null,
      "kvm_hyperv": false,
      "max_phys_bits": 46,
      "affinity": null,
      "features": {
        "amx": false
      }
    },
    "memory": {
      "size": 536870912,
      "mergeable": false,
      "hotplug_method": "Acpi",
      "hotplug_size": null,
      "hotplugged_size": null,
      "shared": false,
      "hugepages": false,
      "hugepage_size": null,
      "prefault": false,
      "zones": null,
      "thp": true
    },
    "payload": {
      "firmware": null,
      "kernel": "/home/sky/work/code/cloud-hypervisor/linux-cloud-hypervisor/arch/x86/boot/compressed/vmlinux.bin",
      "cmdline": "console=ttyS0 console=hvc0 root=/dev/vda1 rw",
      "initramfs": null
    },
    "rate_limit_groups": null,
    "disks": [
      {
        "path": "/home/sky/work/soft/cloudhypervisor/fireware/focal-server-cloudimg-amd64.raw",
        "readonly": false,
        "direct": false,
        "iommu": false,
        "num_queues": 1,
        "queue_size": 128,
        "vhost_user": false,
        "vhost_socket": null,
        "rate_limit_group": null,
        "rate_limiter_config": null,
        "id": "_disk0",
        "disable_io_uring": false,
        "disable_aio": false,
        "pci_segment": 0,
        "serial": null,
        "queue_affinity": null
      }
    ],
    "net": [
      {
        "tap": null,
        "ip": "192.168.10.10",
        "mask": "255.255.255.0",
        "mac": "12:34:56:78:90:01",
        "host_mac": "12:94:98:54:3d:aa",
        "mtu": null,
        "iommu": false,
        "num_queues": 2,
        "queue_size": 256,
        "vhost_user": false,
        "vhost_socket": null,
        "vhost_mode": "Client",
        "id": "_net1",
        "fds": null,
        "rate_limiter_config": null,
        "pci_segment": 0,
        "offload_tso": true,
        "offload_ufo": true,
        "offload_csum": true
      }
    ],
    "rng": {
      "src": "/dev/urandom",
      "iommu": false
    },
    "balloon": null,
    "fs": null,
    "pmem": null,
    "serial": {
      "file": null,
      "mode": "Null",
      "iommu": false,
      "socket": null
    },
    "console": {
      "file": null,
      "mode": "Tty",
      "iommu": false,
      "socket": null
    },
    "debug_console": {
      "file": null,
      "mode": "Off",
      "iobase": 233
    },
    "devices": null,
    "user_devices": null,
    "vdpa": null,
    "vsock": null,
    "pvpanic": false,
    "iommu": false,
    "numa": null,
    "watchdog": false,
    "pci_segments": null,
    "platform": null,
    "tpm": null,
    "landlock_enable": false,
    "landlock_rules": null
  },
  "state": "Running",
  "memory_actual_size": 536870912,
  "device_tree": {
    "_virtio-pci-_net1": {
      "id": "_virtio-pci-_net1",
      "resources": [
        {
          "PciBar": {
            "index": 0,
            "base": 70364448161792,
            "size": 524288,
            "type_": "Mmio64",
            "prefetchable": false
          }
        }
      ],
      "parent": null,
      "children": ["_net1"],
      "pci_bdf": "0000:00:03.0"
    },
    "__ioapic": {
      "id": "__ioapic",
      "resources": [],
      "parent": null,
      "children": [],
      "pci_bdf": null
    },
    "_virtio-pci-__console": {
      "id": "_virtio-pci-__console",
      "resources": [
        {
          "PciBar": {
            "index": 0,
            "base": 70364448686080,
            "size": 524288,
            "type_": "Mmio64",
            "prefetchable": false
          }
        }
      ],
      "parent": null,
      "children": ["__console"],
      "pci_bdf": "0000:00:01.0"
    },
    "_disk0": {
      "id": "_disk0",
      "resources": [],
      "parent": "_virtio-pci-_disk0",
      "children": [],
      "pci_bdf": null
    },
    "_virtio-pci-__rng": {
      "id": "_virtio-pci-__rng",
      "resources": [
        {
          "PciBar": {
            "index": 0,
            "base": 70364447637504,
            "size": 524288,
            "type_": "Mmio64",
            "prefetchable": false
          }
        }
      ],
      "parent": null,
      "children": ["__rng"],
      "pci_bdf": "0000:00:04.0"
    },
    "__console": {
      "id": "__console",
      "resources": [],
      "parent": "_virtio-pci-__console",
      "children": [],
      "pci_bdf": null
    },
    "__rng": {
      "id": "__rng",
      "resources": [],
      "parent": "_virtio-pci-__rng",
      "children": [],
      "pci_bdf": null
    },
    "_net1": {
      "id": "_net1",
      "resources": [],
      "parent": "_virtio-pci-_net1",
      "children": [],
      "pci_bdf": null
    },
    "__serial": {
      "id": "__serial",
      "resources": [],
      "parent": null,
      "children": [],
      "pci_bdf": null
    },
    "_virtio-pci-_disk0": {
      "id": "_virtio-pci-_disk0",
      "resources": [
        {
          "PciBar": {
            "index": 0,
            "base": 3891789824,
            "size": 524288,
            "type_": "Mmio32",
            "prefetchable": false
          }
        }
      ],
      "parent": null,
      "children": ["_disk0"],
      "pci_bdf": "0000:00:02.0"
    }
  }
}

这台虚拟机的配置：4 个 vCPU、512MB 内存、一个磁盘、一个网卡、控制台和 RNG 设备。

重启虚拟机

可以重启已经启动的虚拟机：

curl --unix-socket /tmp/cloud-hypervisor.sock -i -X PUT 'http://localhost/api/v1/vm.reboot'

ubuntu 虚拟机非常快的就重启了, 目测 1 秒上下.

关闭虚拟机

启动后，我们可以通过 REST API 关闭虚拟机：

curl --unix-socket /tmp/cloud-hypervisor.sock -i -X PUT 'http://localhost/api/v1/vm.shutdown'

vm 退出后, 启动 cloud hypervisor vmm 的另外一个终端, 不会显示 vm 已经退出了, 只是不再相应. ctrl + c 可以退出.

D-Bus API

cloud hypervisor 提供了一个 D-Bus API 作为其 REST API 的替代方案。这个 D-Bus API 完全反映了 REST API 的功能，暴露了相同的端点组。由于它也消费/产生 JSON，因此可以作为一个即插即用的替代方案。

此外，D-Bus API 还以 D-Bus 信号的形式暴露了来自 event-monitor 的事件，用户可以订阅这些信号。更多详细信息，请参阅 D-Bus API 接口。

稍后看.

命令行界面

cloud hypervisor 命令行界面（CLI）只能用于启动 cloud hypervisor 二进制文件，即一旦 VMM 或虚拟机启动运行后，无法使用该界面控制它们。

如果您想检查 VMM 或在从 CLI 启动 cloud hypervisor 后控制虚拟机，您必须使用 REST API 或 D-Bus API。

从 CLI 中，您可以：

使用 CLI 选项构建虚拟机配置来创建和启动完整的虚拟机。运行 cloud-hypervisor --help 获取 CLI 选项的完整列表。与 D-Bus API 不同，一旦 cloud-hypervisor 二进制文件启动，REST API 即可用于控制和管理虚拟机。D-Bus API 不会自动启动，需要明确配置才能运行。
无需传递任何虚拟机配置选项，即可启动 REST API、D-Bus API 或两者同时启动。然后可以通过调用选择的 API 方法异步创建和启动虚拟机。需要注意的是，外部 API 并不互斥；同时运行 REST 和 D-Bus API 是可能的。

REST API、D-Bus API 和 CLI 架构关系

REST API、D-Bus API 和 CLI 都依赖于一个通用、内部的 API。

CLI 选项由 clap crate 解析，然后转换为内部 API 命令。

REST API 由使用 Firecracker 的 micro_http crate 的 HTTP 线程处理。与 CLI 类似，HTTP 请求最终会转换为内部 API 命令。

D-Bus API 使用 zbus crate 实现，并在其自己的线程中运行。每当它需要调用内部 API 时，会使用 blocking crate 在 zbus 的异步上下文中执行该调用。

总而言之，REST API、D-Bus API 和 CLI 本质上都是内部 API 的前端：

                                  +------------------+
                        REST API  |                  |
                       +--------->+    micro_http    +--------+
                       |          |                  |        |
                       |          +------------------+        |
                       |                                      |      +------------------------+
                       |                                      |      |                        |
+------------+         |            +----------+              |      |                        |
|            |         |  D-Bus API |          |              |      | +--------------+       |
|    User    +---------+----------->+   zbus   +--------------+------> | Internal API |       |
|            |         |            |          |              |      | +--------------+       |
+------------+         |            +----------+              |      |                        |
                       |                                      |      |                        |
                       |                                      |      +------------------------+
                       |            +----------+              |                 VMM
                       |     CLI    |          |              |
                       +----------->+   clap   +--------------+
                                    |          |
                                    +----------+

内部 API

Cloud Hypervisor 内部 API，如其名称所示，是 Cloud Hypervisor 不同线程（VMM、HTTP、D-Bus、控制循环等）之间发送命令和响应所使用的内部接口。

它基于 rust 的 Multi-Producer, Single-Consumer (MPSC)，而单一消费者（即 API 接收者）是 Cloud Hypervisor 的控制循环。

API 生产者包括处理 REST API 的 HTTP 线程、处理 D-Bus API 的 D-Bus 线程以及最初解析 CLI 的主线程。

目标和设计

内部 API 用于控制、管理和检查 Cloud Hypervisor VMM 及其客户机。它是通过 REST API、D-Bus API 或 CLI 接口处理外部、用户可见请求的后端。

该 API 遵循命令-响应方案，与 REST API 紧密对应。任何命令都必须得到响应。

命令是基于 MPSC 的消息，由 VMM 控制循环接收和处理。

为了让 VMM 控制循环能够响应任何内部 API 命令，它必须能够向 MPSC 发送者发送响应。为此，所有内部 API 命令的有效载荷都包含 MPSC 通道的发送端。

因此，任何内部 API 命令的发送者负责：

创建 MPSC 响应通道。
将响应通道的发送端作为内部 API 命令负载的一部分传递。
在响应通道的接收端等待内部 API 命令的响应。

端到端示例

为了进一步了解外部和内部 Cloud Hypervisor API 如何协同工作，让我们查看一个完整的虚拟机创建流程，从 REST API 调用到外部用户将收到的回复：

用户或运维向 Cloud Hypervisor REST API 发送 HTTP 请求以创建虚拟机：

shell
#!/usr/bin/env bash

 curl --unix-socket /tmp/cloud-hypervisor.sock -i \
 	-X PUT 'http://localhost/api/v1/vm.create'  \
 	-H 'Accept: application/json'               \
 	-H 'Content-Type: application/json'         \
 	-d '{
 		"cpus":{"boot_vcpus": 4, "max_vcpus": 4},
 		"payload":{"kernel":"/opt/clh/kernel/vmlinux-virtio-fs-virtio-iommu", "cmdline":"console=ttyS0 console=hvc0 root=/dev/vda1 rw"},
 		"disks":[{"path":"/opt/clh/images/focal-server-cloudimg-amd64.raw"}],
 		"rng":{"src":"/dev/urandom"},
 		"net":[{"ip":"192.168.10.10", "mask":"255.255.255.0", "mac":"12:34:56:78:90:01"}]
 		}'

Cloud Hypervisor HTTP 线程处理请求，并将 HTTP 请求的 JSON 正文反序列化为内部 VmConfig 结构。
Cloud Hypervisor HTTP 线程为内部 API 服务器创建了一个 MPSC 通道，用于发送其响应。
Cloud Hypervisor HTTP 线程准备一个用于创建虚拟机的内部 API 命令。该命令的负载由反序列化的 VmConfig 结构和响应通道组成：
```
VmCreate(Arc<Mutex<VmConfig>>, Sender<ApiResponse>)
```

Cloud Hypervisor HTTP 线程发送内部 API 命令，并等待响应：

// Send the VM creation request.
 api_sender
     .send(ApiRequest::VmCreate(config, response_sender))
     .map_err(ApiError::RequestSend)?;
 api_evt.write(1).map_err(ApiError::EventFdWrite)?;

 response_receiver.recv().map_err(ApiError::ResponseRecv)??;

Cloud Hypervisor 控制循环接收到该命令，因为它监听内部 API MPSC 通道：

// Read from the API receiver channel
let api_request = api_receiver.recv().map_err(Error::ApiRequestRecv)?;

Cloud Hypervisor 控制循环将接收到的内部 API 与 VmCreate 负载进行匹配，并从命令负载中提取 VmConfig 结构和发送者。它存储 VmConfig 结构，并回复给发送者（（HTTP 线程）：）

match api_request {
    ApiRequest::VmCreate(config, sender) => {
 	   // We only store the passed VM config.
 	   // The VM will be created when being asked to boot it.
 	   let response = if self.vm_config.is_none() {
 		   self.vm_config = Some(config);
 		   Ok(ApiResponsePayload::Empty)
 	   } else {
 		   Err(ApiError::VmAlreadyCreated)
 	   };

        sender.send(response).map_err(Error::ApiResponseSend)?;
    }

Cloud Hypervisor HTTP 线程将内部 API 命令响应作为其 VmCreate HTTP 处理程序的返回值。根据控制循环内部 API 响应，它生成适当的 HTTP 响应：

// Call vm_create()
match vm_create(api_notifier, api_sender, Arc::new(Mutex::new(vm_config)))
    .map_err(HttpError::VmCreate)
{
    Ok(_) => Response::new(Version::Http11, StatusCode::NoContent),
    Err(e) => error_response(e, StatusCode::InternalServerError),
}

Cloud Hypervisor HTTP 线程将形成的 HTTP 响应发送回用户。这由 micro_http 库抽象化。

Optimize: kernel docs

Sat, 15 Nov 2025 00:00:00 +0000

https://docs.kernel.org/filesystems/dax.html

Direct Access for files

动机

页面缓存（page cache）通常用于缓冲对文件的读写操作。它还用于通过调用 mmap 映射到用户空间的页面。

对于类内存的块设备，页缓存页面（page cache pages）将是原始存储的不必要副本。DAX 代码通过直接对存储设备执行读写操作来消除这个额外副本。对于文件映射，存储设备会直接映射到用户空间。

用法

如果你有一个支持 DAX 的块设备，可以像往常一样在其上创建文件系统。目前 DAX 代码仅支持块大小等于内核 PAGE_SIZE 的文件，因此在创建文件系统时可能需要指定块大小。

目前有 5 个文件系统支持 DAX：ext2、ext4、xfs、virtiofs 和 erofs。在这些文件系统上启用 DAX 的方式各不相同。

在 ext2 和 erofs 上启用 DAX

挂载文件系统时，在命令行上使用 -o dax 选项或在 /etc/fstab 的选项中添加 ‘dax’。这可以启用文件系统中所有文件的 DAX 功能。它等同于下面的 -o dax=always 行为。

在 xfs 和 ext4 上启用 DAX

摘要

存在一个内核文件访问模式标志 S_DAX，对应于 statx 标志 STATX_ATTR_DAX。有关此访问模式的详细信息，请参阅 statx(2) 的手册页。
存在一个持久的标志 FS_XFLAG_DAX，它可以应用于常规文件和目录。这个建议标志可以在任何时候设置或清除，但这样做不会立即影响 S_DAX 状态。
如果在目录上设置了持久的 FS_XFLAG_DAX 标志，那么随后在此目录中创建的所有常规文件和子目录都将继承此标志。在父目录上设置或清除此标志时已存在的文件和子目录不会受到此父目录修改的影响。
存在一些 dax 挂载选项可以覆盖 FS_XFLAG_DAX 在 S_DAX 标志设置中的值。假设底层存储支持 DAX，则以下情况成立：
- -o dax=inode 表示"遵循 FS_XFLAG_DAX"，这是默认设置。
- -o dax=never 表示"永不设置 S_DAX，忽略 FS_XFLAG_DAX。"
- -o dax=always 表示"始终设置 S_DAX 忽略 FS_XFLAG_DAX。"
- -o dax 是一个传统选项，它是 dax=always 的别名。
警告：选项 -o dax 可能会在未来被移除，因此 -o dax=always 是指定此行为的推荐方法。

注意：即使文件系统以 dax 选项挂载，FS_XFLAG_DAX 的修改和继承行为也保持不变。但是，直到文件系统以 dax=inode 重新挂载并且 inode 从内核内存中驱逐之前，内存中的 inode 状态（S_DAX）将被覆盖。
可以通过以下方式更改 S_DAX 策略：
- 在创建文件前根据需要设置父目录的 FS_XFLAG_DAX 标志
- 设置适当的 dax=“foo” 挂载选项
- 更改现有常规文件和目录上的 FS_XFLAG_DAX 标志。这具有下文 6) 中描述的运行时限制和约束。
通过切换持久化的 FS_XFLAG_DAX 标志来更改 S_DAX 策略时，对现有常规文件的更改只有在所有进程关闭这些文件后才会生效。

详情

每个文件有 2 个 dax 标志。一个是持久的 inode 设置（FS_XFLAG_DAX），另一个是表示该功能活动状态的易失性标志（S_DAX）。

FS_XFLAG_DAX 在文件系统中被保留。这个持久性配置设置可以使用 FS_IOC_FS[GS]`ETXATTR ioctl（参见 ioctl_xfs_fsgetxattr(2)）或诸如 ‘xfs_io’ 之类的工具进行设置、清除和/或查询。

新文件和目录在创建时会自动从其父目录继承 FS_XFLAG_DAX。因此，在创建目录时设置 FS_XFLAG_DAX 可以为整个子树设置默认行为。

为阐明继承关系，以下是 3 个示例：

Example A: 示例 A：

mkdir -p a/b/c
xfs_io -c 'chattr +x' a
mkdir a/b/c/d
mkdir a/e

------[outcome]------

dax: a,e
no dax: b,c,d

Example B: 示例 B：

mkdir a
xfs_io -c 'chattr +x' a
mkdir -p a/b/c/d

------[outcome]------

dax: a,b,c,d
no dax:

Example C: 示例 C：

mkdir -p a/b/c
xfs_io -c 'chattr +x' c
mkdir a/b/c/d

------[outcome]------

dax: c,d
no dax: a,b

当前启用状态(S_DAX)是在内核将文件 inode 实例化到内存时设置的。该状态基于底层媒体支持、FS_XFLAG_DAX 的值以及文件系统的 dax 挂载选项进行设置。

statx 可用于查询 S_DAX。

注意

只有常规文件才会设置 S_DAX 标志，因此 statx 绝不会指示目录上设置了 S_DAX。

即使底层介质不支持 dax 和/或文件系统被挂载选项覆盖，设置 FS_XFLAG_DAX 标志（无论是直接设置还是通过继承）仍然会发生。

在 virtiofs 上启用 DAX

virtiofs 上 DAX 的语义基本上与 ext4 和 xfs 上的语义相同，只是当指定了’-o dax=inode’时，virtiofs 客户端通过 FUSE 协议从 virtiofs 服务器获取是否启用 DAX 的提示，而不是持久的 FS_XFLAG_DAX 标志。也就是说，是否启用 DAX 完全由 virtiofs 服务器决定，而 virtiofs 服务器本身可能部署各种算法来做出此决定，例如取决于主机上的持久 FS_XFLAG_DAX 标志。

在客户机内部设置或清除持久性 FS_XFLAG_DAX 标志仍然受支持，但不能保证相应文件会启用或禁用 DAX。客户机内的用户仍需调用 statx(2) 并检查 statx 标志 STATX_ATTR_DAX，以查看是否为此文件启用了 DAX。

块驱动程序编写者的实现技巧

要在块驱动程序中支持 DAX，请实现’direct_access’块设备操作。该操作用于将扇区号（以 512 字节扇区为单位）转换为标识内存物理页面的页框号(pfn)。它还会返回一个可用于访问内存的内核虚拟地址。

direct_access 方法接受一个 ‘size’ 参数，表示请求的字节数。该函数应返回在该偏移量处可以连续访问的字节数。如果发生错误，它也可以返回一个负的 errno。

为了支持此方法，存储必须始终能够被 CPU 字节访问。如果您的设备使用分页技术通过较小的窗口暴露大量内存，那么您就无法实现 direct_access。同样，如果您的设备偶尔会使 CPU 长时间停滞，您也不应尝试实现 direct_access。

这些块设备可作为参考： - pmem：NVDIMM 持久内存驱动

文件系统编写者的实现技巧

文件系统支持包括：

通过在 i_flags 中设置 S_DAX 标志来添加将 inode 标记为 DAX 的支持
实现 ->read_iter 和 ->write_iter 操作，当 inode 设置了 S_DAX 标志时使用 dax_iomap_rw()
为 DAX 文件实现一个 mmap 文件操作，该操作在 VMA 上设置 VM_MIXEDMAP 和 VM_HUGEPAGE 标志，并将 vm_ops 设置为包含 fault、pmd_fault、page_mkwrite 和 pfn_mkwrite 的处理程序。这些处理程序可能应该调用 dax_iomap_fault() ，并传递适当的故障大小和 iomap 操作。
调用 iomap_zero_range() 为 DAX 文件传递适当的 iomap 操作，而不是 block_truncate_page()
确保在读取、写入、截断和缺页之间有足够的锁机制

用于分配块的 iomap 处理程序必须确保分配的块在返回前已清零并转换为已写入范围，以避免通过 mmap 暴露未初始化的数据。

处理介质错误

libnvdimm 子系统为每个 pmem 块设备（在 gendisk->badblocks 中）存储已知介质错误位置的记录。如果我们在此类位置或存在尚未发现的潜在错误的位置发生故障，应用程序可以预期会收到 SIGBUS。libnvdimm 还允许通过简单写入受影响的扇区来清除这些错误（通过 pmem 驱动，并且如果底层 NVDIMM 支持 ACPI 定义的 clear_poison DSM）。

由于 DAX IO 通常不会经过 driver/bio 路径，应用程序或系统管理员可以通过以下方式从先前的 backup/inbuilt 冗余中恢复丢失的数据：

删除受影响的文件，并从备份中恢复（系统管理员方式）：这将释放文件占用的文件系统块，下次分配这些块时，它们将被先清零，这个过程通过驱动程序完成，可以清除坏扇区。
截断或打孔处理文件中含有坏块的部分（至少需要打孔处理整个对齐的扇区，但不一定是整个文件系统块）。

这是两条基本路径，它们允许 DAX 文件系统在媒体错误存在的情况下继续运行。未来可以在此基础上构建更强大的错误恢复机制，例如，通过 DM 在块层提供的冗余/镜像，或者额外地在文件系统级别提供。这些机制必须依赖于上述两个基本原则：错误清除可以通过驱动程序发送 IO 来完成，或者通过清零（同样通过驱动程序）来完成。

不足之处

即使内核或其模块存储在支持 DAX 的文件系统上，该文件系统位于支持 DAX 的块设备上，它们仍然会被复制到 RAM 中。

DAX 代码在具有虚拟映射缓存的架构（如 ARM、MIPS 和 SPARC）上无法正常工作。

对从 DAX 文件 mmapped 的用户内存范围调用 get_user_pages() ，当没有 struct page 来描述这些页面时会失败。这个问题已经在一些设备驱动程序中得到解决，通过添加可选的 struct page 支持来支持驱动程序控制的页面（参见 drivers/nvdimm 中的 CONFIG_NVDIMM_PFN 示例，了解如何实现这一点）。在非 struct page 情况下，从非 DAX 文件对这些内存范围进行 O_DIRECT 读取/写入将会失败

注意

对 DAX 文件的 O_DIRECT 读取/写入是有效的，关键在于所访问的内存）。在非 struct page 情况下，其他无法实现的功能包括 RDMA、 sendfile() 和 splice() 。

Optimize: 概述

Sat, 15 Nov 2025 00:00:00 +0000

高密部署意味着 CPU 必然是超分 (Overcommit) 的。

vCPU 拓扑:

建议 MicroVM 配置为 1 vCPU。对于微服务或函数计算场景，单核足以处理，且调度开销最小。
Host 调度器调整:

不要在 Host 上对 MicroVM 进行严格的物理核绑定 (Pinning)，因为高密场景下这会导致碎片化。依赖 Linux CFS (Completely Fair Scheduler) 进行调度。

Halt Polling: 调整 KVM 的 halt_poll_ns。对于高密且 I/O 频繁的场景，适当降低该值，让 vCPU 空闲时尽快释放物理 CPU 资源给其他 VM，而不是空转等待唤醒。

VMM (Virtual Machine Monitor) 进程开销:

Cloud Hypervisor 是多线程模型。确保其辅助线程（如 vhost-user 线程, API 线程）不会抢占过多的计算资源。

Optimize: 概述

Sat, 15 Nov 2025 00:00:00 +0000

内核参数调优：

调整 vm.swappiness , dirty_ratio 参数，减少内存抖动

Optimize: 概述

Sat, 15 Nov 2025 00:00:00 +0000

网络中断风暴是高密场景的隐形杀手。

Vhost-net / Vhost-user:

方案：务必使用 vhost 后端。它将数据平面的处理下沉到 Host 内核（vhost-net），减少了用户态（Cloud Hypervisor）和内核态之间的上下文切换。

高级方案：如果 BMS 网卡支持 SRIOV 且数量足够（通常不够高密），可以使用直通。更通用的高密方案是使用 Tap 设备 + Bridge 或者 MacVTap。

被动模式与中断合并:

在 Guest 内核中开启 NAPI，减少每个数据包的中断触发频率。

高效网络栈：

使用 vhost-net / vhost-user 加速网络 I/O
配合 DPDK 或者 SR-IOV 提升网络吞吐

Optimize: 概述

Sat, 15 Nov 2025 00:00:00 +0000

精简 Guest OS

使用 unikernel 或者精简 LInux 发行版（alpine，busybox）
移除不必要的服务和守护进程

Optimize: 概述

Sat, 15 Nov 2025 00:00:00 +0000

numa 感知：在多 cpu NUMA 架构下，合理绑定 vCPU 与内存节点，避免跨 NUMA 访问带来的延迟。

cpu pinning：将 vCPU 固定在物理 CPU 核心上，减少调度抖动

overcommit 超卖策略

在 cpu 层面适度超卖，但需要监控负载
内存层面依赖 KSM 和 ballooning，避免 OOM

和容器结合

在 microVM 内运行容器，进一步提升密度

Optimize: 概述

Sat, 15 Nov 2025 00:00:00 +0000

介绍1

如果说 MicroVM 是对传统虚拟机的“瘦身”，那么 LibOS (Library OS) 或 Unikernel 则是对操作系统架构的“重构”。

结论是：LibOS 绝对能带来质的飞跃。 在追求极致高密部署（High Density）的道路上，LibOS 是目前理论和实践上的终极方案，它能将密度在 MicroVM 的基础上再提升一个数量级。

以下是 LibOS 为什么能提升密度，以及它如何适配您的 Cloud Hypervisor 方案的详细分析：

1. 核心原理：为什么 LibOS 密度更高？

在您目前的方案中（Host -> Cloud Hypervisor -> Linux MicroVM -> App），虽然 Linux Kernel 已经裁剪得很小，但它仍然是一个通用操作系统。它依然保留了多用户支持、进程调度、复杂的网络栈、文件系统权限管理等应用可能根本不需要的功能。

LibOS 的核心逻辑是：“应用即操作系统”。

单一地址空间： LibOS 将“应用程序代码”与“必要的内核功能（如 TCP/IP 栈、内存分配）”编译成一个单一的二进制镜像。
消除上下文切换： 在 LibOS 内部，没有 User Space 和 Kernel Space 的区分。系统调用（Syscall）变成了简单的函数调用（Function Call），开销极低。
按需链接： 如果你的应用不需要读取磁盘，LibOS 就不包含文件系统驱动；不需要 USB，就不包含 USB 协议栈。

资源消耗对比

指标	传统 VM	MicroVM (裁剪 Linux)	LibOS / Unikernel
启动时间	秒级	100ms - 500ms	5ms - 50ms
内存底噪	几百 MB	20MB - 50MB	几百 KB - 5MB
镜像大小	GB 级	几十 MB	几 MB
单机并发数	几十	几百 - 上千	数千 - 上万

2. 技术结合：Cloud Hypervisor + LibOS

好消息是，您不需要更换 Cloud Hypervisor。

Cloud Hypervisor 是基于 KVM 的 VMM，而现代的 LibOS（如 Unikraft, OSv, RustyHermit）通常都支持直接运行在 KVM 上（通常通过 PVH 引导协议）。

您的架构演进路线图可以是：

当前阶段： Cloud Hypervisor + Minimal Linux Kernel (MicroVM)
下一阶段： Cloud Hypervisor + LibOS Image

在这种模式下，Cloud Hypervisor 依然负责虚拟化硬件接口（Virtio），但 Guest 内部不再运行笨重的 Linux，而是运行一个极简的 LibOS 二进制。

3. LibOS 方案的优缺点权衡

引入 LibOS 虽然能极大提升密度，但也带来了显著的工程挑战。

✅ 优势（Pros）

极致的内存密度： 很多无状态微服务的 LibOS 镜像运行起来只需 <5MB 内存。配合 KSM（内存合并），在 BMS 上部署数千个实例轻而易举。
安全性增强： 攻击面极小。LibOS 没有 Shell，没有 execve，甚至没有多进程概念，攻击者即使利用漏洞进入，也几乎无法进行横向移动或植入后门。
冷启动速度： 毫秒级启动，非常适合 Serverless / FaaS 场景。

❌ 挑战（Cons）

兼容性（最大的痛点）：
- LibOS 通常不支持 fork() 或 exec()。如果您的应用依赖多进程模型（如 Nginx 多进程模式），则无法直接运行。
- 对解释型语言（Python, Java, Node.js）的支持需要特定的运行时适配，不如编译型语言（Go, Rust, C++）方便。
调试困难： 没有 Shell，无法 SSH 进去 top 或 ls。调试往往需要依赖日志输出或远程调试接口。
构建链改变： 需要将应用和 LibOS 内核源码一起编译（或者链接），这改变了标准的 CI/CD 流程（不再是 docker build 那么简单）。

4. 推荐关注的 LibOS 项目

如果您想在 Cloud Hypervisor 上尝试 LibOS，建议关注以下几个成熟度较高的项目：

Unikraft (强力推荐):
- 特点： 欧洲系统顶会（EuroSys）孵化的项目，致力于解决 Unikernel 的兼容性问题。它提供了 POSIX 兼容层，很多标准 Linux 应用（如 Nginx, Redis, SQLite）无需修改代码即可编译运行。
- 适用性： 性能极高，社区活跃，非常适合高密场景。
Gramine (原 Graphene):
- 特点： 这是一个 Library OS，但它的思路是让未修改的 Linux 二进制文件直接运行。它更多是为了 SGX (机密计算) 设计的，但也具备 LibOS 的轻量特性。
- 适用性： 如果不想重新编译应用源码，这是一个折中方案。
Nanos (NanoVMs):
- 特点： 商业化做得较好，工具链（OPS）非常完善，甚至能直接把现有的 ELF 二进制打包成 Unikernel 镜像。
- 适用性： 易用性最好，适合快速验证。

总结建议

对于您的“高密部署”目标：

如果是通用业务（客户跑任意代码）： 继续优化 MicroVM (Linux) 是最稳妥的。因为 LibOS 的兼容性还不足以支撑任意业务。
如果是特定业务（如网关、FaaS、特定微服务）： 强烈建议引入 LibOS (特别是 Unikraft)。这将是您在单机 BMS 上突破性能瓶颈、实现成本碾压对手的关键技术。

介绍2

这是一个非常前沿且深入的技术话题。在 BMS (Bare Metal Server) + MicroVM (如 Firecracker, Cloud Hypervisor) 的架构中，引入 LibOS (Library OS，通常以 Unikernel 的形式落地) 技术，是将云计算的“密度”和“速度”推向极致的关键手段。

通常，MicroVM 已经通过精简设备模型和裁剪 Linux Kernel 实现了毫秒级启动和低内存占用，但在 Guest OS 层面，标准的 Linux（即便是裁剪过的 Alpine 或 Clear Linux）仍然存在由于通用操作系统设计带来的冗余。

LibOS 通过彻底改变 Guest OS 的架构，在 MicroVM 内部实现了更深层次的优化。以下是具体的优化逻辑和技术细节：

1. 核心理念差异：通用 OS vs. LibOS

要理解优化机制，首先需要对比两者的运行模式：

通用 Linux Guest:
- 多用户/多进程： 设计上支持多任务，即使只跑一个应用，也要启动 init 进程、systemd、日志守护进程等。
- 隔离机制： 内核空间与用户空间隔离（Ring 0 vs Ring 3），需要昂贵的上下文切换（Context Switch）。
- 通用性： 包含大量并不需要的驱动和子系统。
LibOS (Unikernel):
- 单应用/单进程： 操作系统作为一个库（Library）与应用程序编译链接在一起，形成一个单一的二进制镜像。
- 单一地址空间： 不区分内核态和用户态，所有代码运行在同一特权级（通常是 Ring 0）。
- 定制化： 仅包含应用所需的 OS 功能（如只需 TCP 栈，就不编译文件系统模块）。

2. 优化 MicroVM 启动速度

在 BMS + MicroVM 架构中，LibOS 可以将启动时间从“几百毫秒”压缩到“十几毫秒”甚至更低，主要得益于以下几点：

A. 极小的镜像体积 (Image Size)

原理： LibOS 利用静态链接和**死代码消除（Dead Code Elimination）**技术。构建时，编译器会自动剔除应用程序未调用的内核代码。
效果： 一个 HTTP Server 的 LibOS 镜像可能只有 几百 KB 到几 MB。
启动优化： 在 MicroVM 启动时，VMM（如 Firecracker）需要将 Guest Kernel 加载到内存。加载 1MB 的 LibOS 远快于加载 20MB+ 的裁剪版 Linux Kernel。这减少了 I/O 开销和内存拷贝时间。

B. 消除初始化冗余 (No Init Process)

原理： 传统 Linux 启动需要经过 BIOS/UEFI -> Bootloader -> Kernel Init -> User Space Init (systemd) -> App 的漫长链路。
LibOS 路径： VMM Entry -> Minimal Hardware Setup -> App Main Function。
效果： 跳过了复杂的硬件探测（因为 MicroVM 提供的设备极少）、跳过了文件系统挂载（如果是内存文件系统）、跳过了多用户环境的初始化。应用的主函数几乎是上电即运行。

C. 就地执行 (Execute in Place, XIP) 的潜力

由于镜像极小，LibOS 更容易利用 XIP 技术，或者通过 DAX (Direct Access) 直接映射宿主机内存，避免了传统 OS 启动时的解压和复杂的内存布局初始化过程。

3. 优化资源占用 (内存与 CPU)

在 BMS 上，资源密度直接决定了成本。LibOS 在 MicroVM 中的资源效率极高：

A. 内存占用 (Memory Footprint)

单一地址空间 (Single Address Space)：
- 传统 OS： 每个进程都有页表，内核与用户态隔离需要重复映射，存在大量内存碎片和页表开销。
- LibOS： 因为没有多进程，不需要维护复杂的页表结构，没有用户态/内核态的内存隔离墙。整个虚拟机可能只需要分配刚好够应用运行的物理内存（例如 10MB）。
去除非必要组件： 没有 sshd，nfs，udev 等后台进程占用内存。
结果： 在一台 128GB 内存的 BMS 上，如果用传统 VM 可能只能跑 1000 个实例，用 LibOS 可能可以跑 10,000 个实例。

B. CPU 效率与上下文切换

系统调用消除 (Syscall Elimination)：
- 传统 OS： 应用程序读写网络需要通过 Syscall 陷入内核（Context Switch），伴随着 CPU 缓存（L1/L2 Cache）和 TLB 的刷新，开销巨大。
- LibOS： read() 或 write() 只是普通的函数调用。应用直接操作网络栈结构，零开销。
零拷贝 (Zero Copy)： 由于应用和内核共享同一内存空间，网络数据包从网卡驱动上来后，不需要在内核缓冲区和用户缓冲区之间拷贝数据，直接处理。

C. 调度器优化

在 MicroVM 场景下，BMS 宿主机的 CPU 调度由 KVM/Host OS 负责。
如果在 Guest 内部再运行一个复杂的 Linux CFS 调度器，会出现双重调度 (Double Scheduling) 问题，浪费 CPU 周期。
LibOS 通常采用极简的协作式调度或单线程模型，将调度权完全交给宿主机（VMM），消除了 Guest 内部的调度开销。

4. 架构图解：BMS + MicroVM + LibOS

+---------------------------------------------------------------+
|                      Application Logic                        |
|   (Directly calls network stack, memory allocator, etc.)      |
+---------------------------------------------------------------+
|        LibOS Layer (Unikraft, RustyHermit, OSv, etc.)         |
|  [Net Stack] [FS Drivers] [Memory Mgmt] (Compiled as Lib)     |
+---------------------------------------------------------------+
|                 Single Binary (Unikernel)                     |
+===============================================================+
|            MicroVM Boundary (virtio-net, virtio-blk)          |
+---------------------------------------------------------------+
|         VMM (Firecracker / Cloud Hypervisor / QEMU)           |
+---------------------------------------------------------------+
|              Host Kernel (KVM) / Hypervisor                   |
+---------------------------------------------------------------+
|                   Bare Metal Server (BMS)                     |
+---------------------------------------------------------------+

5. 挑战与权衡

虽然优化效果显著，但在生产环境落地 LibOS 存在显著门槛：

调试困难： 没有 Shell，没有 SSH，无法登录进去 top 或 ls。调试依赖于外部观测（VMM 日志）或专门的调试构建。
兼容性（POSIX 支持）： 许多 LibOS 对 POSIX 标准支持不完整（尽管 Unikraft 等项目正在努力解决）。这意味着现有的应用（如 Nginx, Redis）可能需要重新编译甚至修改代码才能运行。
安全性（攻击面）： 虽然 MicroVM 提供了强隔离，但 LibOS 内部没有 Ring 3 保护。如果应用有缓冲区溢出漏洞，攻击者直接获得该 MicroVM 的最高权限（虽然仍被困在 MicroVM 内，但破坏性比普通 App 大）。

6. 总结：如何落地？

在 BMS + MicroVM 方案中，LibOS 是为了特定高并发、低延迟、高密度场景（如 Serverless 函数计算、NFV 网元）而生的终极优化。

优化启动： 靠的是“减法”——减去内核初始化、减去用户态环境、减去动态链接。
优化资源： 靠的是“融合”——融合内核与应用、融合地址空间、消除边界开销。

推荐关注的项目：

Unikraft: 目标是高性能且兼容 POSIX，目前最活跃的 LibOS 项目之一，非常适合配合 Firecracker。
RustyHermit: 基于 Rust 的 Unikernel，安全性更好。
Nanos: 试图让运行 Unikernel 像运行 Docker 一样简单。

Optimize: 概述

Sat, 15 Nov 2025 00:00:00 +0000

设备模型最小化：只保留必需的 paravirt 设备（virtio-net、virtio-blk/virtio-fs、vsock），禁用未用的 ACPI/PCI 设备与中断源，减少 emulation 成本。

关闭不必要的设备模拟，如 pci 设备，复杂 I/O

使用 virtio 驱动，减少模拟开销

Features: 介绍

Wed, 15 Oct 2025 00:00:00 +0000

在 Cloud Hypervisor (CH) 中，使用文件作为内存后端（File-backed memory）主要是为了实现高性能（Hugepages）、内存共享（vhost-user）或持久化内存（PMEM）等功能。

这个配置主要通过 --memory 参数下的 file 选项来实现。

基本语法

核心参数是 –memory:

--memory size=<内存大小>,file=<文件路径>[,shared=on|off][,hugepages=on|off]

size: 虚拟机内存大小 (例如 1G, 4G).
file: 主机（Host）上用于映射内存的文件的绝对路径。
shared: (可选) 是否将内存映射为共享（MAP_SHARED）。如果需要与 vhost-user 设备通信，必须设为 on。
hugepages: (可选) 显式声明该文件位于 Hugepages 文件系统中。

常见使用场景

使用 Hugepages (大页内存)

这是最常见的用途，推荐用于生产环境。

使用大页内存可以减少 TLB miss，显著提高虚拟机性能。

步骤：

确保主机已挂载 hugetlbfs (通常在 /dev/hugepages)。
指定文件路径

命令示例：

# 准备目录
mkdir -p /home/sky/work/test/cloudhypervisor/file-backed-memory
cd /home/sky/work/test/cloudhypervisor/file-backed-memory

sudo rm -rf /home/sky/work/test/cloudhypervisor/file-backed-memory/cloud-hypervisor.sock
sudo /home/sky/work/soft/cloudhypervisor/bin/cloud-hypervisor \
    --api-socket /home/sky/work/test/cloudhypervisor/file-backed-memory/cloud-hypervisor.sock \
    --cpus boot=2 \
    --memory size=4G,file=/dev/hugepages/ch-ram-backing \
    --kernel /home/sky/work/test/cloudhypervisor/vmlinux.bin \
    --cmdline "root=/dev/vda1 console=hvc0 rw" \
    --disk path=/home/sky/work/test/cloudhypervisor/ubuntu-cloud-image/rootfs.raw


# 完成后关闭
sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/file-backed-memory/cloud-hypervisor.sock shutdown

注意： Cloud Hypervisor 会在 /dev/hugepages/ 下创建名为 ch-ram-backing 的文件。如果该路径是 hugetlbfs 挂载点，CH 会自动识别并使用大页。

Features: 快速开始

Wed, 15 Oct 2025 00:00:00 +0000

机器配置

安装好 cloud hypervisor，测试机器为 debian13 物理机器，intel x86-64 cpu。

$ cloud-hypervisor --version
cloud-hypervisor v50.0.0

$ ch-remote --version
ch-remote v50.0.0

$ uname -a
Linux skydev3 6.12.57+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64 GNU/Linux

内核

为了极致的启动速度和测试效率，推荐使用 Cloud Hypervisor 官方提供的测试资源，或者使用 Alpine Linux 这种极简发行版。

mkdir -p ~/work/test/cloudhypervisor
cd ~/work/test/cloudhypervisor

ch官方内核

linux kernel 采用之前构建的 x86 内核（45MB），方便起见复制到本地：

cp ~/work/code/cloud-hypervisor/linux-cloud-hypervisor/arch/x86/boot/compressed/vmlinux.bin .

这个内核版本是 6.12，非常新。

记录文件地址备用:

/home/sky/work/test/cloudhypervisor/vmlinux.bin

rootfs

ubuntu cloud image

兼容性最好，但是有点大：

# 下载 Ubuntu 24.04 (Noble) 云镜像
mkdir ubuntu-cloud-image
cd ubuntu-cloud-image
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img

# Cloud Hypervisor 需要 raw 格式，且需要解压
sudo apt install -y qemu-utils
qemu-img convert -p -f qcow2 -O raw noble-server-cloudimg-amd64.img rootfs.raw

# 调整大小（可选，云镜像默认只有 2GB 左右）
qemu-img resize rootfs.raw 4G

操作之后得到的 rootfs 为：

ls -lh                       
total 2.4G
-rw-rw-r-- 1 sky sky 598M Dec 13 21:20 noble-server-cloudimg-amd64.img
-rw-r--r-- 1 sky sky 4.0G Dec 30 17:07 rootfs.raw

记录文件路径备用:

/home/sky/work/test/cloudhypervisor/ubuntu-cloud-image/rootfs.raw

Alpine Linux

TODO

启动

启动 microvm：

sudo rm -rf /home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock
sudo /home/sky/work/soft/cloudhypervisor/bin/cloud-hypervisor \
    --api-socket /home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock \
    --cpus boot=1 \
    --memory size=4G \
    --kernel /home/sky/work/test/cloudhypervisor/vmlinux.bin \
    --cmdline "root=/dev/vda1 console=hvc0 rw" \
    --disk path=/home/sky/work/test/cloudhypervisor/ubuntu-cloud-image/rootfs.raw

在另外一个终端，先 pause：

sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock pause

再执行快照命令，快照文件输出到 snapshot-4g 文件夹：

mkdir -p snapshot-4g
sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock  snapshot file:///home/sky/work/test/cloudhypervisor/snapshot-4g

完成后可以看到：

ls -lh ./snapshot-4g

文件列表为：

total 4.1G
-rw------- 1 root root 1.4K Dec 30 17:23 config.json
-rw------- 1 root root 4.0G Dec 30 17:23 memory-ranges
-rw------- 1 root root  42K Dec 30 17:23 state.json

执行关闭命令，关闭这个 microvm

sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock  resume
sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock  shutdown
sleep 1
sudo rm -rf /home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock

快照恢复

sudo /home/sky/work/soft/cloudhypervisor/bin/cloud-hypervisor \
    --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock \
    --restore source_url=file:///home/sky/work/test/cloudhypervisor/snapshot-4g

Docs: 下载

Wed, 15 Oct 2025 00:00:00 +0000

下载

github 下载地址:

https://github.com/cloud-hypervisor/cloud-hypervisor/releases/

x86

x86平台下载:

mkdir -p ~/work/soft/cloudhypervisor/bin
cd ~/work/soft/cloudhypervisor/bin
wget https://github.com/cloud-hypervisor/cloud-hypervisor/releases/download/v50.0/ch-remote
wget https://github.com/cloud-hypervisor/cloud-hypervisor/releases/download/v50.0/cloud-hypervisor
wget https://github.com/cloud-hypervisor/cloud-hypervisor/releases/download/v50.0/ch-remote-static
wget https://github.com/cloud-hypervisor/cloud-hypervisor/releases/download/v50.0/cloud-hypervisor-static

chmod +x ./ch-remote
chmod +x ./cloud-hypervisor
chmod +x ./ch-remote-static
chmod +x ./cloud-hypervisor-static

# 验证一下版本
./cloud-hypervisor --version
./cloud-hypervisor-static --version
./ch-remote --version
./ch-remote-static --version

版本输出为:

$ ./cloud-hypervisor-static --version
cloud-hypervisor v50.0.0
$ ./cloud-hypervisor --version
[1]    10062 segmentation fault  ./cloud-hypervisor --version
$ ./ch-remote --version
ch-remote v50.0.0
$ ./ch-remote-static --version
ch-remote v50.0.0

cloud-hypervisor 不能用.这是因为带 static 的二进制文件是静态编译版本，所有依赖库都已经打包在可执行文件里；不带 static 的则是动态链接版本，运行时需要系统上存在相应的共享库。如果系统缺少或版本不匹配，就可能出现 segmentation fault。

方便起见,还是直接用 static 版本比较好.

mkdir -p ~/work/soft/cloudhypervisor/bin
cd ~/work/soft/cloudhypervisor/bin
wget https://github.com/cloud-hypervisor/cloud-hypervisor/releases/download/v50.0/ch-remote-static -O ch-remote
wget https://github.com/cloud-hypervisor/cloud-hypervisor/releases/download/v50.0/cloud-hypervisor-static -O cloud-hypervisor

chmod +x ./ch-remote
chmod +x ./cloud-hypervisor

# 验证一下版本
./cloud-hypervisor --version
./ch-remote --version

arm64

类似,下载 cloud-hypervisor-static-aarch64 和 ch-remote-static-aarch64．

安装

将二进制文件所在的目录加入到 path 就可以了,这样用起来比较方便.

vi ~/.zshrc

加入内容:

# cloud hypervisor
export PATH="$PATH:$HOME/work/soft/cloudhypervisor/bin"

生效并检验:

source ~/.zshrc

ch-remote --version
cloud-hypervisor --version

升级

貌似只要直接覆盖原来版本的文件即可．

Docs: Cloud Hypervisor指南

Tue, 07 Oct 2025 00:00:00 +0000

Guide to Cloud Hypervisor in 2026: Modern VMM for cloud workloads

https://northflank.com/blog/guide-to-cloud-hypervisor

Cloud Hypervisor 是一个用 Rust 编写的开源虚拟机监控器，专为现代云工作负载而设计。它通过轻量级虚拟机提供硬件级隔离，同时支持 CPU 和内存热插拔、虚拟主机用户设备以及 Kata 容器集成。

它能在约 200 毫秒内启动虚拟机，并可在 x86-64 和 AArch64 架构的 KVM 和 Microsoft Hypervisor 上运行。该项目隶属于 Linux 基金会，通常与 Kata Containers 结合使用，用于云工作负载。

什么是 Cloud Hypervisor?

Cloud Hypervisor 是一种虚拟机监控程序(Virtual Machine Monitor,缩写为VMM），用于创建和管理用于云工作负载的轻量级虚拟机。

与注重灵活性和对传统硬件支持的传统虚拟机管理程序不同，Cloud Hypervisor 专注于在云环境中运行的现代操作系统。该项目最初是英特尔对 Rust 虚拟机管理程序 (VMM) 生态系统的贡献，并借鉴了 Firecracker 和 crosvm 的经验。

Firecracker 优先考虑无服务器工作负载的极简主义，而 QEMU 优先考虑满足所有可能用例的完整性，Cloud Hypervisor 则力求达到中间水平：提供足够的功能来处理生产工作负载，而不会造成不必要的复杂性。

Cloud Hypervisor 实现了云应用程序实际需要的现代虚拟化功能：通过 virtio 设备实现半虚拟化 I/O、CPU 和内存热插拔、通过 VFIO 实现设备直通以及与容器编排平台集成。

Cloud Hypervisor 架构

Cloud Hypervisor 基于 Rust VMM 项目构建，与 Firecracker 和 crosvm 共享虚拟化组件。

关键的架构选择包括最小的设备仿真（现代工作负载只需要 16 个设备）、通过 virtio 实现网络和存储的半虚拟化、通过 REST 进行 API 驱动的管理，以及 Rust 的内存安全机制来防止常见的漏洞。

Feature 特征	Specification 规格
语言	Rust（内存安全）
代码大小	约50,000行
启动时间	约200毫秒
架构	x86-64, AArch64 x86-64，AArch64
客户操作系统支持	Linux, Windows 10/Server 2019
虚拟机管理程序后端	KVM, Microsoft Hypervisor (MSHV)

Cloud Hypervisor 与其他虚拟机管理程序 (VMM) 相比如何？

了解 Cloud Hypervisor 相对于 Firecracker 和 QEMU 的位置，有助于明确其设计上的权衡取舍。

对比 Firecracker： Cloud Hypervisor 的启动时间约为 200 毫秒，而 Firecracker 的启动时间约为 125 毫秒。多出的 75 毫秒支持 CPU 和内存热插拔、虚拟主机用户设备以及更广泛的硬件兼容性，而 Firecracker 则刻意省略了这些功能。Firecracker 针对短暂的无服务器功能进行了优化，而 Cloud Hypervisor 则面向需要运行时灵活性的长时间运行工作负载。
对比 QEMU： Cloud Hypervisor 约有 5 万行 Rust 代码，而 QEMU 约有 200 万行 C 代码。QEMU 模拟了 40 多种设备，包括传统硬件；Cloud Hypervisor 仅实现了 16 种现代设备。Cloud Hypervisor 的启动速度明显更快（约 200 毫秒，而 QEMU 需要几秒），并且针对云工作负载提供了合理的默认设置，而 QEMU 则需要大量的配置。

Factor 因素	Cloud Hypervisor	Firecracker	QEMU
代码大小**	约 5 万行代码（Rust）	约 5 万行代码（Rust）	约 200 万行（C）
启动时间	约200毫秒	约125毫秒	几秒钟
热插拔	CPU、内存、设备	不支持	是的（复杂）
GPU 支持	有限	不支持	完整（VFIO）
Kata 集成	支持（云平台中常用选项）	Supported 支持	支持（默认）

Cloud Hypervisor 的主要特性有哪些？

Cloud Hypervisor 提供了多种功能，使其适用于生产云工作负载。

CPU 和内存热插拔

Cloud Hypervisor 无需重启即可向正在运行的虚拟机添加 CPU 和内存，从而使工作负载能够动态扩展资源。

CPU 热插拔的工作原理是：虚拟机管理程序创建新的虚拟 CPU（vCPU），并通过 ACPI 将其通告给客户机内核。然后，客户机操作系统将这些新 CPU 上线。内存热插拔则是在主机上分配额外的内存（以 128 MiB 的倍数为单位），并将其映射到客户机的地址空间。

Vhost-user 设备支持

Vhost-user 将设备模拟卸载到单独的进程中，从而提高性能和安全性。

Cloud Hypervisor 不直接在虚拟机管理程序 (VMM) 进程中处理 I/O，而是将其委托给专门的守护进程。这种架构通过在专用内核上运行设备处理程序来实现更高的 I/O 吞吐量，通过将设备逻辑与 VMM 分离来实现更好的隔离，并通过标准的虚拟主机用户协议简化设备实现。

Virtio 设备型号

Cloud Hypervisor 使用半虚拟化的 virtio 设备进行所有 I/O 操作。

这包括用于网络连接的 virtio-net、用于块存储的 virtio-blk、用于文件系统共享的 virtio-fs、用于主机-客户机通信的 virtio-vsock 以及用于持久内存的 virtio-pmem。Virtio 避免模拟真实硬件，提供客户机和主机都能理解的简洁接口，从而消除开销并实现更佳性能。

VFIO 设备直通

Cloud Hypervisor 支持使用 VFIO 将物理设备直接传递给虚拟机。

这为需要直接硬件访问的 PCIe 设备（例如网卡或加速器）提供了接近原生性能。虽然 QEMU 对 VFIO 的支持更为成熟，但 Cloud Hypervisor 能够提供大多数云用例所需的功能。

Cloud Hypervisor 如何与 Kubernetes 集成？

Kata Containers 支持多种虚拟机管理程序（包括 QEMU 和 Cloud Hypervisor）。许多云平台都使用 Cloud Hypervisor 运行 Kata，以支持 Kubernetes microVM工作负载。

当您使用 Kata 的 Cloud Hypervisor 运行时类部署容器时，Kata 会处理所有编排工作：配置虚拟机、启动最小化的客户机内核、挂载容器镜像、管理客户机和主机之间的网络连接以及处理虚拟机生命周期。从 Kubernetes 的角度来看，它就是一个普通的容器。但在底层，它是一个具有硬件隔离的完整虚拟机。

这种集成使得需要虚拟机级安全且无需构建自定义基础架构的团队能够轻松使用 Cloud Hypervisor。Northflank平台利用 Kata Containers 与 Cloud Hypervisor 的集成，为生产工作负载提供硬件级隔离。您只需使用标准的 Kubernetes YAML 进行部署，Kata 便会处理 VMM 的复杂性。

Cloud Hypervisor 有哪些局限性？

与功能齐全的虚拟机管理程序相比，Cloud Hypervisor 会做出一些有意的权衡，从而造成一些限制。

不支持传统硬件： cloud hypervisor不会模拟软盘驱动器、PS/2 键盘或 ISA 总线等传统设备。现代云工作负载不再需要这些设备，而且模拟它们会增加复杂性并扩大攻击面。
GPU 支持有限： 虽然 Cloud Hypervisor 通过 VFIO 支持一些 GPU 直通场景，但 QEMU 的实现更加成熟，可以处理更广泛的 GPU 和配置。
Windows 支持正在不断发展： cloud hypervisor支持 Windows 10 和 Windows Server 2019，但其实现成熟度不如 Linux 支持。大多数生产部署都运行 Linux 虚拟机。
快照稳定性： 快照/恢复和实时迁移功能虽然存在，但无法保证在不同版本之间保持稳定。生产环境部署应在使用前对这些功能进行全面测试。

何时应该使用cloud hypervisor？

了解cloud hypervisor的理想用例有助于您确定它是否符合您的需求。

Kubernetes 中的生产微型虚拟机： Kubernetes 中的生产微型虚拟机：当运行硬件隔离的容器工作负载时，cloud hypervisor是 Kata Containers 常用的虚拟机管理程序。
多租户云工作负载： SaaS 平台、代码执行环境、AI 沙箱和客户部署都受益于cloud hypervisor在安全性和功能性方面的平衡。
需要运行时灵活性的工作负载： 如果您的应用程序需要 CPU/内存热插拔、vhost-user 设备或比 Firecracker 提供的更广泛的硬件支持，Cloud Hypervisor 可以提供这些功能，而无需 QEMU 的复杂性。
内存安全性： Rust 的内存安全机制可以防止影响基于 C 语言的虚拟机管理程序的一系列漏洞。与 QEMU 相比，Rust 的代码库更小，这意味着潜在的攻击途径也更少。

VMM 之间的优缺点是什么？

不同的虚拟机管理程序会根据其目标用例做出不同的权衡。

VMM	设计重点	最适合
Cloud Hypervisor	功能与极简主义的平衡	需要虚拟机隔离和运行时灵活性（热插拔、虚拟主机用户）的生产级 Kubernetes 工作负载。常与 Kata Containers 配合使用，用于云工作负载。
Firecracker	极简主义和速度	无服务器函数需要尽可能快的启动速度和最小的资源占用。AWS Lambda 是临时工作负载的基础。
QEMU	最大限度的灵活性和兼容性	支持全系统仿真、GPU 工作负载、传统硬件和桌面虚拟化。灵活性最高，但攻击面也最大。

关于cloud hypervisor的常见问题

Cloud Hypervisor 和 Firecracker 的主要区别是什么？

Cloud Hypervisor 提供的功能比 Firecracker 更丰富（例如 CPU/内存热插拔、虚拟主机用户、更广泛的设备支持），同时保持了以安全为中心的设计理念。Firecracker 启动速度更快（约 125 毫秒对比约 200 毫秒），但为了保持简洁，它刻意省略了一些功能。Cloud Hypervisor 的目标应用是长时间运行的云工作负载，而 Firecracker 的目标应用是短暂的无服务器功能。

Cloud Hypervisor 比 QEMU 更安全吗？

cloud hypervisor的代码库规模要小得多（Rust 代码约 5 万行，而 C 代码约 200 万行），并且使用内存安全语言编写，从而降低了潜在的安全漏洞。然而，QEMU 已经过数十年的实战检验，并接受了广泛的安全审计。对于现代云工作负载而言，cloud hypervisor较小的攻击面通常更具优势。

cloud hypervisor是否支持 GPU 直通？

Cloud Hypervisor 通过 VFIO 支持部分 GPU 直通场景，但其实现不如 QEMU 成熟。对于生产环境的 GPU 工作负载，请务必使用 Cloud Hypervisor 对您的特定 GPU 和驱动程序进行全面测试，或者考虑使用 QEMU 以获得更可靠的 GPU 支持。

cloud hypervisor可以运行 Windows 吗？

是的，Cloud Hypervisor 支持 Windows 10 和 Windows Server 2019。但是，Linux 虚拟机获得了更多的开发关注，并且在生产环境中的部署也更为广泛。在生产环境部署之前，请务必对 Windows 工作负载进行全面测试。

Cloud Hypervisor 如何与 Kata Containers 集成？

Kata Containers 支持多种虚拟机管理程序 (VMM)，包括 QEMU 和 Cloud Hypervisor。某些平台默认将 Kata 配置为使用 Cloud Hypervisor。在 Kubernetes 中指定 kata-clh 运行时类后，Kata 会自动使用 Cloud Hypervisor 创建和管理虚拟机。此集成处理了所有运维复杂性，使用户可以通过标准的 Kubernetes API 访问 Cloud Hypervisor。

我可以在 Kubernetes 之外使用 Cloud Hypervisor 吗？

是的，Cloud Hypervisor 可以独立运行。但是，大多数生产部署都通过 Kata Containers 将其与 Kubernetes 集成。直接运行 Cloud Hypervisor 需要手动进行虚拟机生命周期管理、网络配置和编排。

Optimize: 高密部署

Mon, 01 Dec 2025 00:00:00 +0000

尝试问了一下 gemini：

https://gemini.google.com/app/f36b99b24d1c84e0

问 copilot , gpt-5:

https://copilot.microsoft.com/chats/gcwFG4V9oasJEtHXg9nFE

Practices: 在腾讯TKE serverless的落地实践

Sun, 23 Nov 2025 00:00:00 +0000

公开资料

咨询gemini

问：请帮我在网络上深度搜索一下 TKE Serverless 在 microvm / cloud hypervisor 上的实践

答复：

针对 TKE Serverless（腾讯云弹性容器服务） 在 MicroVM / Cloud Hypervisor 上的最新实践，我进行了深度的网络搜索和技术追踪。

目前的现状是：腾讯云已经将早期的 “Cube” 引擎完全融入到 TKE Serverless 的底层架构中。在 2024 年至 2025 年初，其实践重点已从“如何实现虚拟化”转向了**“高性能 AI 算力、机密计算、以及超大规模调度优化”**。

以下是为您整理的深度技术实践总结：

1. 核心架构：Kata Containers + Cloud Hypervisor 的“工业化”

在 2024 年的实践中，TKE Serverless 已经标准化了基于 Rust 编写的 Cloud Hypervisor (CH) 作为默认 VMM（Virtual Machine Monitor）。

全栈 Rust 化：腾讯云不仅使用 Cloud Hypervisor，还深度参与了 rust-vmm 生态。通过 Rust 的内存安全特性，TKE Serverless 在高并发拉起容器时，避免了 QEMU 常见的内存溢出和安全漏洞。
极简 VMM：相比 QEMU，TKE 实践中的 CH 剥离了所有不必要的传统设备（如软盘、老旧总线），仅保留 Virtio 设备。这使得 MicroVM 的冷启动时间压缩到了 100ms 级别，单机 Pod 密度提升了 3 倍以上。

2. 2024-2025 最新进展：Serverless GPU 与 AI 实践

这是目前腾讯云最领先的领域。随着大模型（LLM）推理需求的激增，TKE Serverless 在 MicroVM 上实现了 GPU 的快速交付。

vGPU 与直通技术（Pass-through）：在 2024 年的技术分享中，腾讯云披露了如何在 Cloud Hypervisor 中优化 PCI 直通协议，使得 Serverless 容器能够秒级挂载 NVIDIA GPU（如 L40s、H800）。
动态资源调整 (Hot-plug)：AI 推理任务往往有明显的波峰波谷。腾讯云利用 CH 的特性，实现了在不重启 MicroVM 的情况下，动态增加或减少 GPU 显存和算力配额。

3. 机密计算 (Confidential Computing) 的深度融合

这是 2023 年底到 2024 年腾讯云重点宣传的技术突破。

机密容器 (TDX/SEV-SNP)：在最近的全球技术峰会上，腾讯云展示了基于 Intel TDX 技术的 TKE Serverless 实例。通过 Cloud Hypervisor 的硬件抽象层，TKE 能够为用户提供一个完全加密的运行环境（TEE）。
实践场景：主要面向金融、政企客户。即使是腾讯云的系统底层（Host OS），也无法读取 MicroVM 内部的内存数据。这标志着 TKE Serverless 迈向了“零信任虚拟化”。

4. 存储与网络的高性能优化 (2024 最新补丁)

搜索发现，腾讯云团队在 2024 年持续向 Cloud Hypervisor 社区贡献代码，重点解决 I/O 瓶颈：

Vhost-user-blk 增强：为了解决 Serverless 容器在处理数据库等高 IOPS 任务时的延迟，腾讯云优化了 Cloud Hypervisor 的 vhost-user 实现，将存储 IOPS 损耗降低到了物理机的 5% 以内。
Net-accelerator：通过私有的网络加速组件，TKE Serverless 在 MicroVM 环境下实现了单 Pod 20Gbps 的网络吞吐量。

5. 关键技术动态追踪 (2024-2025)

时间	渠道	核心实践内容
2024.Q3	KubeCon China	腾讯云分享《在 TKE Serverless 中构建高性能机密计算节点》，强调 CH 在隔离性上的贡献。
2024.Q4	Cloud Hypervisor 社区	腾讯云工程师提交了关于 Virtio-mem 的多项优化，旨在提升 Serverless 容器内存回收的效率。
2025.Q1	腾讯云官网更新	推出“原生节点” (Native Node) 2.0，底层全面切换至优化后的 MicroVM 架构，支持即时弹性。

深度搜索结论：为什么你感觉 2023 年后的资料少了？

通过对技术博客和 GitHub Commits 的分析，我发现两个原因：

品牌整合：腾讯云内部已不再强调 “Cube” 作为一个独立产品，而是将其作为 TKE Serverless 的“底层引擎”或“虚拟化运行时刻”。因此，最新的搜索关键词应改为 “TKE Serverless 机密容器” 或 “TKE 弹性节点虚拟化”。
进入“深水区”：2023 年之前是在解决“能不能跑”的问题，2024 年之后腾讯云的实践主要集中在 Cloud Hypervisor 社区的底层代码贡献（例如对 Rust 异步 I/O 的改写）。这些内容往往存在于 GitHub 的 Pull Request 或 Linux 邮件列表中，而不是通俗的技术博客。

Optimize: 精简 Guest Kernel

Sun, 23 Nov 2025 00:00:00 +0000

精简 Guest Kernel:

方案：定制 Linux Kernel。移除所有不需要的驱动（USB, GPU, Sound, 传统的 PCI 等）。只保留 virtio 相关的驱动（virtio-net, virtio-blk, virtio-fs, virtio-console）。

效果：减小 Kernel 体积（建议压缩后小于 5MB），减少启动时的内存申请，加快启动速度。

Optimize: aistudio.google

Sat, 15 Nov 2025 00:00:00 +0000

https://aistudio.google.com/prompts/1xw2bDNLkdRaZq5u8OqOhAuIZm5Nwox1j

输入：

我在设计 bms 机器上启动 cloud hypervisor 作为 microvm 运行 ai agent 的方案。现在我想实现高密部署，其中有一个优化策略是降低每个 microvm 实例的内存使用。我想深入了解一下 Virtio-fs + DAX (Direct Access) 在这方面的作用，另外详细介绍一下这个技术的原理。

这是一个非常专业且切中要害的问题。在基于 BMS（裸金属服务器）+ Cloud Hypervisor + MicroVM 的架构下，Virtio-fs + DAX 是实现高密度部署（High Density）、尤其是 AI Agent 这种依赖大文件（模型、Python 库）场景的核心优化技术。

简单来说，它的核心价值在于消除了 Host 和 Guest 之间的“双重缓存”（Double Caching），实现了内存的真正共享。

以下是关于 Virtio-fs + DAX 的深入原理解析及其在 AI Agent 场景下的作用。

1. 核心痛点：传统的“双重缓存”问题

在没有 DAX 的传统虚拟化文件系统（如 virtio-9p 或未开启 DAX 的 virtio-fs）中，当 MicroVM 需要读取一个文件（例如 500MB 的 PyTorch 库或 2GB 的 LLM 模型）时，数据流向如下：

Host Page Cache: 宿主机内核从磁盘读取文件，缓存在宿主机的 Page Cache 中。
Copy Operation: 数据通过 virtio 通道从宿主机内存拷贝到 Guest 的内存中。
Guest Page Cache: Guest 内核将这份数据再次缓存在自己的 Page Cache 中。

后果：

内存浪费： 同一份数据在物理内存中存在了两份（一份在 Host，一份在 Guest）。
无法复用： 如果你启动了 100 个 MicroVM，每个 VM 都要加载 PyTorch，那么内存中就会有 100 + 1 份 PyTorch 的拷贝。这是高密部署的噩梦。

2. Virtio-fs + DAX 的解决方案：共享 Page Cache

DAX (Direct Access) 技术允许 Guest VM 的文件系统绕过自己的 Page Cache，直接映射宿主机的文件缓存。

原理机制（Technical Deep Dive）

Virtio-fs + DAX 的工作流程利用了 PCI BAR (Base Address Register) 和内存映射（mmap）技术。

PCI BAR 窗口（DAX Window）：
- Cloud Hypervisor 在启动时，会为 Virtio-fs 设备分配一块巨大的内存区域（例如 4GB 或更大），这块区域在 Guest 看来是 PCI 设备的一块内存空间（PCI BAR）。
- 在 Host 侧，这块区域实际上并没有立即分配物理 RAM，而是作为一个虚拟地址窗口。
文件映射（The Mapping）：
- 当 Guest 应用（如 AI Agent 的 Python 进程）发起 read 请求读取 pytorch.so 时。
- Guest 内核检测到该文件系统支持 DAX，它不会发起传统的 I/O 请求将数据复制进来。
- 相反，Guest 内核发送一个 FUSE 请求给 Host 端的 virtiofsd（后端守护进程），请求建立映射（FUSE_SETUPMAPPING）。
建立页表关联（The Magic）：
- Host 端的 virtiofsd 收到请求后，会把宿主机上该文件对应的 Page Cache（Host 物理内存）mmap 到 Cloud Hypervisor 的 DAX Window 中。
- KVM 更新 EPT（Extended Page Tables，扩展页表）。
- 结果： Guest 的物理地址空间（GPA）直接指向了 Host 的物理地址空间（HPA）中存放文件内容的页面。
直接访问：
- Guest 应用程序读取内存时，实际上是直接读取了 Host 的 Page Cache。

3. 图解对比

传统模式 (Without DAX):

Host Disk  ->  Host RAM (Page Cache)  ->  (Copy)  ->  Guest RAM (Page Cache)  ->  Guest App

100 个 VM = 100 份 Guest Cache + 1 份 Host Cache

Virtio-fs + DAX 模式:

Host Disk  ->  Host RAM (Page Cache)  <-- (Map/Ptr) -- Guest App (直接读取)

100 个 VM = 0 份 Guest Cache + 1 份 Host Cache

4. 在 AI Agent 高密部署中的具体作用

对于 AI Agent 场景，Virtio-fs + DAX 的收益是巨大的，主要体现在以下三个方面：

A. 共享 Python 环境与依赖库 (Huge Win)

AI Agent 通常运行在 Python 环境中，依赖 torch, numpy, tensorflow 等巨型库。

场景： torch 库解压后可能占用 500MB~1GB 空间。
无 DAX： 启动 50 个 Agent，仅加载 torch 就需要消耗 50GB 内存。
有 DAX： Host 加载一次 torch 占用 1GB 内存。50 个 Agent 全部通过 DAX 映射读取这同一份物理内存。内存开销接近于 0 的增长。

B. 共享 AI 模型权重 (Massive Win)

如果你的 Agent 是同质化的（例如都调用同一个本地 Embedding 模型或小型 LLM）。

场景： 模型文件大小 2GB。
有 DAX： 所有 Agent 共享这 2GB 的物理内存。你可以轻松在 64GB 内存的服务器上跑几十个加载了 2GB 模型的 MicroVM，只要 CPU 撑得住。

C. 极速启动 (Fast Boot)

由于不需要将数据从 Host 拷贝到 Guest 内存，也不需要 Guest 内核进行磁盘解压或加载操作，应用启动速度（Cold Start）会显著加快。MicroVM 启动时，并没有真正加载文件，只是建立了内存映射指针，通过“缺页异常”（Page Fault）按需加载，速度极快。

5. Cloud Hypervisor 配置指南

在 Cloud Hypervisor 中启用 Virtio-fs DAX 需要配合 virtiofsd 使用。

1. 启动 virtiofsd (Host 端): 你需要先运行 virtio-fs 的后端守护进程。

# --cache=auto 或 always 配合 DAX 效果最好
# --socket-path 指定通信 socket
# --shared-dir 指定宿主机共享目录（存放 rootfs, models, python envs）
./virtiofsd --socket-path=/tmp/vhost-user.sock --shared-dir=/path/to/shared/agents --cache=auto

2. 配置 Cloud Hypervisor (JSON 或 CLI): 在启动 Cloud Hypervisor 时，需要指定 DAX 缓存窗口的大小。这个大小限制了 Guest 可以同时映射多少文件内容，建议设置得大一些（覆盖你的模型+库的大小）。

{
  "fs": [
    {
      "tag": "myfs",
      "socket": "/tmp/vhost-user.sock",
      "num_request_queues": 1,
      "queue_size": 1024,
      "cache_size": "4G"  <-- 这里开启 DAX，设置 DAX Window 大小为 4GB
    }
  ],
  "kernel": "...",
  "cpus": "...",
  "memory": "..."
}

或者 CLI 参数：

./cloud-hypervisor \
    ... \
    --fs tag=myfs,socket=/tmp/vhost-user.sock,num_request_queues=1,queue_size=1024,cache_size=4G

3. Guest 内部挂载: Guest 启动后，挂载文件系统需要指定 dax 选项：

mount -t virtiofs -o dax myfs /mnt/shared

6. 总结与建议

Virtio-fs + DAX 是 AI Agent MicroVM 高密部署的基石。

原理： 利用 Host Page Cache 作为唯一的真实数据源，Guest 通过 PCI BAR 直接映射访问，消除数据拷贝。
收益： 将 O(N) 的内存复杂度降低为 O(1)（针对只读数据）。
策略建议：
1. 构建统一的 Base Image/Rootfs： 将 Python 环境、CUDA 库、常用模型文件放在 Host 的共享目录中。
2. 只读挂载： 尽量以只读方式挂载代码和模型目录，这样能最大化利用共享页缓存。
3. 计算 DAX Window： cache_size 不要太小，至少要大于“常用热点文件总和”（如 OS 基础库 + Python 解释器 + PyTorch + 模型权重）。

这一方案能让你在有限的物理内存上，将 MicroVM 的密度提高 3-10 倍（取决于 AI 负载中静态资源的占比）。

Optimize: alpine

Sat, 15 Nov 2025 00:00:00 +0000

背景

由于我们为 microvm 场景定制的内核是 25.9MB 的全内置 (Monolithic) 内核，因此 Rootfs 制作将遵循一个核心原则：彻底剔除所有内核模块和硬件固件。

Alpine 使用 musl libc 和 BusyBox，是目前启动最快的 Linux。

定制脚本

mkdir -p /home/sky/work/code/cloud-hypervisor/rootfs/alphine
cd /home/sky/work/code/cloud-hypervisor/rootfs/alphine

vi build_agent_rootfs_erofs.sh

内容为:

#!/bin/bash
set -e

# --- 配置参数 ---
ROOTFS_NAME="alpine_rootfs.erofs"
WORKING_DIR="./mnt_alpine"
ALPINE_VERSION="3.20.3"
ALPINE_TAR="alpine-minirootfs-${ALPINE_VERSION}-x86_64.tar.gz"
ALPINE_URL="https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/${ALPINE_TAR}"

echo "🚀 开始自动化构建 EROFS + DAX 专用 Alpine Rootfs..."

# 1. 依赖检查
if ! command -v mkfs.erofs &> /dev/null; then
    echo "❌ 错误: 未安装 erofs-utils。请运行: sudo apt install erofs-utils"
    exit 1
fi

# 2. 下载原始 Rootfs 包
if [ ! -f "$ALPINE_TAR" ]; then
    echo "📥 下载 Alpine 原始包..."
    curl -L -O "$ALPINE_URL"
fi

# 3. 准备工作目录
echo "📂 准备构建目录..."
sudo rm -rf "$WORKING_DIR"
mkdir -p "$WORKING_DIR"
sudo tar -xzkf "$ALPINE_TAR" -C "$WORKING_DIR"

# 4. 进入 Chroot 进行内部定制
echo "🛠️ 开始内部定制..."
sudo cp /etc/resolv.conf "$WORKING_DIR/etc/resolv.conf"

sudo chroot "$WORKING_DIR" /bin/sh <<EOF
# 设置密码
echo "root:root" | chpasswd

# 1. 基础环境补全
mkdir -p /etc/init.d
mkdir -p /run/openrc
touch /run/openrc/softlevel

# 2. 优化终端：仅保留 hvc0
sed -i '/tty[0-9]/d' /etc/inittab
if ! grep -q "hvc0" /etc/inittab; then
    echo "hvc0::respawn:/sbin/getty -L hvc0 115200 vt100" >> /etc/inittab
fi

# 3. 换源并安装 OpenRC 
echo "https://mirrors.aliyun.com/alpine/v3.20/main" > /etc/apk/repositories
echo "https://mirrors.aliyun.com/alpine/v3.20/community" >> /etc/apk/repositories
apk add --no-cache openrc

# 4. 配置启动项
rc-update add devfs boot
rc-update add local boot
EOF

# 5. 注入 OverlayFS 极速启动逻辑 (针对 DAX 和写层优化)
echo "⚡ 注入 OverlayFS 启动逻辑..."
sudo tee "$WORKING_DIR/etc/init.d/rcS" <<EOF
#!/bin/sh
# 基础虚拟文件系统挂载
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devtmpfs none /dev

# 准备写层 (假设 /dev/vda 是通过 --disk 传入的 Ext4 镜像)
mkdir -p /mnt/write_layer
if mount -t ext4 -o noatime /dev/vda /mnt/write_layer; then
    echo "✅ Writable layer (/dev/vda) detected."
    # 准备 OverlayFS 结构
    mkdir -p /mnt/write_layer/upper /mnt/write_layer/work
    # 将 /var 叠加到写层，使得日志和配置可持久化
    mount -t overlay overlay -o lowerdir=/var,upperdir=/mnt/write_layer/upper,workdir=/mnt/write_layer/work /var
else
    echo "⚠️ Warning: No writable disk detected, using tmpfs for /var."
    mount -t tmpfs tmpfs /var
fi

# 其他临时目录使用内存
mount -t tmpfs tmpfs /tmp
mount -t tmpfs tmpfs /run

echo "------------------------------------------------"
echo "  Welcome to Agent MicroVM (EROFS + DAX)       "
echo "  Status: Rootfs is Read-Only | /var is Writable"
echo "------------------------------------------------"

# 执行正常的 init 流程
exec /sbin/init
EOF

sudo chmod +x "$WORKING_DIR/etc/init.d/rcS"

# 6. 极致清理
echo "🧹 执行最后瘦身清理..."
sudo rm -rf "$WORKING_DIR/lib/modules"/*
sudo rm -rf "$WORKING_DIR/lib/firmware"/*
sudo rm -rf "$WORKING_DIR/var/cache/apk"/*
sudo rm -f "$WORKING_DIR/etc/resolv.conf"

# 7. 构建 EROFS 镜像 (核心步骤)
# -d4: 4KB对齐，DAX 必需
# --fsid=rootfs: 方便内核识别
echo "💎 构建 EROFS 镜像..."
rm -f "$ROOTFS_NAME"
sudo mkfs.erofs -d4 "$ROOTFS_NAME" "$WORKING_DIR"

# 8. 完成
sudo rm -rf "$WORKING_DIR"
echo "✅ 构建完成！镜像文件: ${ROOTFS_NAME}"
ls -lh "$ROOTFS_NAME"

增加执行权限：

chmod +x build_agent_rootfs_erofs.sh

执行：

./build_agent_rootfs_erofs.sh

执行完成后，rootfs 文件会生成在当前目录下，大小为约 10MB。

-rw-r--r-- 1 root root 8.9M Feb 28 09:57 alpine_rootfs.erofs

测试

准备工作

准备工作目录和文件：

mkdir -p /home/sky/work/test/cloudhypervisor/agent
cd /home/sky/work/test/cloudhypervisor/agent
cp /home/sky/work/code/cloud-hypervisor/linux/vmlinux .
cp /home/sky/work/code/cloud-hypervisor/rootfs/alphine/alpine_rootfs.erofs .

准备可写层文件：

# 1. 创建一个 64MB 的原始镜像 (大小可根据日志量调整)
# 使用 seek 可以创建一个空洞文件，逻辑大小 64M，实际初始占用 0
dd if=/dev/zero of=write_layer_template.img bs=1M count=0 seek=64

# 2. 格式化为极致精简的 Ext4
# -O ^has_journal: 关键优化！禁用日志。
#   在只读根镜像+独立写层的架构下，日志会产生双倍 IO 开销，禁用它能大幅提升小文件写入速度。
# -O ^huge_file,^flex_bg: 移除针对大文件系统的冗余特性。
# -m 0: 将保留给 root 用户的 5% 空间设为 0，充分利用 64MB。
mkfs.ext4 -O ^has_journal,^huge_file,^flex_bg -m 0 write_layer_template.img

启动 microvm

mkdir microvm-1
cp write_layer_template.img microvm-1/write_layer.img

sudo /usr/local/bin/cloud-hypervisor \
    --kernel ./vmlinux \
    --memory size=1024M \
    --pmem file=./alpine_rootfs.erofs \
    --disk path=./microvm-1/write_layer.img \
    --cpus boot=1 \
    --console tty \
    --cmdline "console=hvc0 root=/dev/pmem0 ro rootfstype=erofs init=/etc/init.d/rcS"

然后可以用帐号 root/root 登录（帐号密码在前面的脚本中有设置，可修改）。关机时注意 alphine Linux 默认不带 shutdown 命令，关机要用 poweroff 命令，重启可以用普通的 reboot 命令。

如果想增加 shutdown 命令，可以：

apk update
apk add sysvinit
# 之后就能用 shutdown
shutdown -h now
shutdown -r now

先用 poweroff ，不额外安装了。

进程分析

这是启动单个 microvm 的进程信息：

ps -ef | grep cloud
root     1351503 1349610  0 14:50 pts/0    00:00:00 sudo /usr/local/bin/cloud-hypervisor --kernel ./vmlinux --memory size=1024M --pmem file=./alpine_rootfs.erofs --disk path=./microvm-1/write_layer.img --cpus boot=1 --console tty --cmdline console=hvc0 root=/dev/pmem0 ro rootfstype=erofs init=/etc/init.d/rcS
root     1351505 1351503  0 14:50 pts/1    00:00:00 sudo /usr/local/bin/cloud-hypervisor --kernel ./vmlinux --memory size=1024M --pmem file=./alpine_rootfs.erofs --disk path=./microvm-1/write_layer.img --cpus boot=1 --console tty --cmdline console=hvc0 root=/dev/pmem0 ro rootfstype=erofs init=/etc/init.d/rcS
root     1351506 1351505  1 14:50 pts/1    00:00:00 /usr/local/bin/cloud-hypervisor --kernel ./vmlinux --memory size=1024M --pmem file=./alpine_rootfs.erofs --disk path=./microvm-1/write_layer.img --cpus boot=1 --console tty --cmdline console=hvc0 root=/dev/pmem0 ro rootfstype=erofs init=/etc/init.d/rcS
root     1351509 1351506  0 14:50 pts/1    00:00:00 /usr/local/bin/cloud-hypervisor --kernel ./vmlinux --memory size=1024M --pmem file=./alpine_rootfs.erofs --disk path=./microvm-1/write_layer.img --cpus boot=1 --console tty --cmdline console=hvc0 root=/dev/pmem0 ro rootfstype=erofs init=/etc/init.d/rcS

这是一个多层级进程结构。虽然只运行了一个启动命令，但在 Linux 的 ps 输出中出现了 4 个相关的条目。这是由 sudo 的工作机制、Cloud Hypervisor 的内部架构以及 Linux 线程的处理方式共同决定的。

按照 PID (进程 ID) 和 PPID (父进程 ID) 的链路来拆解，进程链路树状:

PID	PPID	用户	角色	状态描述
1351503	1349610	root	Sudo Shell	`pts/0` 输入命令后产生的第一个 `sudo` 进程。
1351505	1351503	root	Sudo Runner	`sudo` 内部为了安全执行目标程序而分叉（fork）出的运行环境。
1351506	1351505	root	CH Main (核心)	这是真正的 MicroVM 主进程。它负责内存管理、设备初始化。
1351509	1351506	root	CH Worker	这是一个子线程（被 `ps` 显示为进程），通常负责异步 I/O 或 API 处理。

由于存在多余的 sudo 进程，因此大规模部署时不建议用 sudo。考虑到直接用 root 也不够安全，因此最好的解决方式是给运行 cloud hypervisor 的非 root 帐号和 cloud-hypervisor 二进制文件赋予需要的权限。

以 sky 帐号为例，具体需要的操作有：

# 赋予 ch 网络管理、原始 IO 和内存锁定权限
sudo setcap 'cap_net_admin,cap_sys_rawio,cap_ipc_lock+ep' /usr/local/bin/cloud-hypervisor

# 设置设备访问权限
# Cloud Hypervisor 需要访问 /dev/kvm（虚拟化加速）和 /dev/vhost-vsock 等设备
# 将帐号加入 kvm 组
sudo usermod -aG kvm sky
# 为了确保每次开机 /dev/kvm 等设备都能被 sky 访问，创建一条规则
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | sudo tee /etc/udev/rules.d/99-kvm.rules
echo 'KERNEL=="vhost-vsock", GROUP="kvm", MODE="0660"' | sudo tee -a /etc/udev/rules.d/99-kvm.rules
sudo udevadm control --reload-rules && sudo udevadm trigger

# 确保你的 vmlinux、alpine_rootfs.erofs 以及 microvm-1/ 目录下的所有文件，属主都是 sky
# sudo chown -R sky:sky /home/sky/work/test/cloudhypervisor/agent

去掉 sudo，用 sky 帐号启动：

/usr/local/bin/cloud-hypervisor \
    --kernel ./vmlinux \
    --memory size=1024M \
    --pmem file=./alpine_rootfs.erofs \
    --disk path=./microvm-1/write_layer.img \
    --cpus boot=1 \
    --console tty \
    --cmdline "console=hvc0 root=/dev/pmem0 ro rootfstype=erofs init=/etc/init.d/rcS quiet"

ps的信息如下：

ps -ef | grep cloud

sky      1352498 1351990  0 15:10 pts/0    00:00:00 /usr/local/bin/cloud-hypervisor --kernel ./vmlinux --memory size=1024M --pmem file=./alpine_rootfs.erofs --disk path=./microvm-1/write_layer.img --cpus boot=1 --console tty --cmdline console=hvc0 root=/dev/pmem0 ro rootfstype=erofs init=/etc/init.d/rcS

sky      1352501 1352498  0 15:10 pts/0    00:00:00 /usr/local/bin/cloud-hypervisor --kernel ./vmlinux --memory size=1024M --pmem file=./alpine_rootfs.erofs --disk path=./microvm-1/write_layer.img --cpus boot=1 --console tty --cmdline console=hvc0 root=/dev/pmem0 ro rootfstype=erofs init=/etc/init.d/rcS

去掉 sudo 后，现在的 ps 输出变得非常清爽且符合预期。中间那两层中转进程彻底消失了，直接看到的是 Cloud Hypervisor 本身。

PID	PPID	用户	角色	状态描述
1352498	1351990	sky	主进程 (Parent)	这是你手动启动的那个二进制文件，负责资源协调。
1352501	1352498	sky	工作线程 (Child/Thread)	它是主进程派生出的一个轻量级进程（LWP），通常处理 I/O 或信号。

内存分析

sudo pmap -x 1351506
1351506:   /usr/local/bin/cloud-hypervisor --kernel ./vmlinux --memory size=1024M --pmem file=./alpine_rootfs.erofs --disk path=./microvm-1/write_layer.img --cpus boot=1 --console tty --cmdline console=hvc0 root=/dev/pmem0 ro rootfstype=erofs init=/etc/init.d/rcS
Address           Kbytes     RSS   Dirty Mode  Mapping
000055556aece000       4       0       0 -----   [ anon ]
000055556aecf000       8       8       8 rw---   [ anon ]
00007f8d66ff4000       8       0       0 -----   [ anon ]
00007f8d66ff6000    2052       4       4 rw---   [ anon ]
00007f8d671f7000       8       0       0 -----   [ anon ]
00007f8d671f9000    2052      20      20 rw---   [ anon ]
00007f8d673fa000       8       0       0 -----   [ anon ]
00007f8d673fc000    2052       4       4 rw---   [ anon ]
00007f8d675fd000       8       0       0 -----   [ anon ]
00007f8d675ff000    2052    2048    2048 rw---   [ anon ]
00007f8d67800000   10240    2752       0 rw-s- alpine_rootfs.erofs
00007f8d683fd000       8       0       0 -----   [ anon ]
00007f8d683ff000    2052    2048    2048 rw---   [ anon ]
00007f8d68600000 1048576   69632   69632 rw---   [ anon ]
00007f8da87fa000       8       0       0 -----   [ anon ]
00007f8da87fc000    2052       4       4 rw---   [ anon ]
00007f8da89fd000       8       0       0 -----   [ anon ]
00007f8da89ff000    2052    2048    2048 rw---   [ anon ]
00007f8da8c00000     368     368       0 r---- cloud-hypervisor
00007f8da8c5c000    3276    2940       0 r-x-- cloud-hypervisor
00007f8da8f8f000     576     384       0 r---- cloud-hypervisor
00007f8da901f000     600     260     260 rw--- cloud-hypervisor
00007f8da90b5000       8       8       8 rw---   [ anon ]
00007f8da910b000       4       4       4 rw---   [ anon ]
00007f8da910c000       4       0       0 -----   [ anon ]
00007f8da910d000       8       0       0 rw---   [ anon ]
00007f8da910f000       4       4       4 rw---   [ anon ]
00007f8da9110000       4       0       0 -----   [ anon ]
00007f8da9111000       8       0       0 rw---   [ anon ]
00007f8da9113000     124      56      56 rw---   [ anon ]
00007f8da9132000       8       8       8 rw-s-   [ anon ]
00007f8da9134000       8       8       4 rw-s-   [ anon ]
00007f8da9136000       4       0       0 -----   [ anon ]
00007f8da9137000       8       0       0 rw---   [ anon ]
00007f8da9139000      20      16      16 rw---   [ anon ]
00007f8da913e000       4       0       0 -----   [ anon ]
00007f8da913f000       8       0       0 rw---   [ anon ]
00007f8da9141000       4       0       0 -----   [ anon ]
00007f8da9142000       8       0       0 rw---   [ anon ]
00007f8da9144000      60      60      56 rw---   [ anon ]
00007f8da9153000      12       8       8 rw-s-   [ anon ]
00007f8da9156000       4       4       4 rw-s- zero (deleted)
00007f8da9157000      84      80      80 rw---   [ anon ]
00007f8da916c000       4       0       0 -----   [ anon ]
00007f8da916d000       8       0       0 rw---   [ anon ]
00007f8da916f000       4       4       4 rw---   [ anon ]
00007f8da9170000       4       0       0 -----   [ anon ]
00007f8da9171000       8       0       0 rw---   [ anon ]
00007f8da9173000      72      72      72 rw---   [ anon ]
00007f8da9185000       4       0       0 -----   [ anon ]
00007f8da9186000       8       0       0 rw---   [ anon ]
00007f8da9188000       4       4       4 rw---   [ anon ]
00007f8da9189000      16       0       0 r----   [ anon ]
00007f8da918d000       8       4       0 r-x--   [ anon ]
00007ffe2b7bf000     132      60      60 rw---   [ stack ]
---------------- ------- ------- ------- 
total kB         1078736   82920   76464

启动脚本优化

/usr/local/bin/cloud-hypervisor \
    --kernel ./vmlinux \
    --memory size=1024M,shared=on \
    --pmem file=./alpine_rootfs.erofs \
    --disk path=./microvm-1/write_layer.img \
    --cpus boot=1 \
    --console tty \
    --cmdline "console=hvc0 root=/dev/pmem0 ro rootfstype=erofs init=/etc/init.d/rcS quiet mitigations=off lpj=9676800 raid=noautodetect"

参考资料

和 gemini 的交互过程：

https://gemini.google.com/app/604671631189df20

Docs: 虚拟CPU配置

Sat, 15 Nov 2025 00:00:00 +0000

https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/docs/cpu.md

在创建虚拟 CPU 方面，Cloud Hypervisor 提供了多种选项。本文档旨在解释 Cloud Hypervisor 的功能以及如何使用它来满足不同用例的需求。

Options 选项

CpusConfig 或从 CLI 的角度称为 --cpus 是设置 Cloud Hypervisor vCPU 选项的方式。

struct CpusConfig {
    boot_vcpus: u8,
    max_vcpus: u8,
    topology: Option<CpuTopology>,
    kvm_hyperv: bool,
    max_phys_bits: u8,
    affinity: Option<Vec<CpuAffinity>>,
    features: CpuFeatures,
}

--cpus boot=<boot_vcpus>,max=<max_vcpus>,topology=<threads_per_core>:<cores_per_die>:<dies_per_package>:<packages>,kvm_hyperv=on|off,max_phys_bits=<maximum_number_of_physical_bits>,affinity=<list_of_vcpus_with_their_associated_cpuset>,features=<list_of_features_to_enable>

boot

启动时存在的 vCPU 数量。

此选项允许定义虚拟机启动时存在的特定 vCPU 数量。在使用 –cpus 参数时，此选项是必需的。如果未指定 –cpus ，此选项将采用默认值 1，以单个 vCPU 启动虚拟机。

值是一个 8 位的无符号整数。

--cpus boot=2

max

最大 vCPU 数量。

此选项定义可分配给虚拟机的最大 vCPU 数量。特别是，当想用 CPU 热插拔时使用此选项，因为它可以提供有关在虚拟机运行期间可能需要多少 vCPU 的指示。例如，如果使用 2 个 vCPU 启动虚拟机，并且最大限制为 6 个 vCPU，这意味着最多可以在运行时通过调整虚拟机大小添加 4 个 vCPU。

该值必须大于或等于启动 vCPU 的数量。该值是一个 8 位的无符号整数。

默认情况下，此选项取 boot 的值，意味着不期望 vCPU 热插拔，也无法执行。

--cpus max=3

topology

guest 平台的拓扑结构。

该选项为用户提供了一种描述应向 guest 暴露的确切拓扑结构的方法。它可用于向 guest 描述与主机上相同的拓扑结构，因为这允许正确使用资源，并且是提高性能的一种方式。

拓扑结构通过以下结构描述：

struct CpuTopology {
    threads_per_core: u8,
    cores_per_die: u8,
    dies_per_package: u8,
    packages: u8,
}

或者通过 CLI 使用以下语法：

topology=<threads_per_core>:<cores_per_die>:<dies_per_package>:<packages>

默认情况下，拓扑结构将是 1:1:1:1 。示例:

--cpus boot=2,topology=1:1:2:1

kvm_hyperv

启用 KVM Hyper-V 模拟。

当启用此选项时，它依赖于 KVM 来模拟合成中断控制器（SynIC）以及 Windows guest 所期望的合成计时器。Windows 客机通常在 Microsoft Hyper-V 上运行，因此期望这些合成设备存在。这就是为什么 KVM 提供了一种模拟它们的方法，并避免了使用 Cloud Hypervisor 运行 Windows guest 时出现的故障。

默认情况下，此选项是关闭的。

max_phys_bits

最大可寻址空间大小。

此选项定义了所有 vCPU 的最大物理位数，这为虚拟机的可寻址空间大小设置了限制。这主要用于调试目的。

affinity

每个 vCPU 的亲和性。

此选项为用户提供了一种方式来指定每个 vCPU 关联的主机 CPU 集。这对于实现 CPU 固定很有用，可以确保多个虚拟机不会互相影响性能。在 NUMA 上下文中，它也可以被使用，因为它是一种确保虚拟机可以在特定主机 NUMA 节点上运行的方式。通常，此选项用于根据主机平台和虚拟机中运行的负载类型来提高虚拟机的性能。

亲和性通过以下结构描述：

struct CpuAffinity {
    vcpu: u8,
    host_cpus: Vec<u8>,
}

或者通过 CLI 使用以下语法：

affinity=[<vcpu_id1>@[<host_cpu_id1>, <host_cpu_id2>], <vcpu_id2>@[<host_cpu_id3>, <host_cpu_id4>]]

外层括号定义了 vCPU 的列表。而对于每个 vCPU，附在 @ 上的内层括号定义了该 vCPU 被允许运行的主 CPU 列表。

可以提供多个值来定义每个列表。每个值是一个 8 位的无符号整数。

例如，如果需要在从 0 到 4 的主 CPU 上运行 vCPU 0，使用 - 的语法将有助于定义一个连续的范围，配合 affinity=0@[0-4] 使用。同一个例子也可以用 affinity=0@[0,1,2,3,4] 来描述。

当需要描述一个包含从 0 到 99 的主 CPU 和主 CPU 255 的列表时，同时使用 - 和 , 分隔符会很有用，因为这样可以用 affinity=0@[0-99,255] 简单地描述。

一旦试图描述一组值，就必须使用 [ 和 ] 来界定这组值。

默认情况下，每个 vCPU 都在整个主机 CPU 集上运行。

--cpus boot=3,affinity=[0@[2,3],1@[0,1]]

在这个例子中，假设主机有 4 个 CPU，vCPU 0 将专门在主机的 CPU 2 和 3 上运行，而 vCPU 1 将专门在主机的 CPU 0 和 1 上运行。由于 vCPU 2 没有定义，它可以在任何 4 个主 CPU 上运行。

features

要启用的 CPU 功能集。

此选项允许用户启用一组默认情况下被禁用的 CPU 特性。

当前可用的特性集是： amx

amx 功能将启用 x86 扩展，为矩阵运算（整数和浮点数点积）添加硬件单元。该扩展的目标是为这些常见操作提供性能提升。

--cpus features=amx

在这个示例中，将为 VMM 启用 amx CPU 功能。

Optimize: KSM

Sat, 15 Nov 2025 00:00:00 +0000

KSM (Kernel Same-page Merging):

方案：在 Host (BMS) 内核开启 KSM。扫描内存页，将内容相同的页合并为只读页。
适用场景：如果你的 MicroVM 运行着相同的应用程序或库，KSM 能进一步合并代码段和数据段内存。

注意： KSM 消耗 CPU 资源，需权衡扫描频率（sleep_millisecs）和 CPU 占用。

利用 ksm 合并系统内存页

Optimize: 下载

Sat, 15 Nov 2025 00:00:00 +0000

信息

cloud hypervisor官方优化内核的代码仓库为：

https://github.com/cloud-hypervisor/linux/

优化内核的二进制下载地址为：

https://github.com/cloud-hypervisor/linux/releases

选择

最新版本为 ch-release-v6.16.9-20251112，这是 linux 6.16 内核。考虑到我目前用的 debian 13 的物理机的内核是 6.12 内核，因此我保持两者的一致，继续使用 linux 6.12 内核作为 guest os 的内核。

等以后 debian13 升级到 6.16 内核再考虑升级 guest os 的内核版本。

支持 x86-64, arm64 和 riscv，以 x86-64 为例，有两个版本：

bzImage-x86_64： 7.99MB，标准 Linux 发行版用的压缩内核。虽然 Cloud Hypervisor 也支持，但它在启动时需要额外的解压过程，对内存优化场景不如 vmlinux 直接。
vmlinux-x86_64： 45.8MB，原始的内核 ELF 文件（未压缩）。Cloud Hypervisor 可以直接解析它

推荐选择 vmlinux 版本： Cloud Hypervisor 属于“轻量级 VMM”，它支持 Direct Kernel Boot（直接内核引导）。与传统虚拟机需要 bzImage（带解压引导头的压缩镜像）不同，Cloud Hypervisor 更倾向于直接加载 ELF 格式的 vmlinux。这样启动速度最快，且内存占用最少。

下载

下载到特定目录，方便以后使用：

mkdir /home/sky/work/soft/cloudhypervisor/kernel/ch-6.12

cd /home/sky/work/soft/cloudhypervisor/kernel/ch-6.12

wget https://github.com/cloud-hypervisor/linux/releases/download/ch-release-v6.12.8-20250613/vmlinux-x86_64

cp vmlinux-x86_64 vmlinux

mv vmlinux-x86_64 vmlinux-x86_64-download

Docs: 构建

Wed, 15 Oct 2025 00:00:00 +0000

也可以不下载,自己从源码开始构建.

参考: https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/docs/building.md

准备

机器信息:

操作系统: debian13
内核: 6.12

准备工作:

mkdir -p $HOME/work/soft/cloudhypervisor

export CLOUDH=$HOME/work/soft/cloudhypervisor

cd $CLOUDH

安装依赖包:

sudo apt-get update
sudo apt install git build-essential m4 bison flex uuid-dev qemu-utils musl-tools

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

rustup target add x86_64-unknown-linux-musl

构建

clone 代码并开始构建:

mkdir -p ~/work/code/cloud-hypervisor
cd ~/work/code/cloud-hypervisor

git clone https://github.com/cloud-hypervisor/cloud-hypervisor.git
cd cloud-hypervisor
# 最新的 release tag
git checkout v50.0
# 采用静态链接
cargo build --release --target=x86_64-unknown-linux-musl --all
sudo setcap cap_net_admin+ep ./target/x86_64-unknown-linux-musl/release/cloud-hypervisor

检查构建之后的版本：

./target/x86_64-unknown-linux-musl/release/cloud-hypervisor --version
cloud-hypervisor v50.0

ls -lh ./target/x86_64-unknown-linux-musl/release/cloud-hypervisor 
-rwxrwxr-x 2 sky sky 4.0M Nov 18 15:23 ./target/x86_64-unknown-linux-musl/release/cloud-hypervisor

静态链接也才4M,没大多少.

Features: 快照文件信息

Wed, 15 Oct 2025 00:00:00 +0000

文件列表

快照生成时，需要指定一个目录，然后会生成如下三个文件，以4G内存的虚拟机为例：

ls -lh
total 4.1G
-rw------- 1 root root 1.4K Dec 30 17:23 config.json
-rw------- 1 root root 4.0G Dec 30 17:23 memory-ranges
-rw------- 1 root root  42K Dec 30 17:23 state.json

config.json

config.json 格式化之后的内容:

{
  "cpus": {
    "boot_vcpus": 1,
    "max_vcpus": 1,
    "topology": null,
    "kvm_hyperv": false,
    "max_phys_bits": 46,
    "affinity": null,
    "features": {
      "amx": false
    },
    "nested": true
  },
  "memory": {
    "size": 4294967296,
    "mergeable": false,
    "hotplug_method": "Acpi",
    "hotplug_size": null,
    "hotplugged_size": null,
    "shared": false,
    "hugepages": false,
    "hugepage_size": null,
    "prefault": false,
    "zones": null,
    "thp": true
  },
  "payload": {
    "firmware": null,
    "kernel": "/home/sky/work/test/cloudhypervisor/vmlinux.bin",
    "cmdline": "root=/dev/vda1 console=hvc0 rw",
    "initramfs": null
  },
  "rate_limit_groups": null,
  "disks": [
    {
      "path": "/home/sky/work/test/cloudhypervisor/ubuntu-cloud-image/rootfs.raw",
      "readonly": false,
      "direct": false,
      "iommu": false,
      "num_queues": 1,
      "queue_size": 128,
      "vhost_user": false,
      "vhost_socket": null,
      "rate_limit_group": null,
      "rate_limiter_config": null,
      "id": "_disk0",
      "disable_io_uring": false,
      "disable_aio": false,
      "pci_segment": 0,
      "serial": null,
      "queue_affinity": null
    }
  ],
  "net": null,
  "rng": {
    "src": "/dev/urandom",
    "iommu": false
  },
  "balloon": null,
  "fs": null,
  "pmem": null,
  "serial": {
    "file": null,
    "mode": "Null",
    "iommu": false,
    "socket": null
  },
  "console": {
    "file": null,
    "mode": "Tty",
    "iommu": false,
    "socket": null
  },
  "debug_console": {
    "file": null,
    "mode": "Off",
    "iobase": 233
  },
  "devices": null,
  "user_devices": null,
  "vdpa": null,
  "vsock": null,
  "pvpanic": false,
  "iommu": false,
  "numa": null,
  "watchdog": false,
  "pci_segments": null,
  "platform": null,
  "tpm": null,
  "landlock_enable": false,
  "landlock_rules": null
}

这个 config.json 文件是 Cloud Hypervisor 在执行快照（Snapshot）时生成的，它记录了虚拟机在快照那一刻的静态配置信息。当恢复（Restore）快照时，Cloud Hypervisor 会读取这个文件来重建虚拟机的“骨架”（CPU、内存大小、磁盘路径等），然后再加载内存和设备状态。

关键配置解读:

CPU 设置 (cpus)

boot_vcpus: 1: 虚拟机启动时分配了 1 个 vCPU。
max_vcpus: 1: 最大也是 1，说明这台 VM 不支持 CPU 热插拔（如果要支持，max_vcpus 通常要大于 boot_vcpus）。
nested: true: 嵌套虚拟化已启用。这意味着您在这个 MicroVM 里面还可以运行 KVM（例如在 VM 里运行 Docker 或 QEMU）。这在测试环境中很有用。

内存设置 (memory)

size: 4294967296: 即 4GB (4 * 1024 * 1024 * 1024)。
hotplug_method: “Acpi”: 如果支持内存热插拔，将使用 ACPI 机制通知 Guest OS。
thp: true: 启用了 Transparent Huge Pages（透明大页），这通常有助于减少 TLB miss，提升内存访问性能。

启动载荷 (payload)

这是 Direct Kernel Boot 的核心配置。

kernel: /home/sky/work/test/cloudhypervisor/vmlinux.bin

注意：这里记录的是绝对路径。如果把快照目录复制到另一台机器上去恢复，必须确保那台机器的相同路径下也有这个内核文件，否则恢复会失败。
cmdline: root=/dev/vda1 console=hvc0 rw
- root=/dev/vda1: 指定根文件系统挂载点。
- console=hvc0: 关键点。Cloud Hypervisor 默认使用 Virtio Console (hvc0) 而不是传统的串口 (ttyS0)。如果您在启动时看不到输出，需要检查 Guest OS 是否启用了 hvc0 的 getty 服务。

磁盘设备 (disks)

path: /home/sky/work/test/cloudhypervisor/ubuntu-cloud-image/rootfs.raw

同样是绝对路径。恢复快照时，程序会去这个位置找磁盘文件。如果磁盘文件被删了或者移动了，恢复会报错。
readonly: false: 磁盘是可读写的。
direct: false: 没有开启 Direct I/O（O_DIRECT），意味着磁盘读写会经过宿主机的 Page Cache。

网络 (net)

null: 您启动这个虚拟机时没有配置网络接口。它是一个“单机”环境，无法联网。

控制台与串口 (console & serial)

console (Virtio Console):
- mode: “Tty”。这意味着虚拟机的 hvc0 输出被重定向到了宿主机运行 cloud-hypervisor 进程的当前终端（TTY）。
serial (Legacy Serial):
- mode: “Null”。传统的串口（ttyS0）被禁用了/未连接。这就是为什么上面的 cmdline 必须用 console=hvc0 的原因。

随机数生成器 (rng)

src: “/dev/urandom”:

虚拟机配置了 Virtio RNG 设备，透传宿主机的 /dev/urandom。这对于 MicroVM 来说很重要，可以加速虚拟机启动（避免因为熵不足导致启动阻塞）。

注意事项：

路径依赖风险：这个 config.json 文件对宿主机的文件路径（Kernel 和 Disk）有强依赖。如果在本地测试备份/恢复没问题。如果要在不同机器间迁移快照，需要在恢复前修改这个 json 文件里的路径，或者确保两台机器目录结构一致。
嵌套虚拟化：

默认开启了 nested: true，这会增加一些 CPU 开销，如果不需要在 VM 里跑 VM，建议启动时去掉相关参数以提升性能。

关闭的方法：在启动时配置 cpu为 nested off，例如 --cpus boot=1,nested=off \

state.json

state.json 文件大小约为 42 KB。

在 Cloud Hypervisor 的快照体系中，state.json 与 config.json 扮演着完全不同但互补的角色。

如果说 config.json 是虚拟机的**“骨架”（硬件配置），那么 state.json 就是虚拟机的“灵魂”**（运行时的瞬间状态）。

存放的信息

文件记录了虚拟机在暂停那一瞬间，所有“非静态”的、动态变化的数据。具体包括：

vCPU 寄存器状态：这是最核心的部分。包含：
- 通用寄存器：RAX, RBX, RSP (栈指针), RIP (指令指针 - 代码执行到哪一行了)。
- 控制寄存器：CR0, CR3 (页表地址), CR4 等。
- 段寄存器：CS, DS, SS 等。
- 浮点数与向量寄存器：用于数学计算的状态。
- 简单说：它记录了 CPU 下一条指令要算什么，以及当前的计算结果存在哪。
设备后端状态 (Virtio Devices)：
- Virtio Queues (虚拟队列)：记录了磁盘或网卡读写到哪一个位置了（Available Ring 和 Used Ring 的索引）。
- Feature Bits：宿主机和虚拟机协商好了开启哪些功能（比如是否开启了巨型帧、多队列等）。
中断控制器状态 (vPIC / vIOAPIC / LAPIC)：
- 记录当前有哪些中断正在排队等待 CPU 处理，哪些中断被屏蔽了。
时钟与计时器：
- 虚拟机内部的时间偏移量，确保恢复后时间能尽量同步。

用处

它的唯一作用就是“现场还原”。

当执行 resume 或从文件恢复虚拟机时：

Cloud Hypervisor 先读取 config.json 创建出 CPU 线程和设备对象（造出机器）。
然后读取 memory 文件把 RAM 数据填回去（恢复记忆）。
最后读取 state.json，把每一个 CPU 寄存器的值填回去，把网卡/磁盘队列的指针拨回到原来的位置（恢复思维）。

如果没有 state.json，虚拟机虽然有内存数据，但 CPU 不知道该从内存的哪个地址开始执行指令，也不知道刚才磁盘读写到一半的数据该怎么处理，虚拟机就会立刻崩溃。

注意事项

绝对不要手动修改

config.json 里的磁盘路径可以手动改（比如迁移机器后路径变了），但 state.json 里的数据是极度敏感的二进制状态的序列化。
- 风险：改错一个标点或数字，CPU 恢复时的寄存器状态就会错乱，导致 Guest OS 报 Kernel Panic 或直接死机。
- 建议：视其为只读的二进制文件。
版本强耦合 (Version Lock)

Cloud Hypervisor 开发迭代很快，state.json 的内部结构（Schema）经常会变。
- 风险：用 v50.0.0 生成的 state.json，很大可能无法在 v51.0.0 或 v52.0.0 上恢复。
- 建议：生产环境中，快照恢复必须使用与创建快照时完全相同版本的 Cloud Hypervisor。
与内存文件的原子性

state.json 和同目录下的内存文件（通常叫 memory）是即时对应的。

在 Cloud Hypervisor 的快照体系中，state（或者您看到的 state.json）与 config.json 扮演着完全不同但互补的角色。

如果说 config.json 是虚拟机的**“骨架”（硬件配置），那么 state.json 就是虚拟机的“灵魂”**（运行时的瞬间状态）。
包含敏感数据
- 风险：由于它保存了 CPU 寄存器，如果快照时某个程序正在处理密码或私钥，这些明文密钥可能正躺在 state.json 的寄存器值里。
- 建议：如果是在公有云或不可信环境传输快照，必须像保护磁盘文件一样保护 state.json。
CPU 拓扑一致性

state.json 里的 vCPU 数据列表是按照 config.json 里的 CPU 数量顺序排列的。恢复时，宿主机不仅要提供相同数量的 CPU，最好连 CPU 的型号特性（Host CPU Model）也尽量保持一致，否则可能出现指令集不兼容（比如快照时用到了 AVX512，恢复的机器不支持）。

memory-ranges

以 4g 内存规格的快照文件为例：

$ ls -lh
total 4.1G
-rw------- 1 root root 1.4K Dec 30 19:13 config.json
-rw------- 1 root root 4.0G Dec 30 19:13 memory-ranges
-rw------- 1 root root  35K Dec 30 19:13 state.json

可以使用支持稀疏文件的 tar -S 命令来将这个稀疏文件打包并使用 zstd 压缩：

sudo tar -cvSf snapshot.tar.zstd -I 'zstd -T0' config.json memory-ranges state.json

打包出来的 snapshot.tar.zstd 文件只有区区 67M，非常的小：

ls -lh
total 4.1G
-rw------- 1 root root 1.4K Dec 30 19:13 config.json
-rw------- 1 root root 4.0G Dec 30 19:13 memory-ranges
-rw-rw-r-- 1 sky  sky   67M Jan  4 15:39 snapshot.tar.zstd
-rw------- 1 root root  35K Dec 30 19:13 state.json

复制这个文件到其他目录，然后以支持稀疏文件的 tar 命令进行解压缩：

mkdir snapshot-4g-distributed
cd snapshot-4g-distributed
cp ../snapshot-4g/snapshot.tar.zstd .

sudo tar -xvSf snapshot.tar.zstd -I 'zstd -d'

解压缩之后的目录文件为：

ls -lh 
total 4.1G
-rw------- 1 root root 1.4K Dec 30 19:13 config.json
-rw------- 1 root root 4.0G Dec 30 19:13 memory-ranges
-rw-rw-r-- 1 sky  sky   67M Jan  4 15:44 snapshot.tar.zstd
-rw------- 1 root root  35K Dec 30 19:13 state.json

memory-ranges 文件解压缩之后恢复到 4.0G 的表面大小。为了验证这个 memory-ranges 文件依然是稀疏文件，我们再次用 tar 命令进行打包压缩测试：

sudo tar -cvSf snapshot2.tar.zstd -I 'zstd -T0' config.json memory-ranges state.json

重新打包的 snapshot2.tar.zstd 文件依然是 67M，验证前面对稀疏文件的打包/传输/解包过程都是支持稀疏文件的。

ls -lh                                                                              
total 4.2G
-rw------- 1 root root 1.4K Dec 30 19:13 config.json
-rw------- 1 root root 4.0G Dec 30 19:13 memory-ranges
-rw-r--r-- 1 root root  67M Jan  4 15:48 snapshot2.tar.zstd
-rw-rw-r-- 1 sky  sky   67M Jan  4 15:44 snapshot.tar.zstd
-rw------- 1 root root  35K Dec 30 19:13 state.json

因此，对于快照文件的存储和传输，使用支持稀疏文件的打包压缩方式是必须的，可以极大的减少存储和网络传输的流量压力，以及下载快照文件带来的延迟。

重复这个测试，对其他内存规格的快照文件进行打包和压缩：

Practices: 在腾讯SCF的落地实践

Sun, 23 Nov 2025 00:00:00 +0000

腾讯云函数（SCF - Serverless Cloud Function）

公开资料

首次公开：腾讯云虚拟化技术原理及可用性提升实践: 2020-06-24, 实际还是vm，没有用到 cloud hypervisor
腾讯云函数访问VPC网络架构优化: 2019-07-11
腾讯云Serverless2.0架构精解: 2019-10
腾讯云函数计算冷启动优化实践: 2019-07-11

Optimize: arm64 支持

Sat, 15 Nov 2025 00:00:00 +0000

https://aistudio.google.com/prompts/1xw2bDNLkdRaZq5u8OqOhAuIZm5Nwox1j

输入：

有一个关键问题，Virtio-fs + DAX 在 arm64 平台上可以使用吗？

这是一个非常关键且实际的问题。因为 ARM64（AArch64）架构在云原生和 AI 推理场景（如 AWS Graviton, Huawei Kunpeng, Ampere Altra）中越来越普及，但很多虚拟化特性最初都是围绕 x86 开发的。

结论是：可以使用。Virtio-fs + DAX 目前已经支持 ARM64 平台，但有严格的版本要求和配置限制（尤其是页大小对齐）。

以下是针对 ARM64 平台上使用 Virtio-fs + DAX 的详细现状、限制和注意事项：

1. 支持现状与版本要求

Virtio-fs 的 DAX 支持引入 ARM64 架构比 x86 晚一些，主要涉及到 ARM 架构下的内存管理（MMU）、缓存一致性（Cache Coherency）和 PCI BAR 映射机制的差异。

要使其正常工作，你需要满足以下软件栈要求：

Host Kernel（宿主机内核）: 建议 Linux 5.13+，最好是 5.15 LTS 或更高。
- 早期的内核在 ARM64 上处理 virtio-fs 的 DAX 映射时存在 bug，或者不支持通过 PCI BAR 进行大内存窗口映射。
Guest Kernel（MicroVM 内核）: 同样建议 Linux 5.13+。
- Guest 内核必须编译开启 CONFIG_DAX, CONFIG_FS_DAX, CONFIG_VIRTIO_FS。
Cloud Hypervisor: 建议使用 v26.0 或更高版本（越新越好）。
- Cloud Hypervisor 社区对 ARM64 的支持非常积极，它是目前在 ARM64 上运行 MicroVM 的首选 VMM 之一。

2. 核心大坑：页大小（Page Size）对齐问题

这是在 ARM64 上使用 DAX 最容易踩的坑，也是与 x86 最大的不同点。

x86: 几乎所有通用 Linux 发行版默认 Page Size 都是 4KB。Host 和 Guest 天然一致。
ARM64: Linux 内核支持 4KB 和 64KB 页大小。
- 很多 ARM 服务器发行版（如某些版本的 CentOS/RHEL for ARM）默认可能开启 64KB 页以提升性能。
- Android 或某些嵌入式环境通常是 4KB。

DAX 的硬性限制：Host 和 Guest 的 Page Size 必须一致。

因为 DAX 机制是通过 mmap 将 Host 的物理页直接映射到 Guest 的物理地址空间。如果页大小不一致（例如 Host 4KB，Guest 64KB），Guest 内核在建立页表映射时会因为对齐（Alignment）问题而失败，或者回退到无 DAX 模式。

避坑指南：

检查 Host: 执行 getconf PAGESIZE，确认是否为 4096 (4KB)。
检查 Guest Kernel Config: 确保 MicroVM 的内核编译选项 CONFIG_ARM64_4K_PAGES=y。
强制一致: 强烈建议 Host 和 Guest 都统一使用 4KB 页大小。虽然 64KB/64KB 理论上可行，但在虚拟化大页分配和内存碎片上可能会遇到边缘 Case。

3. PCI BAR 窗口大小限制

在 ARM64 架构上，PCI 设备（这里指 Virtio-fs 设备）映射的 MMIO 空间（DAX Window）大小可能会受到物理地址布局的限制。

x86: 我们可以比较随意地给 cache_size 设置 8G、16G。
ARM64: 取决于 Cloud Hypervisor 定义的 Guest 物理内存布局（Memory Layout）。在 ARM64 虚拟化中，用于 PCI MMIO 的地址空间是有限的（通常在 highmem 区域）。
- 如果你设置了非常大的 DAX Window（例如 32GB），可能会导致 Cloud Hypervisor 启动失败，提示无法分配足够的 PCI 资源或地址空间冲突。
- 建议： 开始时不要设得过大，例如先从 2GB 或 4GB 开始测试，够用即可。

4. 缓存一致性 (Cache Coherency)

ARM64 是弱内存序（Weakly Ordered）架构，且不同 SoC 对 DMA 一致性的处理不同。

在 Virtio-fs DAX 模式下，CPU 直接访问 Host 内存。
Cloud Hypervisor 和 KVM 在 ARM64 上已经处理了大部分一致性问题（通过将映射区域标记为合适的内存属性）。
注意： 确保你的 ARM 服务器（BMS）是标准的服务器级芯片（如 Kunpeng 920, Yitian 710, Graviton），它们通常有硬件支持的 IO Coherency。如果在一些嵌入式 ARM 板卡（如 Jetson, Raspberry Pi）上尝试，可能会遇到数据损坏问题，但在 BMS 场景下通常不需要担心。

5. 验证命令

在 ARM64 机器上部署后，务必在 Guest 内部验证 DAX 是否真正生效：

启动 Guest 后检查挂载信息：

# 在 Guest 内部
mount | grep virtiofs
# 输出应该包含 "dax" 关键字
# myfs on /mnt type virtiofs (rw,relatime,dax)

查看内核日志（dmesg）： 如果 DAX 失败，内核日志通常会非常诚实地报错：

dmesg | grep -i "virtio-fs"
# 如果看到类似 "DAX unsupported" 或 "alignment error" 的警告，说明降级到了传统模式。

总结方案

在 ARM64 BMS 上设计高密 AI Agent：

可行性： 完全可行，且效果显著。
Host OS: 使用 Ubuntu 22.04 LTS (Kernel 5.15) 或更高，确认为 4KB Page Size。
Guest Kernel: 编译专门的 MicroVM Kernel（推荐 5.15 或 6.1），务必开启 4KB Page Size。
配置： Cloud Hypervisor 启动参数开启 cache_size，初始设置为 4GB。
收益： 与 x86 一样，可以实现 Python 库和 AI 模型内存的零拷贝共享。

Optimize: debian13

Sat, 15 Nov 2025 00:00:00 +0000

背景

由于我们为 microvm 场景定制的内核是 25.9MB 的全内置 (Monolithic) 内核，因此 Rootfs 制作将遵循一个核心原则：彻底剔除所有内核模块和硬件固件。

Optimize: Hugepages

Sat, 15 Nov 2025 00:00:00 +0000

Hugepages (大页内存):

方案：在 Host 上为 Cloud Hypervisor 进程分配 2MB 或 1GB 的 Hugepages。

效果：减少 Host CPU 的 TLB (Translation Lookaside Buffer) Miss，降低页表本身的内存占用（Page Table Overhead）。对于高密场景，海量的 4KB 页表项会占用大量内存，使用 2MB 大页是必须的。

优化 Hugepage 使用，减少 TLB miss。

Docs: 使用virtio-fs

Sat, 15 Nov 2025 00:00:00 +0000

https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/docs/fs.md

在虚拟化环境中，能够从 host 共享目录到 guest 总是很方便。

virtio-fs，也称为 vhost-user-fs，是由 VIRTIO 规范定义的虚拟设备，它允许任何 VMM 执行文件系统共享。

前提条件

守护进程

这个虚拟设备依赖于 vhost-user 协议，该协议假设后端（设备模拟）由主机上运行的专用进程处理。这个守护进程称为 virtiofsd，并且需要在主机上存在。

构建 virtiofsd:

git clone https://gitlab.com/virtio-fs/virtiofsd
pushd virtiofsd
cargo build --release
sudo setcap cap_sys_admin+epi target/release/virtiofsd

创建共享目录:

mkdir /tmp/shared_dir

运行 virtiofsd:

./virtiofsd \
    --log-level debug \
    --socket-path=/tmp/virtiofs \
    --shared-dir=/tmp/shared_dir \
    --cache=never \
    --thread-pool-size=$N

当使用 Cloud Hypervisor 与 virtiofsd 时， cache=never 选项是默认设置。这会阻止使用主机页面缓存，从而减少对主机内存的整体占用。这增加了单个主机上可以启动的虚拟机的最大密度。

cache=always 选项将允许使用主机页面缓存，这可能会以增加对主机内存占用的代价，为 guest 的负载带来更好的性能。

thread-pool-size 选项控制生成多少个 IO 线程。对于非常快的存储如 NVMe，生成足够的工作线程对于与原生性能相比获得可接受的性能至关重要。

内核支持

现代 Linux 内核（至少 v5.10）支持 virtio-fs。使用较旧的内核，即使有额外的补丁，也不受支持。

如何与 cloud-hypervisor 共享目录

启动虚拟机

一旦守护进程运行，就需要使用 Cloud Hypervisor 的 –fs 选项。

只要云镜像包含足够新的内核，就可以使用直接内核启动和 EFI 固件来启动使用 virtio-fs 的虚拟机。

--fs 的正确运行需要 --memory shared=on 来促进进程间内存共享。

假设你的系统上已经安装了 focal-server-cloudimg-amd64.raw 和 vmlinux ，以下是需要运行的 Cloud Hypervisor 命令：

./cloud-hypervisor \
    --cpus boot=1 \
    --memory size=1G,shared=on \
    --disk path=focal-server-cloudimg-amd64.raw \
    --kernel vmlinux \
    --cmdline "console=hvc0 root=/dev/vda1 rw" \
    --fs tag=myfs,socket=/tmp/virtiofs,num_queues=1,queue_size=512

挂载共享目录

最后一步是在 guest 内部挂载共享目录，使用 virtiofs 文件系统类型。

mkdir mount_dir
mount -t virtiofs myfs mount_dir/

tag 需要与通过 Cloud Hypervisor 命令行提供的内容保持一致，在本例中恰好是 myfs 。

DAX 功能

由于 DAX 功能从守护进程的角度来看还不稳定，因此它目前不可用。

Optimize: 构建

Sat, 15 Nov 2025 00:00:00 +0000

信息

cloud hypervisor官方优化内核的代码仓库为：

https://github.com/cloud-hypervisor/linux/

选择目前最稳定的分支版本： 6.12.8

构建

准备工作

先安装依赖包：

sudo apt install libelf-dev
sudo apt install bc

下载源码，切到 6.12.8 分支：

mkdir /home/sky/work/code/cloud-hypervisor
cd /home/sky/work/code/cloud-hypervisor

git clone --depth 1 https://github.com/cloud-hypervisor/linux.git -b ch-6.12.8
cd linux

默认构建

# 生成 Cloud Hypervisor 专属精简配置
make ch_defconfig

# 开始编译 (只生成 vmlinux，不浪费时间打包 bzImage)
make -j$(nproc) vmlinux

完成后，生成的 vmlinux 文件就放在根目录，大小为 48MB：

ls -lh vmlinux         
-rwxrwxr-x 1 sky sky 48M Feb 26 19:45 vmlinux

这个版本的内核还是太大了，包含了大量的调试信息和不必要的通用驱动。需要继续裁剪。

定制极简内核

可以通过菜单方式进行配置：

make menuconfig

但这个方式比较繁琐，而且不方便重用。因此我们采用命令行方式进行配置。

查找内核空间占用

首先找出来内核里最占空间的“罪魁祸首”是谁，比如这是执行 make ch_defconfig 之后构建的 linux 内核的空间占用结果：

nm --size-sort -r vmlinux | head -n 20

输出结果为：

0000000000580000 d _printk_rb_static_infos
0000000000400000 d sme_workarea
0000000000200000 b __log_buf
0000000000180000 d _printk_rb_static_descs
0000000000044000 b preferred_node_policy
0000000000040000 D early_dynamic_pgts
0000000000019000 d change_point_list
0000000000018000 b wait_table
0000000000010130 B hstates
0000000000010000 b stack_pools
0000000000010000 b __brk_early_pgt_alloc
0000000000010000 b __brk_dmi_alloc
0000000000010000 D __apicid_to_node
000000000000fa04 d e820_table_kexec_init
000000000000fa04 d e820_table_init
000000000000fa04 d e820_table_firmware_init
000000000000fa00 d new_entries
000000000000c800 B pfn_mapped
000000000000c800 d change_point
000000000000c008 b numa_reserved_meminfo

此时内核文件的大小为 48 MB：

ls -lh vmlinux         
-rwxrwxr-x 1 sky sky 48M Feb 26 19:45 vmlinux

我们开始逐个进行裁剪，看看内核大小的变化。

开启尺寸优化

开启 GCC 的 -Os 优化级别，显著减少内核体积（通常能砍掉 2MB - 5MB）。

./scripts/config --enable CC_OPTIMIZE_FOR_SIZE

make clean
make olddefconfig

make -j$(nproc) vmlinux
ls -lh vmlinux
nm --size-sort -r vmlinux | head -n 20

但比较奇怪的是，单独开启这个优化，内核文件大小反而从 48MB 增加到了 49MB。但没关系，后面陆续裁剪之后这个优化的效果会显露出来。

ls -lh vmlinux
-rwxrwxr-x 1 sky sky 49M Feb 26 19:46 vmlinux

缩小日志缓存区

排名第一的 _printk_rb_static_infos 占用了 5.5MB， __log_buf 占用 2MB。

0000000000580000 d _printk_rb_static_infos
0000000000200000 b __log_buf

内核体积大，很大程度上是因为日志缓冲区（Log Buffer）和打印信息设置得太大

路径： General setup -> Kernel log buffer size，默认值是 21，修改为 14.

检查 General setup -> CPU kernel log buffer size contribution，设置为 0.

为什么设为 0 是合适的？

在标准的 Linux 内核中，这个参数的作用是：根据 CPU 核心数动态增加日志缓冲区的大小。

公式大致为：Total Log Buffer = Default Buffer + (Num_CPUs * 2^Contribution)。

由于我的 MicroVM 通常只分配 1 到 4 个虚拟 CPU，这种动态增长几乎没有意义，反而会静态预留内存页。

将其设为 0 意味着禁用动态增长，强制内核仅使用设定的 2^14 (16KB) 的基础缓冲区。对于只跑特定应用的 MicroVM，16KB 的启动日志已经绰绰有余。

界面操作还是比较麻烦的，尤其有些配置隐藏的比较深，可以通过命令来执行：

# 极度缩小日志缓冲区 (从 2MB+ 压低到 16KB)
./scripts/config --set-val LOG_BUF_SHIFT 14
./scripts/config --set-val LOG_CPU_MAX_BUF_SHIFT 0

# 关闭调试索引和 5 级页表 (节省静态内存)
./scripts/config --disable PRINTK_INDEX
./scripts/config --disable X86_5LEVEL

# 开启 Retpoline 支持
./scripts/config --enable RETPOLINE

裁剪之后重新编译：

make olddefconfig
make clean
make -j$(nproc) vmlinux
ls -lh vmlinux
nm --size-sort -r vmlinux | head -n 20

编译之后的 linux 内核文件大小为41MB，和之前的49MB相比减少了8MB：

ls -lh vmlinux
-rwxrwxr-x 1 sky sky 41M Feb 26 19:48 vmlinux

对比之前，_printk_rb_static_infos 和 __log_buf 这两个空间占用第一和第三的项目消失了：

nm --size-sort -r vmlinux | head -n 20

0000000000400000 d sme_workarea
0000000000044000 b preferred_node_policy
0000000000040000 D early_dynamic_pgts
0000000000019000 d change_point_list

关闭 SME

继续裁剪SME，Secure Memory Encryption 是 AMD 处理器的内存加密特性，通常在 MicroVM 内部不需要这个功能。

0000000000400000 d sme_workarea

./scripts/config --disable AMD_MEM_ENCRYPT

make olddefconfig
make clean
make -j$(nproc) vmlinux
ls -lh vmlinux
ls -l vmlinux
nm --size-sort -r vmlinux | head -n 20

裁剪 SME 之后，内核文件大小从41MB降低到了30MB：

ls -lh vmlinux                            
-rwxrwxr-x 1 sky sky 30M Feb 26 19:50 vmlinux
ls -l vmlinux                            
-rwxrwxr-x 1 sky sky 31133144 Feb 26 19:50 vmlinux

裁剪非必要的子系统

对于 MicroVM 来说，有些子系统是不需要的，比如图形支持，声音支持等。

./scripts/config --disable DRM
./scripts/config --disable SOUND
./scripts/config --disable ETHERNET
./scripts/config --disable HID
./scripts/config --disable INPUT
./scripts/config --disable KVM
./scripts/config --disable KVM_INTEL
./scripts/config --disable KVM_AMD
./scripts/config --disable PERF_EVENTS
./scripts/config --disable PROFILING
./scripts/config --disable BPF_SYSCALL
./scripts/config --disable AUDIT

make olddefconfig
make clean
make -j$(nproc) vmlinux
ls -lh vmlinux
ls -l vmlinux
nm --size-sort -r vmlinux | head -n 20

裁剪非必要的子系统之后，内核文件大小从30MB降低到了26MB：

-rwxrwxr-x 1 sky sky 26M Feb 26 20:27 vmlinux
-rwxrwxr-x 1 sky sky 26301552 Feb 26 20:27 vmlinux

精简文件系统

文件系统是 MicroVM 中非常重要的一个部分，但是有些文件系统是不需要的，比如 NTFS, CIFS, NFS 等。

# --- 1. 核心调试与辅助系统 (体积与内存大头) ---
# DEBUG_FS 是内核中非常庞大的符号和接口库
./scripts/config --disable DEBUG_FS
./scripts/config --disable BLK_DEBUG_FS
./scripts/config --disable STACKTRACE
./scripts/config --disable KALLSYMS_ALL

# --- 2. 移除现代存储高级特性 (MicroVM 通常不需要) ---
# DAX 是为了持久性内存(Optane等)设计的，虚拟化环境极少用到
./scripts/config --disable FS_DAX
./scripts/config --disable FS_DAX_PMD
# 禁用内核级文件加密逻辑
./scripts/config --disable FS_ENCRYPTION
./scripts/config --disable FS_ENCRYPTION_ALGS
./scripts/config --disable FS_VERITY

# --- 3. 辅助文件系统逻辑清理 ---
./scripts/config --disable AUTOFS_FS
./scripts/config --disable EFIVAR_FS
./scripts/config --disable CONFIGFS_FS
./scripts/config --disable FSNOTIFY

# --- 4. Ext4 深度瘦身 (只保留最基础的读写逻辑) ---
# 禁用 ACL(访问控制列表) 和 Security Labels(如 SELinux 标签)
# 如果你的 Rootfs 只是简单的权限管理，这两项可以砍掉几百个符号
./scripts/config --disable EXT4_FS_POSIX_ACL
./scripts/config --disable EXT4_FS_SECURITY
./scripts/config --disable FS_POSIX_ACL
./scripts/config --disable QUOTA

# --- 5. 虚拟化文件系统按需清理 ---
# 如果你只用 virtio-blk (磁盘镜像)，可以关掉下两项；
# 如果你用 Kata Containers 这种 virtio-fs 挂载模式，请保留它们。
./scripts/config --disable FUSE_FS
./scripts/config --disable VIRTIO_FS
./scripts/config --disable OVERLAY_FS

# --- 6. 常规文件系统裁剪清单 --
./scripts/config --disable XFS_FS
./scripts/config --disable BTRFS_FS
./scripts/config --disable F2FS_FS
./scripts/config --disable JFS_FS
./scripts/config --disable REISERFS_FS
./scripts/config --disable NTFS_FS
./scripts/config --disable NTFS3_FS
./scripts/config --disable CIFS
./scripts/config --disable SMB_SERVER
./scripts/config --disable NFS_FS
./scripts/config --disable GFS2_FS
./scripts/config --disable OCFS2_FS
./scripts/config --disable MINIX_FS
./scripts/config --disable HFS_FS
./scripts/config --disable HFSPLUS_FS
./scripts/config --disable ISO9660_FS
./scripts/config --disable UDF_FS
./scripts/config --disable FAT_FS
./scripts/config --disable VFAT_FS
./scripts/config --disable MSDOS_FS
./scripts/config --disable EROFS_FS
./scripts/config --disable SQUASHFS
./scripts/config --disable JOLIET
./scripts/config --disable ZISOFS

make olddefconfig
make clean
make -j$(nproc) vmlinux
ls -lh vmlinux
ls -l vmlinux
nm --size-sort -r vmlinux | head -n 20

裁剪文件系统之后，内核文件大小从26.30MB 降到 26.11MB，仅省下了约186KB。体积优化效果非常轻微：

#优化前
-rwxrwxr-x 1 sky sky 26301552 Feb 26 20:27 vmlinux

#优化后：
-rwxrwxr-x 1 sky sky 26115024 Feb 26 20:48 vmlinux

但是，虽然内核体积没减，但这个裁剪操作还有意义的，体现在以下几个方面：

攻击面（Attack Surface）减小：文件系统代码是内核漏洞的重灾区。关掉 NTFS、JFS、CIFS 等，意味着黑客无法通过构造恶意的磁盘镜像或网络包来利用这些复杂的解析逻辑。
启动稳定性：减少了内核启动时尝试探测不同文件系统类型的开销，虽然对 MicroVM 来说只是几毫秒，但更纯净。
内存脚印（Runtime Footprint）：虽然文件体积只差 28KB，但由于去掉了各种文件系统的初始化函数，内核启动后申请的 slab 缓存和全局变量会更少，运行时会更“轻”。

裁剪加密与压缩算法

nm --size-sort -r vmlinux | grep -i ' [tT] ' | head -n 20

可以看到有很多加密与压缩算法，这些算法在 MicroVM 中是不需要的：

0000000000004429 t __twofish_enc_blk8
0000000000004427 t __twofish_dec_blk8
0000000000002966 T intel_pmu_init
00000000000024c1 t sock_ops_convert_ctx_access
0000000000001ddd t ZSTD_decompressSequencesLong_default.constprop.0
0000000000001d86 t ZSTD_decompressSequencesLong_bmi2.constprop.0
0000000000001d85 T __twofish_enc_blk_3way
0000000000001d63 T twofish_dec_blk_3way
0000000000001b62 t ___bpf_prog_run
0000000000001a4c T x64_sys_call
000000000000187d T __twofish_setkey
000000000000183a t __dev_ethtool
0000000000001626 T aes_ctr_enc_256_avx_by8
0000000000001614 t HUF_decompress4X2_usingDTable_internal_default
0000000000001614 t HUF_decompress4X2_usingDTable_internal_bmi2
0000000000001519 T jbd2_journal_commit_transaction
00000000000014fa t ZSTD_decompressSequencesSplitLitBuffer_default.constprop.0
00000000000014a6 t ZSTD_decompressSequencesSplitLitBuffer_bmi2.constprop.0
0000000000001436 T aes_ctr_enc_192_avx_by8
0000000000001321 T blake2s_compress_generic

./scripts/config --disable CRYPTO_TWOFISH
./scripts/config --disable CRYPTO_TWOFISH_COMMON
./scripts/config --disable CRYPTO_TWOFISH_X86_64
./scripts/config --disable CRYPTO_TWOFISH_X86_64_3WAY
./scripts/config --disable CRYPTO_TWOFISH_AVX_X86_64
./scripts/config --disable CRYPTO_AES_NI_INTEL
./scripts/config --disable CRYPTO_MANAGER
./scripts/config --disable ZSTD_COMPRESS
./scripts/config --disable ZSTD_DECOMPRESS
./scripts/config --disable RD_ZSTD

make olddefconfig
make clean
make -j$(nproc) vmlinux
ls -lh vmlinux
ls -l vmlinux
nm --size-sort -r vmlinux | head -n 20
nm --size-sort -r vmlinux | grep -i ' [tT] ' | head -n 20

裁剪完成后体积减少了60KB：

#优化前
-rwxrwxr-x 1 sky sky 26115024 Feb 26 20:48 vmlinux
#优化后：
-rwxrwxr-x 1 sky sky 26055808 Feb 26 20:56 vmlinux

裁剪多国语言支持

NLS (Native Language Support)

在 ch_defconfig 中，内核通常为了兼容各种磁盘格式，编入了一大堆代码页（Codepages）。

grep "NLS" .config                           
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=y
CONFIG_NLS_CODEPAGE_775=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_CODEPAGE_852=y
CONFIG_NLS_CODEPAGE_855=y
CONFIG_NLS_CODEPAGE_857=y
CONFIG_NLS_CODEPAGE_860=y
CONFIG_NLS_CODEPAGE_861=y
CONFIG_NLS_CODEPAGE_862=y
CONFIG_NLS_CODEPAGE_863=y
CONFIG_NLS_CODEPAGE_864=y
CONFIG_NLS_CODEPAGE_865=y
CONFIG_NLS_CODEPAGE_866=y
CONFIG_NLS_CODEPAGE_869=y
CONFIG_NLS_CODEPAGE_936=y
CONFIG_NLS_CODEPAGE_950=y
CONFIG_NLS_CODEPAGE_932=y
CONFIG_NLS_CODEPAGE_949=y
CONFIG_NLS_CODEPAGE_874=y
CONFIG_NLS_ISO8859_8=y
CONFIG_NLS_CODEPAGE_1250=y
CONFIG_NLS_CODEPAGE_1251=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
CONFIG_NLS_ISO8859_3=y
CONFIG_NLS_ISO8859_4=y
CONFIG_NLS_ISO8859_5=y
CONFIG_NLS_ISO8859_6=y
CONFIG_NLS_ISO8859_7=y
CONFIG_NLS_ISO8859_9=y
CONFIG_NLS_ISO8859_13=y
CONFIG_NLS_ISO8859_14=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=y
CONFIG_NLS_KOI8_U=y
CONFIG_NLS_MAC_ROMAN=y
CONFIG_NLS_MAC_CELTIC=y
CONFIG_NLS_MAC_CENTEURO=y
CONFIG_NLS_MAC_CROATIAN=y
CONFIG_NLS_MAC_CYRILLIC=y
CONFIG_NLS_MAC_GAELIC=y
CONFIG_NLS_MAC_GREEK=y
CONFIG_NLS_MAC_ICELAND=y
CONFIG_NLS_MAC_INUIT=y
CONFIG_NLS_MAC_ROMANIAN=y
CONFIG_NLS_MAC_TURKISH=y
CONFIG_NLS_UTF8=y

对于只运行 Linux 现代文件系统（如 ext4/xfs）的 MicroVM，这些全是多余的。

# 彻底关闭 NLS 支持
# 6.1 强制关闭所有已有的 NLS 子项
grep "CONFIG_NLS_" .config | grep "=y" | cut -d'=' -f1 | while read line; do
    ./scripts/config --disable "$line"
done

# 6.2 重新开启必要的 UTF-8 和基础框架
./scripts/config --enable CONFIG_NLS
./scripts/config --enable CONFIG_NLS_UTF8
./scripts/config --enable CONFIG_NLS_ASCII
./scripts/config --enable CONFIG_NLS_ISO8859_1    # 西欧语言基石，必留
./scripts/config --enable CONFIG_NLS_CODEPAGE_936 # 简体中文支持
./scripts/config --set-str CONFIG_NLS_DEFAULT "utf8"
# 补充：确保基础的转换工具也被编译进去
./scripts/config --enable CONFIG_NLS_UCS2_UTILS

make olddefconfig
make clean
make -j$(nproc) vmlinux
ls -lh vmlinux
ls -l vmlinux
nm --size-sort -r vmlinux | head -n 20
nm --size-sort -r vmlinux | grep -i ' [tT] ' | head -n 20

NLS裁剪完成后体积减少了55KB：

#优化前
-rwxrwxr-x 1 sky sky 26055808 Feb 26 20:56 vmlinux
#优化后：
-rwxrwxr-x 1 sky sky 26000328 Feb 26 21:09 vmlinux

为了凑数，减少最后的 328 字节，我们再裁剪一下：

./scripts/config --disable UTS_NS

裁剪完成后体积减少了328字节：

#优化前
-rwxrwxr-x 1 sky sky 26000328 Feb 26 21:09 vmlinux
#优化后：
-rwxrwxr-x 1 sky sky 25999480 Feb 26 21:13 vmlinux

总结

把上面的裁剪汇总一下，这样以后如果需要裁剪内核，只需要执行下面的命令：

make clean
make ch_defconfig

./scripts/config --enable CC_OPTIMIZE_FOR_SIZE
./scripts/config --set-val LOG_BUF_SHIFT 14
./scripts/config --set-val LOG_CPU_MAX_BUF_SHIFT 0
./scripts/config --disable PRINTK_INDEX
./scripts/config --disable X86_5LEVEL
./scripts/config --enable RETPOLINE
./scripts/config --disable AMD_MEM_ENCRYPT

./scripts/config --disable DRM
./scripts/config --disable SOUND
./scripts/config --disable ETHERNET
./scripts/config --disable HID
./scripts/config --disable INPUT
./scripts/config --disable KVM
./scripts/config --disable KVM_INTEL
./scripts/config --disable KVM_AMD
./scripts/config --disable PERF_EVENTS
./scripts/config --disable PROFILING
./scripts/config --disable BPF_SYSCALL
./scripts/config --disable AUDIT

./scripts/config --disable DEBUG_FS
./scripts/config --disable BLK_DEBUG_FS
./scripts/config --disable STACKTRACE
./scripts/config --disable KALLSYMS_ALL
./scripts/config --disable FS_DAX
./scripts/config --disable FS_DAX_PMD
./scripts/config --disable FS_ENCRYPTION
./scripts/config --disable FS_ENCRYPTION_ALGS
./scripts/config --disable FS_VERITY
./scripts/config --disable AUTOFS_FS
./scripts/config --disable EFIVAR_FS
./scripts/config --disable CONFIGFS_FS
./scripts/config --disable FSNOTIFY
./scripts/config --disable EXT4_FS_POSIX_ACL
./scripts/config --disable EXT4_FS_SECURITY
./scripts/config --disable FS_POSIX_ACL
./scripts/config --disable QUOTA
./scripts/config --disable FUSE_FS
./scripts/config --disable VIRTIO_FS
./scripts/config --disable OVERLAY_FS
./scripts/config --disable XFS_FS
./scripts/config --disable BTRFS_FS
./scripts/config --disable F2FS_FS
./scripts/config --disable JFS_FS
./scripts/config --disable REISERFS_FS
./scripts/config --disable NTFS_FS
./scripts/config --disable NTFS3_FS
./scripts/config --disable CIFS
./scripts/config --disable SMB_SERVER
./scripts/config --disable NFS_FS
./scripts/config --disable GFS2_FS
./scripts/config --disable OCFS2_FS
./scripts/config --disable MINIX_FS
./scripts/config --disable HFS_FS
./scripts/config --disable HFSPLUS_FS
./scripts/config --disable ISO9660_FS
./scripts/config --disable UDF_FS
./scripts/config --disable FAT_FS
./scripts/config --disable VFAT_FS
./scripts/config --disable MSDOS_FS
./scripts/config --disable EROFS_FS
./scripts/config --disable SQUASHFS
./scripts/config --disable JOLIET
./scripts/config --disable ZISOFS

./scripts/config --disable CRYPTO_TWOFISH
./scripts/config --disable CRYPTO_TWOFISH_COMMON
./scripts/config --disable CRYPTO_TWOFISH_X86_64
./scripts/config --disable CRYPTO_TWOFISH_X86_64_3WAY
./scripts/config --disable CRYPTO_TWOFISH_AVX_X86_64
./scripts/config --disable CRYPTO_AES_NI_INTEL
./scripts/config --disable CRYPTO_MANAGER
./scripts/config --disable ZSTD_COMPRESS
./scripts/config --disable ZSTD_DECOMPRESS
./scripts/config --disable RD_ZSTD

grep "CONFIG_NLS_" .config | grep "=y" | cut -d'=' -f1 | while read line; do
    ./scripts/config --disable "$line"
done
./scripts/config --enable CONFIG_NLS
./scripts/config --enable CONFIG_NLS_UTF8
./scripts/config --enable CONFIG_NLS_ASCII
./scripts/config --enable CONFIG_NLS_ISO8859_1
./scripts/config --enable CONFIG_NLS_CODEPAGE_936 
./scripts/config --set-str CONFIG_NLS_DEFAULT "utf8"
./scripts/config --enable CONFIG_NLS_UCS2_UTILS
./scripts/config --disable UTS_NS

make clean
make olddefconfig
make -j$(nproc) vmlinux
ls -lh vmlinux
ls -l vmlinux
nm --size-sort -r vmlinux | head -n 20
nm --size-sort -r vmlinux | grep -i ' [tT] ' | head -n 20

最终内核大小为25M：

-rwxrwxr-x 1 sky sky 25M Feb 26 21:21 vmlinux
-rwxrwxr-x 1 sky sky 25999984 Feb 26 21:21 vmlinux

为了方便使用，创建脚本:

vi build_minimal_kernel.sh

内容为:

#!/bin/bash
set -e

echo "开始构建极致瘦身内核 (Target < 26MB)..."

# 1. 初始化配置
make clean
make ch_defconfig

# 2. 核心架构与编译器优化
./scripts/config --enable CC_OPTIMIZE_FOR_SIZE
./scripts/config --set-val LOG_BUF_SHIFT 14
./scripts/config --set-val LOG_CPU_MAX_BUF_SHIFT 0
./scripts/config --disable PRINTK_INDEX
./scripts/config --disable X86_5LEVEL
./scripts/config --enable RETPOLINE
./scripts/config --disable AMD_MEM_ENCRYPT
./scripts/config --disable UTS_NS

# 3. 剥离大型子系统 (显卡、声音、以太网、输入设备等)
./scripts/config --disable DRM
./scripts/config --disable SOUND
./scripts/config --disable ETHERNET
./scripts/config --disable HID
./scripts/config --disable INPUT
./scripts/config --disable KVM
./scripts/config --disable KVM_INTEL
./scripts/config --disable KVM_AMD
./scripts/config --disable PERF_EVENTS
./scripts/config --disable PROFILING
./scripts/config --disable BPF_SYSCALL
./scripts/config --disable AUDIT

# 4. 文件系统深度裁剪 (仅保留基础 Ext4 逻辑)
./scripts/config --disable DEBUG_FS
./scripts/config --disable BLK_DEBUG_FS
./scripts/config --disable STACKTRACE
./scripts/config --disable KALLSYMS_ALL
./scripts/config --disable FS_DAX
./scripts/config --disable FS_DAX_PMD
./scripts/config --disable FS_ENCRYPTION
./scripts/config --disable FS_ENCRYPTION_ALGS
./scripts/config --disable FS_VERITY
./scripts/config --disable AUTOFS_FS
./scripts/config --disable EFIVAR_FS
./scripts/config --disable CONFIGFS_FS
./scripts/config --disable FSNOTIFY
./scripts/config --disable EXT4_FS_POSIX_ACL
./scripts/config --disable EXT4_FS_SECURITY
./scripts/config --disable FS_POSIX_ACL
./scripts/config --disable QUOTA
./scripts/config --disable FUSE_FS
./scripts/config --disable VIRTIO_FS
./scripts/config --disable OVERLAY_FS

# 批量关闭其他不常用文件系统
for fs in XFS_FS BTRFS_FS F2FS_FS JFS_FS REISERFS_FS NTFS_FS NTFS3_FS CIFS SMB_SERVER \
          NFS_FS GFS2_FS OCFS2_FS MINIX_FS HFS_FS HFSPLUS_FS ISO9660_FS UDF_FS \
          FAT_FS VFAT_FS MSDOS_FS EROFS_FS SQUASHFS JOLIET ZISOFS; do
    ./scripts/config --disable $fs
done

# 5. 加密与压缩算法裁剪 (剔除汇编优化重灾区)
./scripts/config --disable CRYPTO_TWOFISH
./scripts/config --disable CRYPTO_TWOFISH_COMMON
./scripts/config --disable CRYPTO_TWOFISH_X86_64
./scripts/config --disable CRYPTO_TWOFISH_X86_64_3WAY
./scripts/config --disable CRYPTO_TWOFISH_AVX_X86_64
./scripts/config --disable CRYPTO_AES_NI_INTEL
./scripts/config --disable CRYPTO_MANAGER
./scripts/config --disable ZSTD_COMPRESS
./scripts/config --disable ZSTD_DECOMPRESS
./scripts/config --disable RD_ZSTD

# 6. 国际化 NLS 精简与简体中文/西欧补全
# 先清空所有 CodePage
grep "CONFIG_NLS_" .config | grep "=y" | cut -d'=' -f1 | while read line; do
    ./scripts/config --disable "$line"
done
# 精准开启
./scripts/config --enable CONFIG_NLS
./scripts/config --enable CONFIG_NLS_UTF8
./scripts/config --enable CONFIG_NLS_ASCII
./scripts/config --enable CONFIG_NLS_ISO8859_1
./scripts/config --enable CONFIG_NLS_CODEPAGE_936 
./scripts/config --set-str CONFIG_NLS_DEFAULT "utf8"
./scripts/config --enable CONFIG_NLS_UCS2_UTILS

# 7. 应用配置并编译
make olddefconfig
make -j$(nproc) vmlinux

# 8. 成果展示
echo "------------------------------------------"
ls -lh vmlinux
ls -l vmlinux
echo "Top 10 Functions by Size:"
nm --size-sort -r vmlinux | head -n 10
echo "------------------------------------------"
echo "构建完成！"

增加执行权限：

chmod +x build_minimal_kernel.sh

执行：

./build_minimal_kernel.sh

执行完成后，内核文件会生成在当前目录下，大小为25M。

定制agent专属内核

在上面定制的极简内核的基础上，针对 agent 的特殊使用场景，进行定制。主要的改动有：

启动 cloud hypervisor 时，内核和 rootfs 都是只读方式
内核文件通过直接内核加载 (Direct Kernel Boot) 读入，跳过 BIOS/UEFI 阶段
使用 virtio-pmem 的方式挂载 rootfs，并开启 DAX 功能，以最大化利用 Host 的 Page Cache
宿主机开启 KSM (Kernel Samepage Merging) 功能，以最大化利用内存

为此，内核需要进行改动：

磁盘格式由 ext4 修改为 erofs
需要支持 overlayfs 功能，以支持 rootfs 和可写层
需要支持 dax 功能，以最大化利用 Host 的 Page Cache

构建脚本

为了方便使用，创建脚本:

vi build_agent_kernel.sh

内容为:

#!/bin/bash
set -e

echo "开始构建 agent 专属内核 (EROFS + DAX + Ext4 Writable)..."

# 1. 初始化配置
make clean
make ch_defconfig

# 2. 核心架构与编译器优化
./scripts/config --enable CC_OPTIMIZE_FOR_SIZE
./scripts/config --set-val LOG_BUF_SHIFT 14
./scripts/config --set-val LOG_CPU_MAX_BUF_SHIFT 0
./scripts/config --disable PRINTK_INDEX
./scripts/config --disable X86_5LEVEL
./scripts/config --enable RETPOLINE
./scripts/config --disable AMD_MEM_ENCRYPT
./scripts/config --disable UTS_NS

# 3. 剥离大型子系统
./scripts/config --disable DRM
./scripts/config --disable SOUND
./scripts/config --disable ETHERNET
./scripts/config --disable HID
./scripts/config --disable INPUT
./scripts/config --disable KVM
./scripts/config --disable KVM_INTEL
./scripts/config --disable KVM_AMD
./scripts/config --disable PERF_EVENTS
./scripts/config --disable PROFILING
./scripts/config --disable BPF_SYSCALL
./scripts/config --disable AUDIT

# 4. 文件系统基础裁剪 (先关掉不需要的)
./scripts/config --disable DEBUG_FS
./scripts/config --disable BLK_DEBUG_FS
./scripts/config --disable STACKTRACE
./scripts/config --disable KALLSYMS_ALL
./scripts/config --disable FS_ENCRYPTION
./scripts/config --disable FS_ENCRYPTION_ALGS
./scripts/config --disable FS_VERITY
./scripts/config --disable AUTOFS_FS
./scripts/config --disable EFIVAR_FS
./scripts/config --disable CONFIGFS_FS
./scripts/config --disable FSNOTIFY
./scripts/config --disable QUOTA
./scripts/config --disable FUSE_FS
./scripts/config --disable VIRTIO_FS

# 批量关闭不常用文件系统
for fs in XFS_FS BTRFS_FS F2FS_FS JFS_FS REISERFS_FS NTFS_FS NTFS3_FS CIFS SMB_SERVER \
          NFS_FS GFS2_FS OCFS2_FS MINIX_FS HFS_FS HFSPLUS_FS ISO9660_FS UDF_FS \
          FAT_FS VFAT_FS MSDOS_FS SQUASHFS JOLIET ZISOFS; do
    ./scripts/config --disable $fs
done

# 5. 加密与压缩算法裁剪
./scripts/config --disable CRYPTO_TWOFISH
./scripts/config --disable CRYPTO_TWOFISH_COMMON
./scripts/config --disable CRYPTO_TWOFISH_X86_64
./scripts/config --disable CRYPTO_TWOFISH_X86_64_3WAY
./scripts/config --disable CRYPTO_TWOFISH_AVX_X86_64
./scripts/config --disable CRYPTO_AES_NI_INTEL
./scripts/config --disable CRYPTO_MANAGER
./scripts/config --disable ZSTD_COMPRESS
./scripts/config --disable ZSTD_DECOMPRESS
./scripts/config --disable RD_ZSTD

# 6. NLS 保持 (UTF-8 + 中文支持)
grep "CONFIG_NLS_" .config | grep "=y" | cut -d'=' -f1 | while read line; do
    ./scripts/config --disable "$line"
done
./scripts/config --enable CONFIG_NLS
./scripts/config --enable CONFIG_NLS_UTF8
./scripts/config --enable CONFIG_NLS_ASCII
./scripts/config --enable CONFIG_NLS_ISO8859_1
./scripts/config --enable CONFIG_NLS_CODEPAGE_936 
./scripts/config --set-str CONFIG_NLS_DEFAULT "utf8"
./scripts/config --enable CONFIG_NLS_UCS2_UTILS

# 7. 开启 DAX 与内存管理 (EROFS DAX 必备)
./scripts/config --enable FS_DAX
./scripts/config --enable FS_DAX_PMD
./scripts/config --enable DAX
./scripts/config --enable ZONE_DEVICE
./scripts/config --enable MEMORY_HOTPLUG
./scripts/config --enable MEMORY_HOTREMOVE

# 8. 开启设备驱动 (virtio-pmem 用于 Rootfs, virtio-blk 用于写层)
./scripts/config --enable VIRTIO_PMEM
./scripts/config --enable LIBNVDIMM
./scripts/config --enable BLK_DEV_PMEM
./scripts/config --enable VIRTIO_BLK

# 9. 开启 EROFS (只读 Rootfs 格式)
./scripts/config --enable EROFS_FS
./scripts/config --enable EROFS_FS_XATTR
./scripts/config --enable EROFS_FS_POSIX_ACL
./scripts/config --enable EROFS_FS_ZIP

# 10. 开启 OverlayFS
./scripts/config --enable OVERLAY_FS

# 11. 优化 Ext4 (写层专用)
./scripts/config --enable EXT4_FS
./scripts/config --disable EXT4_FS_POSIX_ACL
./scripts/config --disable EXT4_FS_SECURITY
./scripts/config --disable EXT4_DEBUG
./scripts/config --disable EXT4_KUNIT_TESTS

# 12. 应用配置并编译
make olddefconfig
make -j$(nproc) vmlinux

# 13. 成果展示
echo "------------------------------------------"
ls -lh vmlinux
echo "Top 10 Functions by Size:"
nm --size-sort -r vmlinux | head -n 10
echo "------------------------------------------"
echo "agent 专属内核构建完成！"

增加执行权限：

chmod +x build_agent_kernel.sh

执行：

./build_agent_kernel.sh

执行完成后，内核文件会生成在当前目录下，大小为25M。

-rwxrwxr-x 1 sky sky 25M Feb 28 09:43 vmlinux

构建脚本改进

根据启动时的 dmesg 信息进行优化改进:

vi build_agent_kernel2.sh

内容为:

#!/bin/bash
set -e

echo "开始构建 agent 专属内核 (EROFS + DAX + Ext4 Writable)..."

# 1. 初始化配置
make clean
make ch_defconfig

# 2. 核心架构与编译器优化
./scripts/config --enable CC_OPTIMIZE_FOR_SIZE
./scripts/config --set-val LOG_BUF_SHIFT 14
./scripts/config --set-val LOG_CPU_MAX_BUF_SHIFT 0
./scripts/config --disable PRINTK_INDEX
./scripts/config --disable X86_5LEVEL
./scripts/config --enable RETPOLINE
./scripts/config --disable AMD_MEM_ENCRYPT
./scripts/config --disable UTS_NS

# 3. 剥离大型子系统
./scripts/config --disable DRM
./scripts/config --disable SOUND
./scripts/config --disable ETHERNET
./scripts/config --disable HID
./scripts/config --disable INPUT
./scripts/config --disable KVM
./scripts/config --disable KVM_INTEL
./scripts/config --disable KVM_AMD
./scripts/config --disable PERF_EVENTS
./scripts/config --disable PROFILING
./scripts/config --disable BPF_SYSCALL
./scripts/config --disable AUDIT

# 4. 文件系统基础裁剪 (先关掉不需要的)
./scripts/config --disable DEBUG_FS
./scripts/config --disable BLK_DEBUG_FS
./scripts/config --disable STACKTRACE
./scripts/config --disable KALLSYMS_ALL
./scripts/config --disable FS_ENCRYPTION
./scripts/config --disable FS_ENCRYPTION_ALGS
./scripts/config --disable FS_VERITY
./scripts/config --disable AUTOFS_FS
./scripts/config --disable EFIVAR_FS
./scripts/config --disable CONFIGFS_FS
./scripts/config --disable FSNOTIFY
./scripts/config --disable QUOTA
./scripts/config --disable FUSE_FS
./scripts/config --disable VIRTIO_FS

# 批量关闭不常用文件系统
for fs in XFS_FS BTRFS_FS F2FS_FS JFS_FS REISERFS_FS NTFS_FS NTFS3_FS CIFS SMB_SERVER \
          NFS_FS GFS2_FS OCFS2_FS MINIX_FS HFS_FS HFSPLUS_FS ISO9660_FS UDF_FS \
          FAT_FS VFAT_FS MSDOS_FS SQUASHFS JOLIET ZISOFS; do
    ./scripts/config --disable $fs
done

# 5. 加密与压缩算法裁剪
./scripts/config --disable CRYPTO_TWOFISH
./scripts/config --disable CRYPTO_TWOFISH_COMMON
./scripts/config --disable CRYPTO_TWOFISH_X86_64
./scripts/config --disable CRYPTO_TWOFISH_X86_64_3WAY
./scripts/config --disable CRYPTO_TWOFISH_AVX_X86_64
./scripts/config --disable CRYPTO_AES_NI_INTEL
./scripts/config --disable CRYPTO_MANAGER
./scripts/config --disable ZSTD_COMPRESS
./scripts/config --disable ZSTD_DECOMPRESS
./scripts/config --disable RD_ZSTD

# 6. NLS 保持 (UTF-8 + 中文支持)
grep "CONFIG_NLS_" .config | grep "=y" | cut -d'=' -f1 | while read line; do
    ./scripts/config --disable "$line"
done
./scripts/config --enable CONFIG_NLS
./scripts/config --enable CONFIG_NLS_UTF8
./scripts/config --enable CONFIG_NLS_ASCII
./scripts/config --enable CONFIG_NLS_ISO8859_1
./scripts/config --enable CONFIG_NLS_CODEPAGE_936 
./scripts/config --set-str CONFIG_NLS_DEFAULT "utf8"
./scripts/config --enable CONFIG_NLS_UCS2_UTILS

# 7. 开启 DAX 与内存管理 (EROFS DAX 必备)
./scripts/config --enable FS_DAX
./scripts/config --enable FS_DAX_PMD
./scripts/config --enable DAX
./scripts/config --enable ZONE_DEVICE
./scripts/config --enable MEMORY_HOTPLUG
./scripts/config --enable MEMORY_HOTREMOVE

# 8. 开启设备驱动 (virtio-pmem 用于 Rootfs, virtio-blk 用于写层)
./scripts/config --enable VIRTIO_PMEM
./scripts/config --enable LIBNVDIMM
./scripts/config --enable BLK_DEV_PMEM
./scripts/config --enable VIRTIO_BLK

# 9. 开启 EROFS (只读 Rootfs 格式)
./scripts/config --enable EROFS_FS
./scripts/config --enable EROFS_FS_XATTR
./scripts/config --enable EROFS_FS_POSIX_ACL
./scripts/config --enable EROFS_FS_ZIP

# 10. 开启 OverlayFS
./scripts/config --enable OVERLAY_FS

# 11. 优化 Ext4 (写层专用)
./scripts/config --enable EXT4_FS
./scripts/config --disable EXT4_FS_POSIX_ACL
./scripts/config --disable EXT4_FS_SECURITY
./scripts/config --disable EXT4_DEBUG
./scripts/config --disable EXT4_KUNIT_TESTS

# 12. 应用配置并编译
make olddefconfig


if ! grep -q "CONFIG_EROFS_FS=y" .config; then
    echo "❌ 严重错误: 依赖冲突导致 EROFS 无法内置！"
    echo "当前冲突点可能在: $(grep -E "CONFIG_EROFS_FS|DAX|NETFS" .config)"
    exit 1
fi

make -j$(nproc) vmlinux

# 13. 成果展示
echo "------------------------------------------"
ls -lh vmlinux
echo "Top 10 Functions by Size:"
nm --size-sort -r vmlinux | head -n 10
echo "------------------------------------------"
echo "agent 专属内核构建完成！"

Docs: 启动

Wed, 15 Oct 2025 00:00:00 +0000

参考:

https://www.cloudhypervisor.org/docs/prologue/quick-start/#booting-linux

在 linux 上启动.

Cloud Hypervisor 支持直接内核启动（x86-64内核需使用支持PVH构建的内核）或通过固件/firmware启动（可选Rust Hypervisor固件或名为 CLOUDHV/CLOUDHV_EFI 的edk2 UEFI固件）。

最新版本的Rust Hypervisor固件及edk2存储库中均提供固件文件的二进制构建版本。

固件的选择取决于您的客户操作系统选项，可能需要进行一些实验性测试。

固件启动

Cloud Hypervisor 支持引导包含运行云工作负载所需全部组件的磁盘镜像，即云镜像。

准备工作

首先安装 qemu-utils,稍后要用到其中的 qemu-img 和 mkdosfs :

sudo apt install qemu-utils
sudo apt install dosfstools
sudo apt install mtools

以下示例命令将下载Ubuntu云镜像，将其转换为 Cloud Hypervisor 可用的格式，并生成引导该镜像所需的固件。

mkdir -p ~/work/soft/cloudhypervisor/fireware
cd ~/work/soft/cloudhypervisor/fireware

wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img

qemu-img convert -p -f qcow2 -O raw focal-server-cloudimg-amd64.img focal-server-cloudimg-amd64.raw

wget https://github.com/cloud-hypervisor/rust-hypervisor-firmware/releases/download/0.5.0/hypervisor-fw

处理完成后的文件列表:

$ ls -lh    

total 2.1G
-rw-rw-r-- 1 sky sky 618M Jun 25 09:39 focal-server-cloudimg-amd64.img
-rw-r--r-- 1 sky sky 2.2G Oct 16 16:54 focal-server-cloudimg-amd64.raw
-rw-rw-r-- 1 sky sky 133K Nov 30  2024 hypervisor-fw

Ubuntu云镜像默认不提供密码，因此首次启动时必须使用 cloud-init 磁盘镜像进行镜像定制。本脚本可生成基础 cloud-init 镜像，为镜像预设默认用户名/密码为 cloud/cloud123 。仅需在首次启动时添加此磁盘镜像即可。脚本同时通过 --net “mac=12:34:56:78:90:ab,tap=” 选项，基于 test_data/cloud-init/ubuntu/local/network-config 配置信息分配默认IP地址。随后系统将根据 network-config 详情启用匹配MAC地址的网络接口。

准备需要的脚本, 在代码仓库根目录下的 scripts 中:

https://github.com/cloud-hypervisor/cloud-hypervisor/tree/v48.0/scripts

后面还要使用到 test_data/cloud-init/ubuntu/ 目录下的文件, 因此最好是把整个代码仓库下载下来,方便后面使用

mkdir -p ~/work/code/cloud-hypervisor/
cd ~/work/code/cloud-hypervisor/

git clone https://github.com/cloud-hypervisor/cloud-hypervisor.git
cd cloud-hypervisor
git checkout v50.0

执行:

~/work/code/cloud-hypervisor/cloud-hypervisor/scripts/create-cloud-init.sh

输出如下:

+ rm -f /tmp/ubuntu-cloudinit.img
+ mkdosfs -n CIDATA -C /tmp/ubuntu-cloudinit.img 8192
mkfs.fat 4.2 (2021-01-31)
+ mcopy -oi /tmp/ubuntu-cloudinit.img -s test_data/cloud-init/ubuntu/local/user-data ::
+ mcopy -oi /tmp/ubuntu-cloudinit.img -s test_data/cloud-init/ubuntu/local/meta-data ::
+ mcopy -oi /tmp/ubuntu-cloudinit.img -s test_data/cloud-init/ubuntu/local/network-config ::

这会生成一个 ubuntu-cloudinit.img 文件,大小为 8M:

$ ls -lh /tmp/ubuntu-cloudinit.img
-rw-rw-r-- 1 sky sky 8.0M Oct 16 17:12 /tmp/ubuntu-cloudinit.img

注意这个目录是 /tmp,重启之后文件很可能就不在了,方便起见, 还是复制到

mkdir -p ~/work/soft/cloudhypervisor/images
mv /tmp/ubuntu-cloudinit.img /home/sky/work/soft/cloudhypervisor/images

启动

注意: 从 v49 版本开始需要设置 cloud-hypervisor 二进制的特权, 执行命令:

sudo setcap cap_net_admin+ep /home/sky/work/code/cloud-hypervisor/cloud-hypervisor/target/x86_64-unknown-linux-musl/release/cloud-hypervisor

否则后面启动时会报错:

cloud-hypervisor:   0.016376s: <main> ERROR:/home/sky/work/code/cloud-hypervisor/cloud-hypervisor/src/lib.rs:23 -- Fatal error: VmBoot(VmBoot(DeviceManager(CreateVirtioNet(OpenTap(TapOpen(ConfigureTap(Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" })))))))
Error: Cloud Hypervisor exited with the following chain of errors:
  0: Error booting VM
  1: The VM could not boot
  2: Error from device manager
  3: Cannot create virtio-net device
  4: Failed to open taps
  5: Open tap device failed
  6: Unable to configure tap interface
  7: Operation not permitted (os error 1)

注意启动命令中的路径要用绝对路径,不能用 ‘~/’ 之类,否则会报错无法找到文件.

/home/sky/work/code/cloud-hypervisor/cloud-hypervisor/target/x86_64-unknown-linux-musl/release/cloud-hypervisor \
	--kernel /home/sky/work/soft/cloudhypervisor/fireware/hypervisor-fw \
	--disk path=/home/sky/work/soft/cloudhypervisor/fireware/focal-server-cloudimg-amd64.raw path=/home/sky/work/soft/cloudhypervisor/images/ubuntu-cloudinit.img \
	--cpus boot=4 \
	--memory size=1024M \
	--net "tap=,mac=,ip=,mask="

输出为:

cloud-hypervisor: 481.142000µs: <main> WARN:vmm/src/vm_config.rs:356 -- Deprecation warning: No IP address provided. A default IP address is assigned. This behavior will be deprecated soon.
cloud-hypervisor: 506.863000µs: <main> WARN:vmm/src/vm_config.rs:363 -- Deprecation warning: No network mask provided. A default network mask is assigned. This behavior will be deprecated soon.

Ubuntu 20.04.6 LTS cloud hvc0

cloud login:

输入前面设置的用户/密码 (cloud / cloud123), 登录进去, 如果要退出,执行 sudo shutdown now 命令关闭启动的 microVM 即可.

此时因为没有配置好网络, 所以登录进去 microVM 后会发现没有网络可用.

配置microVM的网络

没成功,等下继续.

首先要在主机上创建并配置 TAP 接口:

sudo ip tuntap add name vm-tap0 mode tap user $(whoami) 
sudo ip link set vm-tap0 up
sudo ip addr add 192.168.1.127/24 dev vm-tap0

此时在主机上看到的 vm-tap0 设备为:

$ ip addr
......

10: vm-tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 3e:7b:2e:ca:9a:3e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.127/24 scope global vm-tap0
       valid_lft forever preferred_lft forever

注意：上面的 ip 命令在重启后会失效。若需持久化配置，可将其写入主机的网络配置文件（如 /etc/network/interfaces 或使用 systemd-networkd/NetworkManager)。

注意2: 如果配置有问题,可以先删除,再重新配置. sudo ip link delete vm-tap0

/home/sky/work/code/cloud-hypervisor/cloud-hypervisor/target/x86_64-unknown-linux-musl/release/cloud-hypervisor \
	--kernel /home/sky/work/soft/cloudhypervisor/fireware/hypervisor-fw \
	--disk path=/home/sky/work/soft/cloudhypervisor/fireware/focal-server-cloudimg-amd64.raw path=/tmp/ubuntu-cloudinit.img \
	--cpus boot=4 \
	--memory size=1024M \
	--net "tap=vm-tap0,mac=12:34:56:78:90:22,ip=192.168.1.129,mask=255.255.255.0"


/home/sky/work/code/cloud-hypervisor/cloud-hypervisor/target/x86_64-unknown-linux-musl/release/cloud-hypervisor \
	--kernel /home/sky/work/soft/cloudhypervisor/fireware/hypervisor-fw \
	--disk path=/home/sky/work/soft/cloudhypervisor/fireware/focal-server-cloudimg-amd64.raw path=/home/sky/work/soft/cloudhypervisor/images/ubuntu-cloudinit.img \
	--cpus boot=4 \
	--memory size=1024M \
	--net "tap=tap0,mac=12:34:56:78:90:22,ip=192.168.1.10,mask=255.255.255.0"

镜像启动

Cloud Hypervisor 也支持直接内核启动。对于 x86-64 架构，需要一个 vmlinux ELF 内核（编译时包含 PVH 支持）。为了支持开发，有一个自定义分支；不过只要所需选项已启用，任何近期的内核都可以使用。

构建 linux 内核

要构建内核：

cd ~/work/code/cloud-hypervisor/

git clone --depth 1 https://github.com/cloud-hypervisor/linux.git -b ch-6.12.8 linux-cloud-hypervisor
cd linux-cloud-hypervisor
make ch_defconfig

sudo apt install libelf-dev
sudo apt install bc

注意要执行 sudo apt install libelf-dev 命令安装 libelf,否则会报错:

<stdin>:1:10: fatal error: libelf.h: No such file or directory

构建 x86-64 kernel:

KCFLAGS="-Wa,-mx86-used-note=no" make bzImage -j `nproc`

构建完成后,linux 内核保存在 ./arch/x86/boot/compressed/vmlinux.bin,大小为 45M:

$ ls -lh ./arch/x86/boot/compressed/vmlinux.bin
-rwxrwxr-x 1 sky sky 45M Nov 18 15:50 ./arch/x86/boot/compressed/vmlinux.bin

rootfs 磁盘镜像可以用之前下载的 ubuntu 镜像, 之前存放在目录 ~/work/soft/cloudhypervisor/fireware 下

也可以再次下载和转换:

cd ~/work/soft/cloudhypervisor/fireware

wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img # x86-64
wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-arm64.img # AArch64
qemu-img convert -p -f qcow2 -O raw focal-server-cloudimg-amd64.img focal-server-cloudimg-amd64.raw # x86-64
qemu-img convert -p -f qcow2 -O raw focal-server-cloudimg-arm64.img focal-server-cloudimg-arm64.raw # AArch64

启动 vm:

/home/sky/work/code/cloud-hypervisor/cloud-hypervisor/target/x86_64-unknown-linux-musl/release/cloud-hypervisor \
	--kernel /home/sky/work/code/cloud-hypervisor/linux-cloud-hypervisor/arch/x86/boot/compressed/vmlinux.bin \
	--console off \
	--serial tty \
	--disk path=/home/sky/work/soft/cloudhypervisor/fireware/focal-server-cloudimg-amd64.raw \
	--cmdline "console=ttyS0 root=/dev/vda1 rw" \
	--cpus boot=4 \
	--memory size=1024M \
	--net "tap=,mac=,ip=,mask="

Features: 优化性能

Wed, 15 Oct 2025 00:00:00 +0000

准备工作

准备目录和文件

继续使用之前的 work/test/cloudhypervisor 目录：

cd /home/sky/work/test/cloudhypervisor

启动

冷启动虚拟机，用于制作快照，注意修改内容大小设置：

sudo /home/sky/work/soft/cloudhypervisor/bin/cloud-hypervisor \
    --api-socket /home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock \
    --cpus boot=1,nested=off \
    --memory size=512M \
    --kernel /home/sky/work/test/cloudhypervisor/vmlinux.bin \
    --cmdline "root=/dev/vda1 rw quiet 8250.nr_uarts=0" \
    --disk path=/home/sky/work/test/cloudhypervisor/ubuntu-cloud-image/rootfs.raw \
    --console off \
    --serial off \
    --log-file /dev/null

制作快照

根据前面设置的内存大小，制作快照，保存在不同的目录下，备用：

rm -rf /home/sky/work/test/cloudhypervisor/snapshot-4g
mkdir -p /home/sky/work/test/cloudhypervisor/snapshot-4g
sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock pause
sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock  snapshot file:///home/sky/work/test/cloudhypervisor/snapshot-4g
sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock  resume
sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock  shutdown
sudo fuser -k -TERM /home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock

重复以上操作，可以分别制作出 512M/1G/2G/4G 的快照文件，用于后面的恢复操作。

恢复虚拟机

执行恢复虚拟机的命令，注意选择快照文件的来源目录，其实就是选择不同的内存规格：

sudo /home/sky/work/soft/cloudhypervisor/bin/cloud-hypervisor \
    --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock \
    --restore source_url=file:///home/sky/work/test/cloudhypervisor/snapshot-4g

恢复之后，虚拟机是处于 pause 状态的，因此还要执行 resume 才能唤醒到正常运行状态：

sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock  resume

恢复性能测试

默认

使用脚本 test_restore_speed.sh 进行测试，执行前修改脚本中的这一行，指定要使用的不同内存规格的快照文件：

SNAPSHOT_URL="file:///home/sky/work/test/cloudhypervisor/snapshot-512m"

执行前强制清理 page cache：

./test_restore_speed.sh false

多次测试的结果汇总为：

====== 开始性能测试 (Cache: false Size=4G) ======

 1. Load (Disk -> RAM)     :   1913.322 ms
 2. Resume (CPU Active)    :     16.584 ms
 --------------------------------------------------
 3. Total Recovery         :   1929.907 ms

====== 开始性能测试 (Cache: false Size=2G) ======

 1. Load (Disk -> RAM)     :    985.878 ms
 2. Resume (CPU Active)    :     14.172 ms
 --------------------------------------------------
 3. Total Recovery         :   1000.050 ms

====== 开始性能测试 (Cache: false Size=1G) ======

 1. Load (Disk -> RAM)     :    533.121 ms
 2. Resume (CPU Active)    :     15.142 ms
 --------------------------------------------------
 3. Total Recovery         :    548.263 ms

====== 开始性能测试 (Cache: false Size=512M) ======

 1. Load (Disk -> RAM)     :    304.199 ms
 2. Resume (CPU Active)    :     15.110 ms
 --------------------------------------------------
 3. Total Recovery         :    319.310 ms

page cache优化

类似的，不过执行前执行 page cache 优化：

./test_restore_speed.sh true

====== 开始性能测试 (Cache: true Size=4G) ======

 1. Load (Disk -> RAM)     :    623.998 ms
 2. Resume (CPU Active)    :     14.062 ms
 --------------------------------------------------
 3. Total Recovery         :    638.060 ms

====== 开始性能测试 (Cache: true Size=2G) ======

 1. Load (Disk -> RAM)     :    333.440 ms
 2. Resume (CPU Active)    :     17.197 ms
 --------------------------------------------------
 3. Total Recovery         :    350.637 ms

====== 开始性能测试 (Cache: true Size=1G) ======

 1. Load (Disk -> RAM)     :    190.534 ms
 2. Resume (CPU Active)    :     16.542 ms
 --------------------------------------------------
 3. Total Recovery         :    207.076 ms

====== 开始性能测试 (Cache: true Size=512M ======

 1. Load (Disk -> RAM)     :    105.908 ms
 2. Resume (CPU Active)    :     16.547 ms
 --------------------------------------------------
 3. Total Recovery         :    122.456 ms

HugePages 优化

类似，但是在启动虚拟机时设置内存为 hugepages=on：

sudo /home/sky/work/soft/cloudhypervisor/bin/cloud-hypervisor \
    --api-socket /home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock \
    --cpus boot=1,nested=off \
    --memory size=1G,hugepages=on \
    --kernel /home/sky/work/test/cloudhypervisor/vmlinux.bin \
    --cmdline "root=/dev/vda1 rw quiet 8250.nr_uarts=0" \
    --disk path=/home/sky/work/test/cloudhypervisor/ubuntu-cloud-image/rootfs.raw \
    --console off \
    --serial off \
    --log-file /dev/null

同样制作快照，为了和之前 hugepages=off 的快照区分，存放在不同的目录，以后缀 -hugepage 为标志：

rm -rf /home/sky/work/test/cloudhypervisor/snapshot-1g-hugepage
mkdir -p /home/sky/work/test/cloudhypervisor/snapshot-1g-hugepage
sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock pause
sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock  snapshot file:///home/sky/work/test/cloudhypervisor/snapshot-1g-hugepage
sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock  resume
sudo /home/sky/work/soft/cloudhypervisor/bin/ch-remote --api-socket=/home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock  shutdown
sudo fuser -k -TERM /home/sky/work/test/cloudhypervisor/cloud-hypervisor.sock

继续测试，开启 hugepage + 不开启 page cache 基本没差别：

====== 开始性能测试 (Cache: false Size=4G) ======

 1. Load (Disk -> RAM)     :   1906.534 ms
 2. Resume (CPU Active)    :     15.309 ms
 --------------------------------------------------
 3. Total Recovery         :   1921.843 ms

====== 开始性能测试 (Cache: false Size=2G) ======

 1. Load (Disk -> RAM)     :    985.883 ms
 2. Resume (CPU Active)    :     13.876 ms
 --------------------------------------------------
 3. Total Recovery         :    999.759 ms

====== 开始性能测试 (Cache: false Size=1G) ======

 1. Load (Disk -> RAM)     :    521.281 ms
 2. Resume (CPU Active)    :     14.697 ms
 --------------------------------------------------
 3. Total Recovery         :    535.978 ms

====== 开始性能测试 (Cache: false Size=512M) ======

 1. Load (Disk -> RAM)     :    300.310 ms
 2. Resume (CPU Active)    :     15.617 ms
 --------------------------------------------------
 3. Total Recovery         :    315.927 ms

开启 hugepage + 开启 page cache 能快一点：

====== 开始性能测试 (Cache: true Size=4G) ======

 1. Load (Disk -> RAM)     :    526.327 ms
 2. Resume (CPU Active)    :     15.826 ms
 --------------------------------------------------
 3. Total Recovery         :    542.153 ms

====== 开始性能测试 (Cache: true Size=2G) ======

 1. Load (Disk -> RAM)     :    312.838 ms
 2. Resume (CPU Active)    :     15.331 ms
 --------------------------------------------------
 3. Total Recovery         :    328.169 ms

====== 开始性能测试 (Cache: true Size=1G) ======

 1. Load (Disk -> RAM)     :    153.869 ms
 2. Resume (CPU Active)    :     16.558 ms
 --------------------------------------------------
 3. Total Recovery         :    170.427 ms

====== 开始性能测试 (Cache: true Size=512M ======

 1. Load (Disk -> RAM)     :    102.818 ms
 2. Resume (CPU Active)    :     15.310 ms
 --------------------------------------------------
 3. Total Recovery         :    118.128 ms

性能对比分析

将上面测试的几组数据汇总，对比一下：

内存规格	操作	默认（强制清理page cache）	开启 page cache	不开启 page cache + 开启 hugepage	开启 page cache + 开启 hugepage
4G	restore	1913.322 ms	623.998 ms	1906.534 ms	526.327 ms
	resume	16.584 ms	14.062 ms	15.309 ms	15.826 ms
	total	1929.907 ms	638.060 ms	1921.843 ms	542.153 ms
2G	restore	985.878 ms	333.440 ms	985.883 ms	312.838 ms
	resume	14.172 ms	17.197 ms	13.876 ms	15.331 ms
	total	1000.050 ms	350.637 ms	999.759 ms	328.169 ms
1G	restore	533.121 ms	190.534 ms	521.281 ms	153.869 ms
	resume	15.142 ms	16.542 ms	14.697 ms	16.558 ms
	total	548.263 ms	207.076 ms	535.978 ms	170.427 ms
512M	restore	304.199 ms	105.908 ms	300.310 ms	102.818 ms
	resume	15.110 ms	16.547 ms	15.617 ms	15.310 ms
	total	319.310 ms	122.456 ms	315.927 ms	118.128 ms

分析：

resume 操作的时间非常固定，稳定在 15 毫秒左右，不受内存规格和各种优化策略的影响
restore 操作和内存规格影响非常大，基本呈现线性
开启 page cache 能极大的加速 restore 的速度，但也只能加速到 30% 左右，不能直接到非常小，而且也是和内存规格直接相关（几乎也是线性）
开启 hugepage 能再次加速 restore 的速度，但很有限。

结论：

restore 操作的确是在读取和操作完整的内存快照文件，并没有跳过空闲内存

Optimize: 去除固件

Mon, 01 Dec 2025 00:00:00 +0000

去除固件 (Direct Kernel Boot):

方案： Cloud Hypervisor 支持直接加载 Linux Kernel (vmlinux)，跳过 BIOS/UEFI 阶段。

效果：既加快了启动速度，又节省了用于模拟固件的内存开销。

Practices: 在腾讯Agent Runtime的落地实践

Sun, 23 Nov 2025 00:00:00 +0000

公开资料

听说，Agent都在找这个“箱子”: 2025-12-15
腾讯云推出“龙虾”密钥沙箱：给权限，不给密钥: 2026年03月18日, 宣传文稿
Agent 沙箱服务 - 快速入门: 2025-11-19，官方文档，展示了腾讯云沙箱如何完美兼容国际主流的 E2B (e2b-code-interpreter) 协议栈
腾讯云函数计算冷启动优化实践腾讯云Agent Runtime 执行引擎开放内测！专为 Agent 而生、超安全、极致弹性的Serverless AI 运行时: 22025-09-29

Optimize: CoW

Sun, 23 Nov 2025 00:00:00 +0000

对只读镜像采用共享基础镜像 + 写时复制（CoW），减少磁盘占用。

Practices: Northflank介绍

Sun, 23 Nov 2025 00:00:00 +0000

https://northflank.com/

Northflank 在业界以提供极其安全、可扩展的计算沙箱而闻名，尤其是在当前的 AI Agent 时代，他们利用 Cloud Hypervisor 处理了海量的“不可信代码执行”任务。

以下是关于 Northflank 及其在 Cloud Hypervisor 上实践的详细资料梳理：

1. Northflank 是什么？

Northflank 是一个全栈的云原生 PaaS（平台即服务）平台，类似于国外的 Heroku、Vercel 或 Render。它的核心优势在于：允许开发者通过 UI、API、CLI 或 GitOps 极速部署容器、数据库、API 和后台任务。近年来，随着大模型（LLM）的爆发，Northflank 演变成为了顶级的**“不可信代码执行沙箱（Untrusted Code Execution）”**平台。每月在生产环境中运行超过 200 万个 MicroVM，为许多 AI 初创公司和企业提供多租户隔离的底层基建。

2. Northflank 在 Cloud Hypervisor 上的深度实践

Northflank 并没有选择自己从头造轮子，也没有单一依赖 AWS 的 Firecracker，而是构建了一个极具弹性的底层调度架构：

A. 核心架构：Kata Containers + Cloud Hypervisor

首选 VMM：Northflank 将 Cloud Hypervisor 作为其微虚拟机隔离的首选/主要 VMM（虚拟机监视器）。
结合 Kubernetes：他们使用 Kata Containers 将 Cloud Hypervisor 融入到 Kubernetes 集群中。在用户看来，他们只是上传了一个标准的 Docker (OCI) 镜像；但在底层，Northflank 使用 Kata Containers 调用 Cloud Hypervisor，在 ~200毫秒内为这个容器拉起一个拥有独立内核的微虚拟机（MicroVM）。
为什么选 Cloud Hypervisor？ 根据其官方博客透露，相比于极其精简但功能受限的 Firecracker（启动 ~125ms），Cloud Hypervisor（启动 ~200ms）虽然慢了几十毫秒，但提供了企业级生产环境必须的关键特性：CPU 和内存的热插拔（Hotplugging）、vhost-user 设备支持、以及更广泛的硬件兼容性。同时，它同样基于 Rust 编写，具备极高的内存安全性。

B. 智能回退机制 (Fallback Strategy)

并非所有的云环境都支持嵌套虚拟化（Nested Virtualization）来运行硬件级虚拟机。Northflank 采用了一套智能调度策略：

在支持嵌套虚拟化的环境（如裸金属或特定的云主机），运行 Kata + Cloud Hypervisor（或 Firecracker）提供最强的硬件级隔离。
如果底层不支持硬件虚拟化，则自动无缝回退到使用 Google 的 gVisor 提供系统调用（Syscall）级别的用户态隔离。

C. 开源社区贡献

Northflank 的工程团队不仅是使用者，还是积极的社区贡献者。他们向上游的 Kata Containers、Cloud Hypervisor、QEMU 和 containerd 提交代码，以确保他们依赖的隔离层得到持续的维护和优化。

3. 主要的应用场景

AI Agent 代码执行沙箱：当 AI Agent 需要自己写代码并执行以完成任务时，Northflank 利用 Cloud Hypervisor 秒级拉起沙箱，确保 AI 生成的恶意代码或死循环绝对无法穿透沙箱影响宿主机。
BYOC (自带云部署)：Northflank 允许企业客户将其调度引擎部署在客户自己的 AWS、GCP 或裸机机房内（Bring Your Own Cloud）。这意味着客户可以在自己的私有 VPC 内，利用 Cloud Hypervisor 享受极速的 MicroVM 隔离体验，无需自己搭建复杂的虚拟化底层。

备注：这家公司的 blog 上有不少写的不错的介绍文章。

Optimize: DAX机制的功能和实现

Sat, 15 Nov 2025 00:00:00 +0000

https://www.cnblogs.com/dream397/p/13900936.html

https://blog.csdn.net/maokelong95/article/details/107195192

DAX 简述

直接访问（Direct Access，DAX）机制是一种支持用户态软件直接访问存储于持久内存（Persistent Memory，PM）的文件的机制，用户态软件无需先将文件数据拷贝到页高速缓存（Page Cache）。

上述描述对应到下面这张图（Typical NVDIMM Software Architecture）中，就是说（File）和（Memory）这两条 IO 路径都能绕过页高速缓存。

其中 File 路径（下称普通文件路径）表示，用户态软件通过标准文件接口（Standard File API）访问持久内存文件系统。
其中 Memory 路径（下称映射文件路径）表示，用户态软件通过映射文件（Memory-mapped File）直接访问 PM。

DAX 的原理

以下将结合 Linux v5.8-rc1 中的 XFS 为例进行介绍。

普通文件路径如何旁路页缓存

以文件写路径为例，其由 xfs_file_write_iter 提供，该函数部分代码如下所示：

STATIC ssize_t
xfs_file_write_iter(
	struct kiocb		*iocb,
	struct iov_iter		*from)
{
	struct file		*file = iocb->ki_filp;
	struct address_space	*mapping = file->f_mapping;
	struct inode		*inode = mapping->host;
	ssize_t			ret;

	if (IS_DAX(inode))
		return xfs_file_dax_write(iocb, from);

	if (iocb->ki_flags & IOCB_DIRECT) {
		ret = xfs_file_dio_aio_write(iocb, from);
		if (ret != -EREMCHG)
			return ret;
	}

	return xfs_file_buffered_aio_write(iocb, from);
}

这段代码在执行写操作的时候，将分别处理三种情况：

DAX
- 在将文件系统挂载到 PM 设备时，若设置 DAX 标识（mount -o dax），则持久内存文件系统将为所有写操作采用该路径；
- 该路径主要调用 dax_iomap_rw。该函数在通过 dax_direct_access 获取目标物理内存的地址后，通过 dax_copy_from_iter 调用 NVDIMM 驱动直接把数据拷贝到目标物理内存中，并冲洗（Flush）相应缓存行（Cache Line）。
DIO（Direct IO）：
- 在打开文件时，若设置直接 IO 标识（O_DIRECT），则文件操作将采用该路径；
- 该路径主要调用 iomap_dio_rw。该函数仍通过传统存储栈（Storage Stack）访问设备，即通过构造 bio，将请求传递到块设备层（Block Device Layer），再由块设备层调用驱动从而访问设备。
正常 IO：
- 常规的、使用页缓存的 IO 方式。
- 该路径主要调用 iomap_file_buffered_write。该函数首先通过 pagecache_get_page 获取页缓存（有关页缓存机制的最新设计，可阅读3 4 5），接着通过 iomap_read_page_sync 封装 bio，以请求块设备层调用驱动，将设备上的数据读取到页缓存中。在准备好页缓存之后，调用 iov_iter_copy_from_user_atomic 将用户态软件请求写入的数据拷贝到页缓存中。一切完成之后，通过 iomap_set_page_dirty 将页缓存设置为脏页。如此迭代，直至用户所有数据都写入页缓存，最后通过 balance_dirty_pages_ratelimited 酌情使用后台进程将脏页回写到块设备中。

映射文件路径如何旁路页缓存

调用 mmap 时，文件系统仅仅在进程的 mm_struct 中注册了一段使用虚拟内存区域（Virtual Memory Area，VMA）描述的虚拟地址。后续当用户态软件首次访问映射文件时，内存管理单元（Memory Managment Unit）发现页表项（Page Table Entry,PTE）为空，于是触发 14 号故障，即页故障（Page Fault），使得操作系统开始执行请求调页（Demand Paging）。此时，由虚拟内存管理器（Virtual Memory Manager）和文件系统共同管理页表，以建立虚拟内存到物理内存之间的映射关系。注意，以上为同步过程，而非异步过程，因为页故障是一个异常（Exception）而非软/硬件中断（Software/Hardware Interrupt）。

调用 mmap 时发生了什么

在执行 mmap 系统调用时，主要执行 do_mmap 中的 mmap_region，其根据用户态软件的请求，返回一个用于描述一段可用进程虚拟地址空间的 VMA，接着通过 call_mmap 执行文件系统注册的 mmap 实现，最后将该段 VMA 之添加在进程的 mm_struct 中。

XFS 中 mmap 由 xfs_file_mmap 实现，其中主要语句就一个：vma->vm_ops = &xfs_file_vm_ops;。它告诉异常处理例程（Exception Handler）应该调用 xfs_file_vm_ops 中相应的函数处理页错误。

请求调页时发生了什么

请求调页主要执行 __xfs_filemap_fault，其代码如下所示：

static vm_fault_t
__xfs_filemap_fault(
	struct vm_fault		*vmf,
	enum page_entry_size	pe_size,
	bool			write_fault)
{
	struct inode		*inode = file_inode(vmf->vma->vm_file);
	struct xfs_inode	*ip = XFS_I(inode);
	vm_fault_t		ret;

	trace_xfs_filemap_fault(ip, pe_size, write_fault);

	if (write_fault) {
		sb_start_pagefault(inode->i_sb);
		file_update_time(vmf->vma->vm_file);
	}

	xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
	if (IS_DAX(inode)) {
		pfn_t pfn;

		ret = dax_iomap_fault(vmf, pe_size, &pfn, NULL,
				(write_fault && !vmf->cow_page) ?
				 &xfs_direct_write_iomap_ops :
				 &xfs_read_iomap_ops);
		if (ret & VM_FAULT_NEEDDSYNC)
			ret = dax_finish_sync_fault(vmf, pe_size, pfn);
	} else {
		if (write_fault)
			ret = iomap_page_mkwrite(vmf,
					&xfs_buffered_write_iomap_ops);
		else
			ret = filemap_fault(vmf);
	}
	xfs_iunlock(XFS_I(inode), XFS_MMAPLOCK_SHARED);

	if (write_fault)
		sb_end_pagefault(inode->i_sb);
	return ret;
}

显然，这段代码有两条分支：

DAX：该路径主要调用 dax_iomap_fault。该函数首先通过 grab_mapping_entry 获取页缓存中的 DAX Exception Entry（详见3），接着通过 xfs_bmbt_to_iomap 准备一个名为 struct iomap 的数据结构。
```
struct iomap {
	u64			addr; /* disk offset of mapping, bytes */
	loff_t			offset;	/* file offset of mapping, bytes */
	u64			length;	/* length of mapping, bytes */
	u16			type;	/* type of mapping */
	u16			flags;	/* flags for mapping */
	struct block_device	*bdev;	/* block device for I/O */
	struct dax_device	*dax_dev; /* dax_dev for dax operations */
	void			*inline_data;
	void			*private; /* filesystem private */
	const struct iomap_page_ops *page_ops;
};
```
准备好 struct iomap 之后，通过 dax_iomap_pfn ，结合 struct iomap 所提供的信息，获取目标 PM 页的物理页号（Physical Page Number，pfn）。之后由 dax_insert_entry 将与该页相关联的 DAX Exception Entry 添加到用于维护页缓存的数据结构 XArray 中。最后调用 vmf_insert_mixed_mkwrite 将从 DAX Exception Entry 中缓存的 pfn 填写到对应虚拟页的 PTE 中。
正常请求调页

该路径主要调用 filemap_fault。该函数首先通过 do_sync_mmap_readahead 试图同步地预读文件数据（预读行为可受 madvise 系统调用的影响，因此也可能完全不读取），接着通过 pagecache_get_page 分配页缓存，再通过 xfs_vm_readpage 将读取块设备数据的请求发送到块设备层，从而将文件数据读取到页缓存中。在将文件数据拷贝到页缓存之后，取决于映射文件的类型（MAP_SHARED、MAP_PRIVATE）执行不同的分支。最后返回的页保存在 vmf->page 中。
- 当是 MAP_SHARED，主要调用 do_shared_fault 函数，该函数：
  1. 调用 xfs_file_vm_ops 中注册的 xfs_filemap_page_mkwrite，从而调用 iomap_page_create 在 vmf->page 对应的 struct page 的 private 字段中塞进去一个 struct iomap_page。
```
/*
* Structure allocated for each page when block size < PAGE_SIZE to track
* sub-page uptodate status and I/O completions.
*/
struct iomap_page {
	atomic_t		read_count;
	atomic_t		write_count;
	spinlock_t		uptodate_lock;
	DECLARE_BITMAP(uptodate, PAGE_SIZE / 512);
};
```
  finish_fault
  
  alloc_set_pte
  
  信息以支持空闲页回收。
- 当是 MAP_PRIVATE，调用 do_cow_fault。该函数首先通过 alloc_page_vma 为 VMA 分配一个页，该页保存在 vmf->cow_page 中。接着通过 copy_user_highpage 将 vmf->page 中的数据拷贝到 vmf->cow_page 中。最后通过 finish_fault 将 vmf->cow_page 映射到虚拟页上。

附录 1：术语表

持久内存（Persistent Memory，PM）：指能通过访存指令（区别于系统调用）访问、可按字节寻址的（区别于块）非易失存储器（Non-volatile Memory，NVM）。其中可按字节寻址（Byte-addressable）表示每个寻址单位对应一个 PM 单元（而非字或块）。
持久内存系统（PM-aware File System）：指支持 DAX 机制的文件系统。该词的常见表述也包括「Persistent Memory File System」、「DAX Enabled File System」。
映射文件（Memory-mapped File）：是一段虚内存逐字节对应于一个文件或类文件的资源，使得应用程序处理映射部分如同访问主内存。进程地址空间由映射文件和匿名内存（Anonymous Memory）组成。

附录 2：DAX 历史沿革

2015，Carsten Otte 在 Linux v2.6 中引入 XIP（Execute-in-place）机制。 XIP 原本用于嵌入式系统，它摒弃了存储栈中的通用块层及驱动层，并旁路了页高速缓存，使得进程可以直接访问只读存储器或基于 Flash 的内存。
2014 年，Subramanya R Dulloor 等人在 PMFS 中基于 XIP 机制管理 PM。
同年，Matthew Wilcox 改进了 XIP 并提出了名为 DAX 的子系统。他在尝试将 XIP 集成到 Ext4 文件系统时，发现 XIP 无法很好地应对竞争条件（Race Conditions）。当多个线程需要同时访问共享资源，且结果依赖于它们执行的相对速度时，便出现了竞争条件。他所做出的最主要的变动，就是使用文件系统的 get_block 路径替代 struct address_space_operations 中的 get_xip_mem操作。

Docs: 命令

Sat, 15 Nov 2025 00:00:00 +0000

参考:

https://www.cloudhypervisor.org/docs/prologue/commands/

cloud-hypervisor

通过 help 命令可以得到参数和参数说明:

cloud-hypervisor --help

--api-socket <api-socket>

HTTP API socket (UNIX domain socket): path=</path/to/a/file> or fd=<fd>
--balloon <balloon>

Balloon parameters

“size=<balloon_size>,deflate_on_oom=on|off”
--cmdline <cmdline>

Kernel command line
--console <console>

Control (virtio) console: “off|null|pty|tty|file=</path/to/a/file>,iommu=on|off”

[default: tty]
--cpus <cpus>

boot=<boot_vcpus>,max=<max_vcpus>,topology=<threads_per_core>:<cores_per_die>:<dies_per_package>:<packages>,kvm_hyperv=on

[default: boot=1,max_phys_bits=46]
--debug-console <debug-console>

off|pty|tty|file=</path/to/a/file>,iobase=<port in hex>

[default:off,iobase=0xe9]
--device <device>...

Direct device assignment parameters

“path=<device_path>,iommu=on|off,id=<device_id>,pci_segment=<segment_id>”
--disk <disk>...

Disk parameters

“path=<disk_image_path>,readonly=on|off,direct=on|off,iommu=on|off,num_queues=<number_of_queues>,queue_size=<size_of_each_queue>,vhost_user=on|off,socket=<vhost_user_socket_path>,bw_size=,bw_one_time_burst=,bw_refill_time=,ops_size=<io_ops>,ops_one_time_burst=<io_ops>,ops_refill_time=,id=<device_id>,pci_segment=<segment_id>,rate_limit_group=<group_id>,queue_affinity=<list_of_queue_indices_with_their_associated_cpuset>,serial=<serial_number>”
--event-monitor <event-monitor>

File to report events on: path=</path/to/a/file> or fd=<fd>
--firmware <firmware>

File to report events on: path=</path/to/a/file> or fd=<fd>
--fs <fs>...

virtio-fs parameters “tag=<tag_name>,socket=<socket_path>,num_queues=<number_of_queues>,queue_size=<size_of_each_queue>,id=<device_id>,pci_segment=<segment_id>”
--initramfs <initramfs>

Path to initramfs image
--kernel <kernel>

Path to kernel to load. This may be a kernel or firmware that supports a PVH entry point (e.g. vmlinux) or architecture equivalent
--landlock

enable/disable Landlock.
--landlock-rules <landlock-rules>...

Landlock parameters “path=<path/to/{file/dir}>,access=[rw]”
--log-file <log-file>

Log file. Standard error is used if not specified
--memory <memory>

“size=<guest_memory_size>,mergeable=on|off,shared=on|off,hugepages=on|off,hugepage_size=<hugepage_size>,hotplug_method=acpi|virtio-mem,hotplug_size=<hotpluggable_memory_size>,hotplugged_size=<hotplugged_memory_size>,prefault=on|off,thp=on|off”

[default: size=512M]
--memory-zone <memory-zone>...

User defined memory zone parameters

“size=<guest_memory_region_size>, file=<backing_file>, shared=on|off, hugepages=on|off, hugepage_size=<hugepage_size>, host_numa_node=<node_id>, id=<zone_identifier>, hotplug_size=<hotpluggable_memory_size>, hotplugged_size=<hotplugged_memory_size>, prefault=on|off”
--net <net>...

Network parameters

“tap=<if_name>,ip=<ip_addr>,mask=<net_mask>,mac=<mac_addr>,fd=<fd1,fd2…>,iommu=on|off,num_queues=<number_of_queues>,queue_size=<size_of_each_queue>,id=<device_id>, vhost_user=<vhost_user_enable>, socket=<vhost_user_socket_path>, vhost_mode=client|server, bw_size=,bw_one_time_burst=, bw_refill_time=, ops_size=<io_ops>, ops_one_time_burst=<io_ops>, ops_refill_time=, pci_segment=<segment_id>offload_tso=on|off, offload_ufo=on|off, offload_csum=on|off”
--numa <numa>...

Settings related to a given NUMA node

“guest_numa_id=<node_id>, cpus=<cpus_id>, distances=<list_of_distances_to_destination_nodes>, memory_zones=<list_of_memory_zones>, pci_segments=<list_of_pci_segments>”
--pci-segment <pci-segment>...

PCI Segment parameters

“pci_segment=<segment_id>, mmio32_aperture_weight=, mmio64_aperture_weight=”
--platform <platform>

num_pci_segments=<num_pci_segments>, iommu_segments=<list_of_segments>, iommu_address_width=<bits>, serial_number=<dmi_device_serial_number>, uuid=<dmi_device_uuid>, oem_strings=<list_of_strings>
--pmem <pmem>...

Persistent memory parameters

“file=<backing_file_path>,size=<persistent_memory_size>,iommu=on|off,discard_writes=on|off,id=<device_id>,pci_segment=<segment_id>”
--pvpanic

Enable pvpanic device
--rate-limit-group <rate-limit-group>...

Rate Limit Group parameters

"bw_size=<bytes>, bw_one_time_burst=<bytes>, bw_refill_time=<ms>, ops_size=<io_ops>, ops_one_time_burst=<io_ops>, ops_refill_time=<ms>, id=<device_id>"
--restore <restore>

Restore from a VM snapshot.

Restore parameters

"source_url=<source_url>, prefault=on|off, net_fds=<list_of_net_ids_with_their_associated_fds>"

source_url should be a valid URL (e.g file:///foo/bar or tcp://192.168.1.10/foo)

prefault brings memory pages in when enabled (disabled by default)

net_fds is a list of net ids with new file descriptors. Only net devices backed by FDs directly are needed as input.
--rng <rng>

Random number generator parameters “src=<entropy_source_path>,iommu=on|off”

[default: src=https://skyao.net/learning-cloud-hypervisor/dev/urandom]
--seccomp <seccomp>

[default: true] [possible values: true, false, log]
--serial <serial>

Control serial port: off|null|pty|tty|file=</path/to/a/file>|socket=</path/to/a/file>

[default: null]
--tpm <tpm>

TPM device “(UNIX Domain Socket from swtpm) socket=</path/to/a/socket>”
--user-device <user-device>...

Userspace device socket=<socket_path>,id=<device_id>,pci_segment=<segment_id>
-v...

Sets the level of debugging output
--vdpa <vdpa>...

vDPA device

“path=<device_path>,num_queues=<number_of_queues>,iommu=on|off,id=<device_id>,pci_segment=<segment_id>”
-V, --version

Print version
--vsock <vsock>

Virtio VSOCK parameters

“cid=<context_id>, socket=<socket_path>, iommu=on|off, id=<device_id>, pci_segment=<segment_id>”
--watchdog

Enable virtio-watchdog
-h, --help

Print help

ch-remote

通过 help 命令可以得到参数和参数说明:

ch-remote --help

命令	命令描述
add-device	Add VFIO device
add-disk	Add block device
add-fs	Add virtio-fs backed fs device
add-net	Add network device
add-pmem	Add persistent memory device
add-user-device	Add userspace device
add-vdpa	Add vDPA device
add-vsock	Add vsock device
boot	Boot a created VM
coredump	Create a coredump from VM
counters	Counters from the VM
create	Create VM from a JSON configuration
delete	Delete a VM
info	Info on the VM
nmi	Trigger NMI
pause	Pause the VM
ping	Ping the VMM to check for API server availability
power-button	Trigger a power button in the VM
reboot	Reboot the VM
receive-migration	Receive a VM migration
remove-device	Remove VFIO and PCI device
resize	Resize the VM
resize-zone	Resize a memory zone
restore	Restore VM from a snapshot
resume	Resume the VM
send-migration	Initiate a VM migration
shutdown	Shutdown the VM
shutdown-vmm	Shutdown the VMM
snapshot	Create a snapshot from VM
help	Print this message or the help of the given subcommand(s)

命令行选项:

选项	选项描述
`--api-socket <api-socket>`	HTTP API socket path (UNIX domain socket)
-h, –help	Print help
-V, –version	Print version

Docs: 热拔插

Sat, 15 Nov 2025 00:00:00 +0000

https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/docs/hotplug.md

目前 cloud hypervisor 支持 CPU 设备（仅限 x86）、PCI 设备和内存调整的热插拔。

内核支持

在 cloud hypervisor 上进行热插拔需要 ACPI GED 支持。这可以通过开启 CONFIG_ACPI_REDUCED_HARDWARE_ONLY 或使用此内核补丁（在 5.5-rc1 及更高版本中可用）：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/drivers/acpi/Makefile?id=ac36d37e943635fc072e9d4f47e40a48fbcdb3f0

CPU 热插拔

额外的 vCPU 可以在运行的 cloud-hypervisor 实例中添加和移除。这由两种机制控制：

指定一个大于默认（boot）vCPU 数量的最大潜在 vCPU 数。
向 VMM 发出 HTTP API 请求，要求添加额外的 vCPU。

要使用 CPU 热插拔功能，请以大于启动 vCPU 数量的最大 vCPU 数启动虚拟机，例如。

$ pushd $CLOUDH
$ sudo setcap cap_net_admin+ep ./cloud-hypervisor/target/release/cloud-hypervisor
$ ./cloud-hypervisor/target/release/cloud-hypervisor \
	--kernel custom-vmlinux.bin \
	--cmdline "console=ttyS0 console=hvc0 root=/dev/vda1 rw" \
	--disk path=focal-server-cloudimg-amd64.raw \
	--cpus boot=4,max=8 \
	--memory size=1024M \
	--net "tap=,mac=,ip=,mask=" \
	--rng \
	--api-socket=/tmp/ch-socket
$ popd

注意 –api-socket=/tmp/ch-socket 和 max 参数在 –cpus boot=4,max=8 中的添加。

若要请求 VMM 添加额外的 vCPU，请使用 resize API：

./ch-remote --api-socket=/tmp/ch-socket resize --cpus 8

额外的 vCPU 线程将被创建并向运行中的内核进行通告。内核不会立即启动 CPU，相反，用户必须从虚拟机内部将它们 “online” 化：

root@ch-guest ~ # lscpu | grep list:
On-line CPU(s) list:             0-3
Off-line CPU(s) list:            4-7
root@ch-guest ~ # echo 1 | tee /sys/devices/system/cpu/cpu[4,5,6,7]/online
1
root@ch-guest ~ # lscpu | grep list:
On-line CPU(s) list:             0-7

重启后，添加的 CPU 将保持在线状态。

移除 CPU 的操作与减少 resize API 中"desired_vcpus"字段的数值类似。CPU 将在虚拟机内部自动下线，因此无需在虚拟机内部运行任何命令：

./ch-remote --api-socket=/tmp/ch-socket resize --cpus 2

关于向虚拟机添加 CPU，重启后虚拟机将以减少的 vCPU 数量运行。

内存热插拔

ACPI 方法

可以从正在运行的 cloud-hypervisor 实例中添加额外内存。这由两种机制控制：

为热插拔内存分配部分 guest 物理地址空间。
向 VMM 发起 HTTP API 请求，要求为虚拟机分配新的内存量。在为虚拟机扩展内存的情况下，新内存将被热插拔到正在运行的虚拟机中；如果减少内存大小，则更改将在下次重启后生效。

要使用内存热插拔，启动虚拟机时在内存配置的 hotplug_size 参数中指定一些 RAM 大小。这个参数中指定的所有内存并不都会用于热插拔，因为存在间隔和对齐要求，所以建议使其大于所需的热插拔 RAM 大小。

由于 ACPI 方法为默认选项，因此无需添加额外的选项 hotplug_method=acpi 。

$ pushd $CLOUDH
$ sudo setcap cap_net_admin+ep ./cloud-hypervisor/target/release/cloud-hypervisor
$ ./cloud-hypervisor/target/release/cloud-hypervisor \
	--kernel custom-vmlinux.bin \
	--cmdline "console=ttyS0 console=hvc0 root=/dev/vda1 rw" \
	--disk path=focal-server-cloudimg-amd64.raw \
	--cpus boot=4,max=8 \
	--memory size=1024M,hotplug_size=8192M \
	--net "tap=,mac=,ip=,mask=" \
	--rng \
	--api-socket=/tmp/ch-socket
$ popd

在发出 API 请求之前，需要在虚拟机内部运行以下命令，以使其自动上线添加的内存：

root@ch-guest ~ # echo online | sudo tee /sys/devices/system/memory/auto_online_blocks

要求 VMM 扩展虚拟机的 RAM：

./ch-remote --api-socket=/tmp/ch-socket resize --memory 3G

新内存现在可以在虚拟机内部使用：

free -h
              total        used        free      shared  buff/cache   available
Mem:          3.0Gi        71Mi       2.8Gi       0.0Ki        47Mi       2.8Gi
Swap:          32Mi          0B        32Mi

由于 guest 操作系统限制，必须确保添加的内存量（当前分配的 RAM 与所需 RAM 之间的差值）是 128MiB 的倍数。

相同的 API 也可以用来减少虚拟机的所需 RAM，但更改不会在虚拟机重新启动后生效。

内存和 CPU 调整可以组合在同一个 HTTP API 请求中。

virtio-mem 方法

额外的内存可以从正在运行的 Cloud Hypervisor 实例中添加和移除。这由两种机制控制：

为热插拔内存分配部分客户物理地址空间。
向 VMM 发起 HTTP API 请求，请求为虚拟机分配新的内存量。

要使用内存热插拔功能，启动虚拟机时需要在 hotplug_size 参数中指定一些内存大小，并在内存配置中使用 hotplug_method=virtio-mem 。

$ pushd $CLOUDH
$ sudo setcap cap_net_admin+ep ./cloud-hypervisor/target/release/cloud-hypervisor
$ ./cloud-hypervisor/target/release/cloud-hypervisor \
	--kernel custom-vmlinux.bin \
	--cmdline "console=ttyS0 console=hvc0 root=/dev/vda1 rw" \
	--disk path=focal-server-cloudimg-amd64.raw \
	--memory size=1024M,hotplug_size=8192M,hotplug_method=virtio-mem \
	--net "tap=,mac=,ip=,mask=" \
	--api-socket=/tmp/ch-socket
$ popd

要求 VMM 为虚拟机扩展 RAM（请求单位为字节）：

./ch-remote --api-socket=/tmp/ch-socket resize --memory 3G

新内存现在可以在虚拟机内部使用：

相同的 API 也可以用来减少虚拟机的所需 RAM。需要注意的是，减少 RAM 大小可能只能部分生效，因为 guest 可能正在使用其中的一部分。

PCI 设备热插拔

添加 VFIO 设备

稍后看,目前没需要.

添加磁盘设备

要让 VMM 添加额外的磁盘设备，请使用 add-disk API。

./ch-remote --api-socket=/tmp/ch-socket add-disk path=/foo/bar/cloud.img

添加文件系统设备

要请求 VMM 添加额外的文件系统设备，请使用 add-fs API。

./ch-remote --api-socket=/tmp/ch-socket add-fs tag=myfs,socket=/foo/bar/virtiofs.sock

添加网络设备

要求 VMM 添加额外的网络设备，请使用 add-net API。

./ch-remote --api-socket=/tmp/ch-socket add-net tap=chtap0

添加 Pmem 设备

稍后看,目前没需要.

添加 Vsock 设备

若要请求 VMM 添加额外的 vsock 设备，请使用 add-vsock API。

./ch-remote --api-socket=/tmp/ch-socket add-vsock cid=3,socket=/foo/bar/vsock.sock

所有 PCI 设备的通用特性

额外的 PCI 设备将被创建并向正在运行的内核进行通告。新设备可以通过检查 PCI 设备列表来找到。

root@ch-guest ~ # lspci
00:00.0 Host bridge: Intel Corporation Device 0d57
00:01.0 Unassigned class [ffff]: Red Hat, Inc. Virtio console (rev 01)
00:02.0 Mass storage controller: Red Hat, Inc. Virtio block device (rev 01)
00:03.0 Unassigned class [ffff]: Red Hat, Inc. Virtio RNG (rev 01)

重启后，添加的 PCI 设备将保持存在。

移除 PCI 设备

移除 PCI 设备对所有类型的 PCI 设备都采用相同的方式。必须提供与设备相关的唯一标识符。此标识符可以在添加新设备时由用户提供，或者默认情况下由 Cloud Hypervisor 分配。

./ch-remote --api-socket=/tmp/ch-socket remove-device _disk0

在为虚拟机添加 PCI 设备后，重启后虚拟机将不再运行已移除的 PCI 设备。

Features: 延迟加载

Wed, 15 Oct 2025 00:00:00 +0000

Optimize: ballooning

Sat, 15 Nov 2025 00:00:00 +0000

通过 ballooning 动态调整内存

Optimize: virtio-mem

Sat, 15 Nov 2025 00:00:00 +0000

通过 virtio-mem 动态内存热插拔

Docs: Cloud Hypervisor 资料收集

Tue, 07 Oct 2025 00:00:00 +0000

官方资料

官方网站: https://www.cloudhypervisor.org/

官方文档：https://www.cloudhypervisor.org/docs/

官方博客：https://www.cloudhypervisor.org/blog/

代码仓库: https://github.com/cloud-hypervisor/cloud-hypervisor/

Features: Running Nanos Unikernels under Cloud Hypervisor

Wed, 15 Oct 2025 00:00:00 +0000

Running Nanos Unikernels under Cloud Hypervisor

https://www.youtube.com/watch?v=1IteC54pcWM

这是一份为您详细整理的视频内容图文解析。由于我无法直接生成视频截图文件，我将采用**“关键画面描述与终端代码块还原”**的方式来为您展示“图片”和视觉信息，结合详细的文字解析，带您完整回顾该视频。

📑 视频内容摘要 (Summary)

本视频是一个关于 Cloud Hypervisor 与 Nanos Unikernel (单内核) 结合使用的硬核技术演示。作者首先介绍了 Cloud Hypervisor 的官方网站、核心特性（如基于 Rust 开发、毫秒级启动、极小内存开销等）以及其背后的支持大厂（包含腾讯云等）。随后，作者转入 Linux 终端实战，展示了一个简单的 Go 语言程序，将其编译为 Nanos Unikernel 镜像，并通过 Cloud Hypervisor 极速拉起该轻量级虚拟机。程序成功在虚拟机内运行并输出日志。最后，作者通过强杀进程结束了演示，并总结指出这种极速、轻量的技术栈非常适合用来构建 Serverless（无服务器）架构。

🎬 详细内容与图文解析 (Detailed Breakdown)

第一阶段：介绍 Cloud Hypervisor (00:00 - 00:27)

📺 画面展示： 浏览器停留在 Cloud Hypervisor 的官方网站主页 (cloudhypervisor.org)。

[网页视觉呈现] 大标题：Run Cloud Virtual Machines Securely and Efficiently (安全高效地运行云虚拟机) 简介：Cloud Hypervisor is an open source Virtual Machine Monitor (VMM) implemented in Rust… 核心特性面板：Secure (安全)、Fast (快，启动<100ms)、Slim (轻量)、Kata Containers (支持 Kata)、Live migration (热迁移) 等。 支持机构：Alibaba, AMD, ARM, ByteDance, Intel, Microsoft, Tencent Cloud。
📝 文字解说： 作者欢迎大家来到视频教程系列。今天的主角是 Cloud Hypervisor。他介绍道，这是一个用 Rust 语言编写的全新虚拟机监视器（VMM）。它拥有许多酷炫的功能，并且得到了如阿里巴巴、字节跳动、英特尔、腾讯、Ampere 等众多大厂的支持。作者预告，今天的演示目标是在 Cloud Hypervisor 上启动一些 Unikernel（单内核）。

第二阶段：准备 Go 语言测试程序 (00:27 - 00:50)

📺 画面展示： 画面切换到纯黑背景的 Linux 终端。作者使用 Vim 打开了一个名为 main.go 的文件。

[终端代码截图还原]

package main
import (
    "fmt"
    "time"
)
func main() {
    for i := 0; i < 10; i++ {
        fmt.Println("hello from nanos")
        time.Sleep(1 * time.Second)
    }
}

📝 文字解说： 作者展示了他准备好的一个非常简单的 Go 语言程序。这个程序的功能只有一个：通过一个 for 循环，每隔 1 秒钟在控制台打印一次 "hello from nanos"，总共循环 10 次。作者表示，他在此之前已经提前将这个 Go 程序编译好了。

第三阶段：查看编译产物与 Nanos 内核 (00:50 - 01:36)

📺 画面展示： 终端执行了 ls -lh 命令，展示当前目录下的文件列表和大小。

[终端输出截图还原]

cyberg@nanos:~/...$ ls -lh
-rwxrwxr-x 1 cyberg cyberg 4.0M May 24 08:15 cloud-hypervisor
-rw-rw-r-- 1 cyberg cyberg 2.4M May 24 08:27 kernel.img
-rwxrwxr-x 1 cyberg cyberg 120  May 24 08:30 run.sh

📝 文字解说： 作者向大家展示当前工作目录中的三个关键文件：
1. cloud-hypervisor：编译好的 VMM 执行文件，体积非常小巧，大约只有 4MB。
2. kernel.img：这是 Nanos Unikernel 的内核镜像文件。
3. 为了照顾想要自己从源码编译 Nanos 的开发者，作者还特意敲击路径，展示了这个 kernel.img 在 Nanos 源码树中的默认生成位置（通常在 .../nanos/output/platform/pc/bin/kernel.img）。

第四阶段：一键极速启动轻量虚拟机 (01:36 - 02:18)

📺 画面展示： 作者查看并执行了启动脚本 run.sh。随后，终端立刻开始疯狂输出虚拟机的启动日志和 Go 程序的运行结果。

[启动脚本与运行画面还原]

# 查看 run.sh 内容
cyberg@nanos:~/...$ cat run.sh
./cloud-hypervisor --kernel kernel.img --disk "path=/home/cyberg/ch/g" --console off --serial tty

# 执行脚本
cyberg@nanos:~/...$ sudo ./run.sh
[sudo] password for cyberg: ******

# 虚拟机瞬间拉起并输出
en1: assigned FE80::2C2C:47FF:FEE6:7D07
hello from nanos
hello from nanos
hello from nanos
...

📝 文字解说： 作者打开了 run.sh 脚本，讲解了启动 Cloud Hypervisor 的核心参数：指定内核文件 (--kernel)、指定挂载的磁盘路径 (--disk) 以及将输出重定向到串口终端 (--serial tty)。当他输入 sudo 密码按下回车后，虚拟机在瞬间（毫秒级）就完成了启动。我们直接在屏幕上看到了网卡分配的日志，紧接着，刚才编写的 Go 程序开始正常工作，屏幕上稳稳地每秒打印出一句 "hello from nanos"。

第五阶段：展示进程管理并结束演示 (02:18 - 02:44)

📺 画面展示： 作者将终端分屏（Split Screen）。左侧继续打印日志，右侧用于查找并杀掉进程。

[分屏操作画面还原]

# 右侧终端操作
cyberg@nanos:~/...$ ps aux | grep cloud
root     13904  0.0  0.0 2004488 64536 pts/2 ... ./cloud-hypervisor --kernel ...
cyberg@nanos:~/...$ sudo kill -9 13904

# 左侧终端显示：
hello from nanos
hello from nanos
Killed
cyberg@nanos:~/...$

📝 文字解说： 作者提到，Cloud Hypervisor 其实还提供了一个非常强大的 API（REST API），可以通过 API 来控制虚拟机的生命周期，但他今天不打算演示，留到以后的视频再说。为了结束当前一直打印的虚拟机，他在右侧终端使用 ps aux 找到了 Cloud Hypervisor 的进程 PID，然后直接运行 sudo kill -9 强杀了该进程。左侧的虚拟机随即停止运行，显示 Killed 并退回了宿主机的终端提示符。最后，作者总结道：“这就是在 Cloud Hypervisor 下运行 Nanos Unikernel 的演示。我认为你可以利用这项技术制作出非常酷炫的 Serverless（无服务器）风格的特性。下次再见！”