Encore团队在Apple Silicon上重建了Firecracker微VM栈，开发了crackling工具，统一了Linux和macOS的微VM接口，使工程师能在本地运行与生产环境相同的构建系统。

标题：我们在Apple Silicon上重建了Linux微虚拟机栈

来源：https://encore.dev/blog/firecracker-apple-silicon

发布时间：2026年8月18日

Encore公司自2022年中起，所有构建工作均在Firecracker微虚拟机内运行。Firecracker精简了模拟硬件，仅保留Linux内核所需部分，为每个构建提供虚拟机级别的隔离，同时启动速度接近容器。然而，Firecracker依赖KVM，需要Linux主机支持/dev/kvm，而Mac不具备此条件。由于Encore多数工程师使用Mac开发，且Firecracker维护者已拒绝基于Apple Virtualization.framework的概念验证，明确表示短期内不支持macOS，因此团队面临挑战。

为解决这一问题，团队开发了crackling——一个统一的微虚拟机API，在Linux上驱动Firecracker，在macOS上驱动Apple的虚拟机管理程序。crackling能在两种平台上启动相同的镜像，为此需要重建大部分Linux镜像工具链以在macOS上运行。

此前，团队使用共享构建机器，每位工程师通过脚本配置个人环境，包括SSH访问、用户创建、权限设置和镜像复制。但这种方式存在诸多不便：远程构建导致本地断点无法触发、日志需通过SSH查看、性能分析工具需手动复制到远程机器，且每次镜像变更都需经过docker save、rsync和mksquashfs等繁琐步骤，大大降低了开发效率。

crackling的核心设计是提供一个独立于底层虚拟机管理程序的接口。它通过MachineSpec描述虚拟机配置（包括vCPU、内存、内核、根文件系统等），并通过MachineBackend trait实现启动、关闭、暂停、恢复等操作。两种后端（Firecracker和Apple Virtualization.framework）在编译时静态选择，各自支持不同的功能集，如Firecracker支持主机tap设备和MMDS元数据服务，而Apple框架支持内置NAT、virtiofs目录共享和Rosetta x86二进制翻译。

在实现Apple后端时，团队面临严格的线程约束：Apple的虚拟机对象必须在串行调度队列上创建和访问，不能跨异步点移动。团队通过全局串行DispatchQueue管理所有虚拟机对象，确保线程安全。

构建可启动的Linux镜像是另一大挑战。在macOS上，将OCI镜像转换为可启动的根文件系统通常需要root权限和循环挂载，而这些在macOS上不可用。团队用纯Rust实现了内核解包（处理EFI zboot格式）、OCI层应用（处理白出条目）和initramfs生成。内核需要解压缩后才能被Apple框架识别，否则会报错。根文件系统默认从内存启动，通过clonefile或FICLONE实现缓存优化。

虚拟机内部通信通过vsock实现。团队开发了一个轻量级代理，使用AFVSOCK协议，支持命令执行、交互式shell、文件传输和端口转发。代理是静态编译的musl二进制文件，在macOS和Linux上分别编译为aarch64和x8664版本。

值得注意的是，Apple框架不支持第三方应用进行虚拟机快照保存，即使验证器报告支持，实际保存操作也会失败，因为需要Apple不授予第三方应用的私有权限。

最终，crackling实现了在Mac上本地运行构建系统，工程师可以克隆构建系统并在笔记本上直接运行，启动与生产环境相同的OCI镜像。共享主机、docker save管道、rsync和特权容器内的手动桥接都已不复存在，开发者可以在构建系统中设置断点并直接命中。本地工作流程简洁明了：通过crackling run启动镜像，crackling exec执行命令，crackling shell进入交互式shell。

根据评论内容，总结主要观点如下：

1. 技术实现与限制 - Hypervisor.framework 类比 KVM：评论1指出VZ.framework功能有限，Hypervisor.framework更接近KVM。关键引用："VZ.framework is very limited, Hypervisor.framework is the better analogue to KVM" - 私有API限制：评论3提到Apple的私有API（如com.apple.private.virtualization）隐藏了许多有用功能。关键引用："There's lot of useful stuff hidden in Apple's Private API space" - 嵌套虚拟化方案：评论6分享了在Mac上运行Firecracker的挑战，并介绍了使用vfkit→QEMU→Kind+Firecracker的嵌套虚拟化方案。关键引用："getting Firecracker to run well on M-series macs is quite the undertaking"

2. 开发工具与工作流 - 远程开发 vs 本地工具：评论4认为在构建本地后端前使用共享远程机器四年，是权衡开发工具投资与临时解决方案的好教训。关键引用："Four years on a shared remote machine... a good lesson in when to invest in dev tooling" - 硬件更新周期：评论9质疑为何工程师仍使用M1/M2 Mac，认为应每两年更新设备。关键引用："I've always gotten a new machine at $CORP every 2 years"

3. 文章质量与AI写作争议 - 负面评价：评论7、12、13批评文章明显由AI生成，缺乏个人风格。评论12称"obvious LLM slop writing is just so incredibly off-putting"，评论13建议作者"don't outsource your writing to AI"并去除"Claudisms"。 - 可读性问题：评论5指出博客渲染器在Firefox中键盘滚动失效，评论11简单评价"Very hard to read"。

4. 其他观点 - 问题解决方向：评论2认为Encore工程师在Mac上开发是"解决错误的问题"。 - 作者回应：评论8为文章作者，表示愿意回答问题。

平衡性总结：评论对技术内容（如虚拟化方案）有肯定，但对文章写作风格和AI使用持强烈批评态度，同时指出渲染器等技术细节问题。