ZimaOS 虚拟机的下一步开发计划
开发预览：更简单的镜像导入、更安全的网络、磁盘快照、备份，以及支撑这些功能的可靠性改进。
开发预览： 本文不是版本发布公告，也不承诺交付日期。标记为验证中、原型或研究的功能在进入公开 ZimaOS 版本前可能发生变化。功能是否可用还可能取决于 ZimaOS 软件包的推送进度、主机硬件、客户机操作系统以及存储或网络配置。
四项工作以不同速度推进。本文中的状态标签是当前状态的唯一准确信息来源。
有些工作负载非常适合运行在容器中，另一些则需要完整的操作系统。
只能在 Windows 上运行的实用工具、Home Assistant 虚拟设备、隔离的 Linux 测试机，或是一个可以重建且不会影响其余网络的路由器实验环境。这些任务正是虚拟机在家庭服务器上发挥价值的地方。
ZVM 是 ZimaOS 中提供这套体验的虚拟机服务。它已经具备创建和运行虚拟机所需的基础能力，而社区也向我们指出了体验仍需改进的地方。导入现有磁盘镜像仍然需要太多手动步骤。桥接网络容易让人误解。自动启动、快照、备份和恢复需要更明确的保护措施。操作失败时，提示信息也应该帮助你解决问题，而不只是告诉你出了错。
我们一直在把这些反馈汇总为更明确的 ZVM 改进方向。下面将介绍目前正在强化的内容、处于积极验证阶段的内容，以及仍在研究的内容。
状态概览
| 状态 | 含义 | 当前示例 |
|---|---|---|
| Alpha 基础功能 | 代码已进入当前 Alpha 版本线；设备何时可用仍取决于 ZimaOS 软件包的推送进度。 | 强化基于浏览器的虚拟机控制台访问路径的身份验证。 |
| 验证中 | 主要实现已经完成，但兼容性和升级测试仍在进行。 | 直接导入镜像、分阶段转换、完整性检查和失败清理。 |
| 原型 | 设计已经在代码和测试中运行，但行为和 UI 仍可能变化。 | 多模式网络、带保护机制的桥接更改、自动启动事件、磁盘快照和完整备份创建。 |
| 研究 | 我们正在探索的方向，并非承诺发布的功能。 | USB、PCIe、GPU 和物理网卡直通；增量备份；更广泛的迁移工作流。 |
我们特意使用这些标签。某项功能出现在开发分支或原型中，并不意味着它已经可以用于你的生产虚拟机。
导入你已有的镜像
许多自托管项目发布的是可以直接运行的虚拟磁盘，而不是安装程序。要把这类镜像导入虚拟机，你可能需要手动转换格式、将其移动到正确的目录，然后再把它接入一台新虚拟机。
我们希望让这个过程简单得多：选择镜像，选择虚拟机的存储位置，其余准备工作交给 ZVM。
第一批兼容目标包括：
- ISO 安装介质
- QCOW2
- VDI
- VMDK
- raw 或 IMG 磁盘
- 包含 OVF 元数据的 OVA 软件包
每条路径最终都会得到经过验证、可供虚拟机使用的副本，或进入清理步骤；绝不会把未完成的磁盘显示为可用。
支持一种格式不能只靠文件扩展名判断。ZVM 会检查内容、验证镜像，并将其复制或转换到为虚拟机选择的存储位置。非 ISO 磁盘默认转换为 QCOW2，同时保留 raw 作为高级选项。完成后的虚拟机会指向这个受管理的副本，因此删除最初上传或下载的文件不应影响虚拟机运行。
导入管线在设计时对失败和成功同样谨慎：
- 暂存源文件，但不将其视为已经完成的磁盘。
- 检测真实格式，并拒绝不支持或已损坏的镜像。
- 检查可选的 SHA-256 值。
- 检查 OVA 归档，并拒绝路径遍历或不安全的条目。
- 复制或转换为临时
.partial文件。 - 同步并验证完成的镜像，再通过原子重命名使其生效。
- 取消或失败后删除临时数据。
在条件允许时，这一过程还会保留稀疏磁盘特性。虚拟容量很大的磁盘不应立刻占用同等大小的物理存储空间。
更长期的 UI 目标是让本地上传、在 ZimaOS Files 中选择的路径、URL 下载和内置系统模板汇入同一个虚拟机配置流程。当前阶段解决的是为虚拟机导入镜像，而不是建立独立的镜像库，也不包含虚拟机导出功能。
状态：验证中。 直接导入后端和回归测试已经存在，其中包括针对 appliance-1.2.3.qcow2 这类带版本号文件名的修复。我们仍需扩大对设备、镜像和客户机操作系统的覆盖范围。
网络模式应该是一道选择题，而不是术语考试
不同的虚拟网络模式在表单中看起来可能几乎一样，但数据在实际网络中的传输方式大不相同。ZVM 应该在你按下“保存”之前解释清楚这些差异。
网络原型为每个虚拟网卡提供明确的模式：
- NAT：适用于能够访问外部网络的简单私有网络。
- Linux bridge：适用于虚拟机需要直接出现在局域网中并与主机通信的场景。
- macvtap：适用于更直接的连接方式，并明确警告主机与客户机之间通常无法通信。
- 断开连接：适用于隔离的实验环境，或稍后才会连接的网卡。
这些标签在设置表单中可能看起来相似，但主机、虚拟机和局域网之间的通信方式并不相同。
产品目标是让每台虚拟机拥有 1-8 个可独立配置的网卡。NAT 规划还包括 DHCP 地址保留和 TCP 或 UDP 端口转发。如果主机端口重复或已被占用，ZVM 应该报告冲突，而不是悄悄替换另一条规则。
在无头家庭服务器上，更改桥接配置需要格外谨慎。移动承载 ZimaOS 管理连接的物理接口，可能会断开正在执行这项更改的浏览器。原型将这项操作视为一个事务：检查拟议配置、应用配置、监控连接状况，并在新路径未能恢复正常时回滚。
对于需要关机才能生效的更改，也应同样如实说明。如果主机或客户机无法安全地热插拔网卡，ZVM 应保存请求的配置，将其标记为等待重启，并且不应假装正在运行的虚拟机已经应用了该配置。
状态：原型。 明确的接口模式、接口 API、持久化 NAT 策略、转发规则、静态网络预配置以及带保护机制的 Linux bridge 更改都已有可运行的分支实现。硬件和升级测试矩阵尚未完成。
快照不是备份
快照是位于原存储附近的回滚点。备份则是一份独立副本，用于在原虚拟机或存储出现问题时继续保留数据。如果把两者放在一个含糊的按钮后面，恢复只会变得更困难。
快照和备份解决的是不同问题。从备份恢复仍是后续里程碑。
用磁盘快照进行本地回滚
首个快照设计仅包含磁盘。它不会捕获内存，也不能让应用从停止时的确切指令处恢复运行。
对于已关机的 QCOW2 虚拟机，ZVM 可以直接复制稳定的磁盘。对于正在运行的虚拟机，原型会创建一个临时外部叠加层，以获得某一时间点的磁盘视图；然后复制稳定的基础磁盘，再提交数据并将活动磁盘切回原始路径。虚拟机不会依赖一条不断增长的 ZVM 管理叠加层链。
默认快照具有崩溃一致性，类似意外断电后的磁盘状态。如果客户机中的 QEMU Guest Agent 能够正常响应，ZVM 可以提供静默捕获，让文件系统围绕快照执行刷新和冻结。ZVM 会在运行时检查这项能力，而不是显示一个可能无法生效的开关。
恢复磁盘快照前必须关闭虚拟机。替换磁盘之前，原型会写入恢复日志，并临时接管自动启动设置。如果多磁盘恢复被中断，它可以回滚，而不是让虚拟机混用不同时间点的磁盘。实时捕获还会检查可用空间，并在复制期间监控临时叠加层。
用完整备份保留独立副本
备份原型会在通过 ZimaOS Files 选择的现有目录中创建 .zvm-backup 备份包。它会记录非活动状态的虚拟机配置、独立的 QCOW2 磁盘副本、SHA-256 校验和、文件大小、原始磁盘映射以及带版本的清单。
目标位置安全性也是这项功能的一部分。ZVM 以较高的存储访问权限运行，因此实现会拒绝操作系统路径、ZVM 元数据位置以及基于符号链接的逃逸路径，而不是依赖简单的文本检查。
重要限制： 创建和列出备份包属于当前原型的一部分。从备份包恢复虚拟机是单独的里程碑，不能假定该功能已经可用。磁盘快照也不包含内存状态。
状态：原型。 API、服务实现、中断日志、路径检查和针对性测试已存在于开发中的代码里。真实 libvirt、断电、空间不足和多磁盘测试仍是发布门槛。
自动启动不该是一个令人费解的开关
对于 Home Assistant、路由器虚拟机或任何应在主机重启后恢复运行的服务，自动启动很有用。但如果虚拟机依赖的存储或网络尚未就绪，自动启动也会带来风险。
当前工作会通过 API 公开现有的自动启动设置，并在设置变更时记录成功或失败事件。更完整的设计会加入启动优先级和可配置延迟，然后等待主机所需资源就绪，再启动依赖这些资源的虚拟机。
状态：原型。 基本的自动启动控制和事件报告目前正在测试。依赖感知的启动顺序和延迟是设计目标，尚未成为完整功能。
小修复同样重要
如果升级、控制台会话或失败的操作让虚拟机处于不明确的状态，新功能也无济于事。多项不太显眼的修复正在与大型功能同步推进：
- 控制台访问安全： 在当前 Alpha 代码版本线中，基于浏览器的 VNC 代理现在会遵循预期的身份验证路径。设备何时可用仍取决于 ZimaOS 软件包的推送进度。
- 更安全的身份处理： 身份验证不再通过客户端可控的转发地址来判断请求是否来自本地。
- 带点号的镜像名称：
appliance-1.2.3.qcow2这类文件名会保留有用的版本号，而不会被错误截短。 - 已取消的上传： 镜像上传中断后会删除未完成的文件，不会将其遗留为看似可用的文件。
- 已保存设置与实时设置： 网络功能会读取持久化的虚拟机定义，并能显示等待重启状态，避免混淆运行状态和已保存状态。
- 网络协调： 对重复的 DHCP 地址保留、转发冲突和仅部分应用的主机网络策略执行明确验证，并采用面向回滚的处理方式。
其他问题报告仍在回归计划中，包括浏览器控制台二进制帧、重连循环、键盘行为、Windows 安装、GRUB 显示和升级兼容性。正在调查并不意味着这些问题已经全部修复。
你现有的虚拟机应继续由你掌控
社区虚拟机通常包含手动编辑的 XML、非常规设备、自定义固件，或由旧版 ZimaOS 创建的设置。为了更改一个字段而重写整个定义，可能会恰好删掉让这台虚拟机有用的定制内容。
ZVM Next 设计采用增量方式：
- 发现现有虚拟机，但不对其进行更改。
- 只修改请求的操作所负责的 XML 节点。
- 保留 UUID、现有 MAC 地址、磁盘路径、NVRAM、自动启动设置和未涉及的设备。
- 说明某项功能能否实时应用、是否需要关机、是否需要明确转换，或是否不受支持。
- 确保新的操作失败后，虚拟机仍能使用之前的配置启动。
在稳定版发布前，计划中的回归测试矩阵会覆盖现有 Windows、Linux、Home Assistant OS，以及 OpenWRT 或 pfSense 虚拟机，测试功能使用、重启、升级和回滚场景。
直通不只是一个复选框
硬件直通是社区呼声最高的功能之一。如果隐藏过多复杂细节，它也很容易变得不安全。
USB 分配可以相对独立。PCIe 和 GPU 直通则取决于 IOMMU 分组、固件、驱动绑定、设备重置行为，以及同一分组中还共享了哪些设备。物理网卡直通可能会移除 ZimaOS 自身所需的接口。一个复选框无法让不兼容的硬件变得安全。
因此，PCIe、GPU 和物理网卡直通仍属于研究/预览方向。任何公开预览都需要兼容性矩阵、明确的主机影响警告、恢复说明，以及独立禁用该功能的方法。
增量备份、在线存储迁移、跨主机迁移、集群、高可用、分布式存储、内存快照和备份去重也不在当前核心范围内。
帮助我们测试真实工作负载
我们在分享想法的同时也说明边界，因为最有用的反馈始于真实工作负载。
请告诉我们：
- 你想导入哪种镜像格式和哪个虚拟设备？
- 你需要 NAT、真正的 Linux bridge、macvtap，还是隔离的多网卡实验环境？
- 未安装 QEMU Guest Agent 时，崩溃一致性快照对你是否仍有用？
- 完整备份应该存放在哪里？你希望获得怎样的可用空间保护？
- 你想直通哪款 USB、PCIe、GPU 或网卡设备？
- 目前哪个虚拟机问题正在阻碍你？
提交问题报告时，请附上你的 Zima 硬件或 x86 主机型号、ZimaOS 和 ZVM 版本、客户机操作系统、虚拟机固件类型、磁盘格式和存储位置、网络模式、导致失败的确切操作，以及 UI 中显示的完整错误信息。
欢迎加入 ZimaSpace 社区参与讨论。这些细节可以帮助其他社区成员和 Zima 团队将你的报告与已知案例进行对照。
我们的目标并不是把 libvirt 的每个开关都搬进网页表单，而是让家庭服务器上真正重要的虚拟机工作流变得易于理解、可以恢复，并且足够安全，让你放心迎接下一次重启。
常见问题
所有这些功能现在都可以使用吗？
不是。状态表区分了 Alpha 基础功能、验证中、原型和研究。本文是方向更新，不是版本说明。
快照会包含虚拟机的内存状态吗？
当前核心设计不会包含。首个实现只捕获磁盘。正在运行的虚拟机默认创建崩溃一致性快照，并且在 QEMU Guest Agent 可用时可以让文件系统进入静默状态。
每个 OVA、VMDK 或 VDI 镜像都能导入吗？
这些格式属于兼容目标，但真实镜像各不相同。固件、架构、控制器、驱动程序、加密、损坏和供应商专用的 OVF 元数据仍可能导致镜像不兼容。ZVM 应该拒绝不支持的情况，并给出可供采取行动的说明，而不是创建一台无法启动的虚拟机。
已经支持从备份恢复了吗？
还没有。当前原型可以创建和列出完整备份包。从这些备份包恢复是单独规划的工作流，需要经过明确测试。
GPU 直通能在每台 Zima 设备上运行吗？
不能。它取决于 CPU、固件、IOMMU 分组、GPU、主机驱动、客户机驱动和重置行为。在明确支持矩阵和恢复路径之前，它仍属于研究和预览领域。