Lima v2.1 已经扩展到 macOS 和 FreeBSD 来宾系统，v2.2 又补上了 Windows。现在，Linux、macOS、FreeBSD 和 Windows 虚拟机可以进入同一套 limactl 工作流。与此同时，TPM 2.0 模拟为需要可信平台模块的 Windows 安装、测试和自动化场景补上了关键能力。
Windows 支持改变的不只是系统列表
过去，开发团队经常为不同来宾系统维护不同工具：Linux 环境走 Lima，Windows 测试则交给另一套虚拟机管理程序。问题不只是多装一个软件，还包括命名、启动、停止、清理和 CI 脚本都要维护两份。
Lima v2.2 的价值在于统一生命周期操作。团队可以继续围绕 limactl 组织虚拟机管理：
- 使用名称区分 Windows、Linux、macOS 和 FreeBSD 实例；
- 通过相同入口完成创建、查看、启动、停止和删除；
- 在本地测试脚本中减少针对不同虚拟机工具的条件分支；
- 将 Windows 纳入已有的 Lima 环境治理方式。
这里需要区分“统一控制面”和“完全相同的来宾体验”。Windows 与 Unix 类系统在远程登录、镜像准备、许可、初始化脚本和文件共享方面仍可能存在差异。limactl 统一的是虚拟机生命周期入口，并不意味着来宾系统内部的运维命令也会变得一致。
TPM 2.0 模拟解决了什么问题
TPM 是独立于普通磁盘和内存的可信计算组件。操作系统和安全软件可以用它保存密钥、记录启动状态，并判断启动链是否符合预期。Windows 的部分安装、安全和设备管理场景会检查 TPM 2.0，因此仅仅能够启动一个传统虚拟机并不总是够用。
Lima v2.2 提供 TPM 2.0 模拟后，开发者可以在不依赖宿主机物理 TPM 直通的前提下构造相应测试环境。这对下面几类工作尤其有用：
- 验证 Windows 安装或升级流程中的 TPM 检查；
- 测试依赖 TPM 状态的企业设备策略；
- 观察安全软件在虚拟 TPM 存在或异常时的行为；
- 为可重复的 Windows 测试环境保留统一的虚拟机定义。
不过，模拟 TPM 不等同于物理 TPM。涉及硬件级密钥保护、合规认证、攻击面评估或生产凭据托管时，不能把模拟环境的结论直接外推到真实设备。虚拟 TPM 的状态文件也应按敏感数据处理，避免随意复制或提交到代码仓库。
可以这样实践：启动并检查 Windows 来宾
下面给出一个可改造的操作流程。由于摘要没有给出 Windows 模板的准确名称，先在 WIN_TEMPLATE 中填写 Lima v2.2 安装环境实际提供的 Windows 模板 URI 或本地 YAML 路径。
#!/usr/bin/env bash
set -euo pipefail
VM_NAME=win-dev
WIN_TEMPLATE=/absolute/path/to/windows-template.yaml
limactl --version
limactl start --name="$VM_NAME" "$WIN_TEMPLATE"
limactl list
如果发行包提供的是模板 URI，可以把变量改成对应值：
WIN_TEMPLATE='template://REPLACE_WITH_ACTUAL_WINDOWS_TEMPLATE'
limactl start --name=win-dev "$WIN_TEMPLATE"
启动后，在 Windows 来宾的 PowerShell 中检查系统是否识别到 TPM：
$ErrorActionPreference = 'Stop'
Get-Tpm | Select-Object `
TpmPresent, `
TpmReady, `
TpmEnabled, `
TpmActivated, `
ManufacturerIdTxt, `
ManufacturerVersion
重点观察 TpmPresent 和 TpmReady。如果虚拟机模板已启用 TPM 2.0 模拟，但结果仍为 False，应依次检查模板配置、虚拟机启动日志以及 Windows 设备管理器，而不是只在来宾系统里重复初始化。
测试结束后，可以继续使用通用的 Lima 生命周期命令清理实例：
limactl stop win-dev
limactl delete win-dev
删除前应确认虚拟机中没有需要保留的数据。Windows 系统盘和虚拟 TPM 状态可能共同参与密钥保护；只备份其中一部分，恢复后未必还能解锁原有数据。
把四种系统纳入同一套测试入口
团队可以把来宾系统名称和模板放进一个简单的 shell 封装中。下面是假设性示例，模板路径需要按实际安装环境修改：
#!/usr/bin/env bash
set -euo pipefail
GUEST="${1:?usage: $0 <linux|windows|macos|freebsd>}"
case "$GUEST" in
linux) TEMPLATE=/absolute/path/to/linux.yaml ;;
windows) TEMPLATE=/absolute/path/to/windows.yaml ;;
macos) TEMPLATE=/absolute/path/to/macos.yaml ;;
freebsd) TEMPLATE=/absolute/path/to/freebsd.yaml ;;
*) echo "unsupported guest: $GUEST" >&2; exit 2 ;;
esac
VM_NAME="ci-${GUEST}"
limactl start --name="$VM_NAME" "$TEMPLATE"
limactl list
这个封装没有假设四种系统拥有相同的初始化方式。更稳妥的做法是统一外层生命周期命令，同时为每种来宾保留独立的配置、引导和测试脚本。
升级前应确认的边界
采用 Lima v2.2 时，可以按下面的清单推进：
- 确认宿主机后端、Windows 镜像和模板与目标环境兼容；
- 明确 Windows 镜像的许可、激活和分发规则；
- 在测试机上验证 TPM 的创建、关机、重启、克隆和删除行为；
- 不把虚拟 TPM 当作物理硬件安全保证；
- 分开备份系统盘与敏感状态，并实际演练恢复流程；
- 让跨系统脚本只统一生命周期操作，不强行统一来宾内部命令。
Lima v2.2 最值得关注的变化，是 Windows 不再需要游离于现有 Lima 工作流之外。TPM 2.0 模拟则让这项支持覆盖了更多现代 Windows 场景。对于已经使用 Lima 管理开发虚拟机的团队，这次升级提供了一个收拢工具链的机会，但镜像许可、安全边界和跨系统差异仍需要单独设计。