Docker VMM Public Beta 实战：切换、性能验证与安全边界

更新日期：2026-08-31

Docker 在 2026 年 8 月发布了全新 Docker VMM Public Beta。它是 Docker Desktop 底层的第一方虚拟机监视器，负责运行承载 Linux Docker Engine 的虚拟机，目标是改善启动、主机文件共享、内存回收与 Windows 稳定性。Docker Desktop 4.86 或更高版本的 Mac（Apple Silicon）和 Windows 用户可以在设置中切换试用。

先澄清一个很容易混淆的概念：Docker VMM 不是“每个普通容器一台 microVM”。Docker Desktop 的普通 Linux 容器仍然运行在同一台 Desktop Linux VM 内，共享其中的 Linux 内核与 Docker daemon；VMM 提供的是这台 Linux VM 与 macOS/Windows 宿主机之间的虚拟机边界。Docker Sandboxes（SBX）也使用相同方向的虚拟化引擎，但 Sandboxes 的 Agent microVM 产品模型不能直接套到普通 docker run 或 Compose 上。

因此，Docker VMM 值得测试，但不应被当作一键容器安全加固。正确的试用方法是先记录当前 backend 的可用性与性能基线，在非关键开发机切换，验证 bind mount、数据库、跨架构镜像和网络，再决定是否扩到团队。

当前可用范围与时间边界

截至 2026-08-31，官方状态如下：

项目	当前状态
发布阶段	Public Beta
Docker Desktop	4.86 或更高
macOS	Apple Silicon 可选 Docker VMM
Windows	可选 Docker VMM，作为 WSL 2/Hyper-V 之外的 backend
Linux	官方计划在 GA 时提供，当前 Beta 不应写成已支持
内存	Docker Linux VM 至少分配 4 GB
GA	Docker 目标为 2026 年 10 月底，不是已经承诺完成的事实

Public Beta 的意义是可以在真实开发流程中评估，不等于当前适合所有生产或受管设备。Docker 官方描述了更快启动、改善文件 I/O、空闲内存归还宿主机等收益，但没有给出适用于每个项目的统一倍率。源码树大小、文件数量、语言工具链、杀毒软件、宿主文件系统和 bind mount 模式都会改变结果，团队必须测自己的 workload。

架构上到底替换了哪一层

在 macOS 或 Windows 上运行 Linux 容器时，大致链路是：

macOS / Windows host
        ↓
Docker VMM（虚拟化层）
        ↓
Docker Desktop Linux VM
        ↓
Docker Engine / containerd
        ↓
Linux containers

Docker VMM 替换的是宿主和 Linux VM 之间的虚拟化实现，并没有改变镜像格式、Dockerfile、Compose Spec 或容器共享内核的基本模型。大多数项目无需修改 docker compose up 命令，但以下边界可能发生变化：

宿主目录如何通过 virtiofs 进入 VM；
VM 内存如何按负载增长并归还宿主；
网络如何在宿主、VM bridge 和容器网络之间转发；
Apple Silicon 上 amd64 镜像如何模拟；
数据库对文件系统语义与同步写的兼容性。

旧版名为 Docker VMM 的选项也需要按版本区分。官方文档说明，Docker Desktop 4.35 至 4.85 的 Mac Docker VMM 由 libkrun 支撑；4.86 起同一设置切换到 Docker 自研 hypervisor。评测报告必须同时记录 Docker Desktop 版本，否则“Docker VMM 性能”可能比较的是两种不同实现。

哪些团队适合现在试用

比较合适的试点包括：

Mac/Windows 日常开发中频繁启动、停止多容器 Compose；
大型源码目录的 edit-compile-test 循环受文件共享延迟影响；
Docker Desktop 空闲后仍长期占用大量内存；
Windows 团队希望评估 WSL 2 之外的真实 VM 边界；
平台团队愿意维护 Beta 版本、兼容清单和快速回退。

暂时不建议作为第一批试点的场景：

Apple Silicon 必须高频运行 amd64-only 镜像；
开发环境依赖 MongoDB、Cassandra 或对文件系统一致性敏感的数据库；
大量项目目录依赖自动 bind mount 共享；
VDI/嵌套虚拟化、受严格 MDM 管理且没有回退窗口；
关键演示、考试、发布日或无法重建本地数据的开发机。

Beta 不意味着一定不稳定，而是接口、兼容和默认值仍可能变化。生产容器主机上的 Docker Engine 也不是本次切换对象；不要为了测试 Desktop VMM 去改 Linux 服务器 runtime。

第一步：切换前记录可恢复基线

先在当前 backend 上收集只读信息：

docker version
docker info
docker context show
docker compose version
docker system df
docker ps --all --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
docker volume ls
docker network ls

把关键项目的 Compose 最终配置保存到受控位置：

docker compose config > compose.resolved.yaml

生成文件可能包含展开后的环境变量；提交或分享前必须检查秘密，不能直接上传到工单。更稳妥的基线还包括：

Docker Desktop 与宿主 OS 的精确版本；
当前 Virtual Machine Manager/backend；
VM 分配的 CPU、内存与磁盘上限；
关键镜像 digest，而不仅是可变化的 tag；
命名 volume、bind mount 目录和本地数据库备份；
公司代理、VPN、DNS、证书、registry mirror 与登录状态；
一组可重复的 build、test、启动和文件同步用例。

不要假设切换 backend 一定保留所有本地容器数据。即使当前版本可以看到原有镜像和 volume，回退流程仍应以 Dockerfile、Compose、registry 制品和应用级备份重建为准。数据库要使用对应数据库的备份/恢复工具，不能把复制 Desktop VM 磁盘当成一致性备份。

第二步：设计公平的性能验证

不要只运行一次 docker run hello-world 就下结论。至少覆盖四类工作流，并在相同硬件、资源设置、镜像 digest 和代码 commit 下重复多次。

1. 冷启动与热启动

time docker compose up --detach --wait
docker compose ps
docker compose down

冷启动包括 Docker Desktop 刚启动、镜像已在本地但容器不存在；热启动则保留缓存。两者分开记录，避免把镜像下载时间算成 VMM 性能。

2. 镜像构建

time docker build --no-cache --progress=plain -t local/vmm-check:baseline .
time docker build --progress=plain -t local/vmm-check:cached .

同时记录构建上下文大小和是否使用宿主 bind mount。网络下载波动很大，最好使用本地 registry mirror 或将下载阶段与编译阶段拆开观察。

3. bind mount 文件循环

使用团队真实项目执行：保存源码、容器内 watcher 发现变更、完成增量编译、测试返回。记录 p50/p95，而不是挑最快一次。Node.js、Go、Rust、Java 项目的目录结构差异很大，厂商的文件 I/O 描述不能替代实际测量。

4. 内存回收

在启动高内存容器、停止容器并等待稳定后，分别观察 Docker Desktop 与宿主任务管理器。不要在不同 VM 内存上限之间比较，也不要把宿主 page cache 当作永久泄漏。记录时间序列比单张截图更可靠。

评测表至少包含：backend、Desktop 版本、宿主版本、资源配置、项目 commit、样本次数、均值/中位数/p95 和失败数。若差异小于日常波动，应诚实记录“无明显变化”，不要为了热点文章制造倍率。

第三步：在 Mac 上切换

Docker Desktop 4.86+ 的 Apple Silicon Mac：

打开 Docker Desktop；
进入 Settings → General → Virtual Machine Manager；
选择 Docker VMM；
确认 Settings → Resources 中 Linux VM 内存至少为 4 GB；
点击 Apply & restart。

如果此前已经选择旧 Docker VMM，升级到 4.86 后设置会保留，并在重启时进入新的 Docker 自研 hypervisor。仍应在切换后检查实际版本与基本功能：

docker version
docker info
docker run --rm hello-world

Mac 当前有两项关键限制。

第一，Docker VMM 不支持 Rosetta，因此 Apple Silicon 上运行 linux/amd64 镜像的模拟会比较慢。先找出当前镜像架构：

docker image inspect your-image:tag --format '{{.Os}}/{{.Architecture}}'

优先改用官方 multi-arch 镜像或构建原生 linux/arm64，不要把 --platform=linux/amd64 永久硬编码成团队默认。

第二，Docker VMM 仅支持 virtiofs 文件共享，MongoDB、Cassandra 等数据库当前可能出现故障。数据库开发环境更适合先使用命名 volume，而不是把数据库数据目录 bind mount 到 macOS；即使如此也要跑恢复、崩溃重启与一致性测试。

第四步：在 Windows 上切换

Windows 安装 Docker Desktop 4.86 或更高后：

确认 BIOS/UEFI 硬件虚拟化已启用；
打开 Docker Desktop Settings → General；
在 Virtual Machine Manager 中选择 Docker VMM；
为 Linux VM 分配至少 4 GB 内存；
点击 Apply & restart。

Docker 官方把 VMM 描述为 WSL 2 之外的容器优化 hypervisor，并强调 Linux 容器环境与 Windows 宿主之间是真实 VM 边界。这里讨论的是 Linux containers backend，不要推导成 Windows containers 的新隔离方式。

切换后验证 PowerShell、WSL shell、IDE 与 CI 工具实际连接的 context：

docker context show
docker version
docker info
docker compose up --detach --wait

如果团队依赖从 WSL distribution 直接访问项目文件、特定 VPN 路由、企业代理或 host.docker.internal，必须逐项验证。VMM 改善某些路径，不代表它与 WSL 2 的所有文件和网络集成完全相同。

第五步：修复 bind mount “未共享”错误

Docker VMM 当前不支持 bind mount auto-shares。Compose 启动时报 file is not shared from the host 时，不要把宿主根目录或整个用户目录一次性共享给 Docker。

正确做法是：

打开 Settings → Resources → File sharing；
添加项目确实需要的最小目录；
Apply & restart；
重新执行 docker compose up；
核对容器内路径、读写权限与文件监听。

共享目录是 VM 边界上的显式入口。开发者把 $HOME、SSH、云配置或密码管理器目录整体 bind mount 给容器，会直接扩大容器可见数据。Compose 中使用只读配置时明确写 :ro，构建凭据使用 BuildKit secret，不把秘密复制进 build context。

services:
  app:
    volumes:
      - ./src:/workspace/src:ro

需要热更新的源码当然可能要可写，但应按目录和服务拆分，不要因为 Beta 共享报错就关闭所有边界。

Docker VMM 的安全收益与不能解决的问题

VMM 提供 Linux VM 到宿主机的隔离边界。在 Windows 上，它让容器环境不再依赖与宿主深度集成的 WSL 2 路径，适合纳入企业治理评估。但 VM 内部的普通容器仍共享内核；一个拿到 Docker socket 的容器，仍可能控制该 Desktop Docker daemon 下的其他容器、镜像和 volume。

Docker VMM 不会自动完成以下工作：

不会把每个容器变成独立 microVM；
不会自动启用 Docker Business 的 Enhanced Container Isolation；
不会扫描镜像漏洞、阻止恶意依赖或保护泄漏的 registry token；
不会让危险 bind mount、--privileged、host network 或 Docker socket 变安全；
不会代替镜像签名、SBOM、最小权限与 egress policy；
不会为 AI coding agent 自动限制可读写的工作区。

基础加固仍然需要：

docker run --rm \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  your-image:tag

这只是通用示例，真实应用可能需要特定 capability、可写目录或端口。应逐项添加，而不是因为启动失败就恢复 --privileged。

如果目标是运行会执行任意代码的 AI Agent，应单独评估 Docker Sandboxes、安全凭据代理、工作区 --clone 和网络策略。Docker VMM 与 Sandboxes 共享虚拟化技术方向，不代表开启 VMM 就获得 Sandbox 的每任务隔离。

已知问题排查顺序

切换后 Docker 无法正常启动

确认 Desktop 版本、宿主硬件虚拟化、VM 至少 4 GB 内存，并再次重启 Docker Desktop。仍失败时先切回之前的稳定 backend，保留诊断日志后再通过 Docker 支持渠道反馈，不在关键开发机反复重装。

Compose 提示 host path 未共享

到 File sharing 精确添加项目目录。检查路径大小写、符号链接目标和 MDM 限制，不要共享宿主根目录。

Apple Silicon amd64 构建明显变慢

核对基础镜像和依赖是否只有 amd64。能改成 multi-arch 就改为原生 arm64；必须使用 Rosetta 的项目暂时切回 Apple Virtualization framework，等待 Docker 后续兼容进展。

MongoDB/Cassandra 启动或数据测试失败

这是官方列出的 Mac 已知问题。停止试点，不把开发数据反复用于破坏性重试；恢复备份并切回已验证 VMM。若要继续分析，在可丢弃数据上比较命名 volume 与 bind mount，并记录 Desktop 版本。

VPN、代理或私有 registry 异常

先检查 Docker Desktop 的代理、证书和 DNS 设置，再用最小镜像请求明确目标。不要通过关闭 TLS 验证或暴露未加密 daemon 来止血。公司网络下的差异应同时交给平台/网络团队调查。

灰度与回滚方案

建议按以下顺序推进：

两台非关键设备分别覆盖 Apple Silicon 与 Windows；
跑一周真实 build、Compose、IDE、VPN 与数据库工作流；
记录成功率、p95、内存和兼容问题，不只记录最快结果；
建立允许/暂缓项目列表；
扩到一个自愿团队，仍保留原 backend 一键回退；
等 GA 后重新核对 release notes，再决定是否设为团队默认。

Mac 回滚是在同一 Virtual Machine Manager 设置中选择之前已验证的 Apple Virtualization framework；Windows 通常切回 WSL 2 或组织此前批准的 Hyper-V，然后 Apply & restart。回滚后重新执行版本、Compose、数据恢复与网络测试。

不要在切换当天同时升级数据库镜像、重写 Compose、迁移 CPU 架构和清理 Docker data。一次只改变 VMM，才能判断问题来自哪里。若必须执行 Docker Desktop 的 reset/uninstall，先停下来确认数据备份；这类操作可能破坏本地镜像、容器和 volume，不属于普通回滚步骤。

试点检查清单

Docker VMM Public Beta 最有价值的地方，是 Docker 开始直接控制 Desktop 的虚拟化层，从而有机会把性能、内存与治理做成一体。但对团队来说，是否切换不应由发布文案决定，而应由自己的构建时延、文件系统兼容、内存曲线和回退演练决定。先小范围量化，保留原 backend，再等待 GA 复核，会比“全员立即开启”更稳妥。