外观
unRAID 虚拟机
unRAID 是买断制的商业 NAS 系统，特色是允许阵列里的硬盘容量不一致（不要求同容量成组），并自带成熟的 Docker 和虚拟机管理界面。把它跑在 PVE 虚拟机里能行，但有两个别的 NAS 系统没有的前提：授权和一个物理 U 盘绑定，以及开发者本身不建议虚拟化它。
适合谁
| 你的情况 | 适不适合 |
|---|---|
| 已经买了 unRAID 授权，想把它和其他服务整合到一台 PVE 上 | 可以考虑，但请先读完下面的官方立场 |
| 需要不同容量硬盘混用的阵列能力 | unRAID 在这一点上确实是同类里少见的 |
| 追求最稳妥、官方支持的部署方式 | 物理机才是 unRAID 官方支持的形态，虚拟化是社区玩法 |
| 还没买授权，想先零成本试用 | unRAID 官网提供限时试用授权，请通过官方渠道获取，本站不提供任何绕过授权的方法 |
unRAID 开发者不建议虚拟化
社区里能找到多篇「把 unRAID 装进 PVE 虚拟机」的教程，但 unRAID 官方论坛上的指南明确提到，开发者不希望 unRAID 被虚拟化，理由是可能带来稳定性问题。本文照实记录社区通行做法，但这不等于官方认可，生产数据请权衡这一点。
授权和 USB 盘：不能只用虚拟磁盘
unRAID 的授权和一个物理 USB 闪存盘的硬件标识（GUID）绑定，这是它长期以来的核心授权机制。把 USB 盘的内容复制进一个虚拟磁盘文件，无法让 unRAID 认可这块虚拟磁盘的 GUID——这是该机制的设计目的，本站不提供、也不建议寻找绕开它的方法。
社区通行且不涉及绕过授权的做法是：把物理 U 盘直接直通给虚拟机，让 unRAID 像在物理机上一样识别这块真实存在的 U 盘。
text
虚拟机 → Hardware → Add → USB Device选择这块 U 盘（可以选具体设备，也可以选它所在的物理 USB 端口，端口方式在你换插槽时更省心）。
更新的版本提供了另一条路径
unRAID 7.3 起官方文档提到了一种不依赖 USB 盘的「内部启动」方案，把授权改为与主板的 TPM 2.0 绑定。PVE 能给虚拟机提供 vTPM，理论上有可能满足这个前提，但本站没有找到确认它在虚拟机里可行的官方说明，请在动手前查阅 unRAID 官方文档确认当前支持状态，不要假定它一定能用。
装机前先在物理机上验证过这块 U 盘
社区经验里，不是所有 U 盘型号都能被 unRAID 稳定识别和启动，即使是同型号也可能有个体差异。建议先在一台物理机上直接启动过这块 U 盘确认没问题，再拿到虚拟机场景使用，避免把「U 盘本身有问题」误判成「虚拟化配置有问题」。
资源规划
| 项 | 建议起点 | 说明 |
|---|---|---|
| vCPU | 1–2 | 官方文档给的是基础要求，按后续跑的 Docker/VM 负载再加 |
| 内存 | 2 GB 起 | 同样要看后续是否在 unRAID 里跑应用或虚拟机 |
| 启动介质 | 直通的物理 USB 盘 | 不是虚拟磁盘，见上文 |
| 数据盘 | 直通的整张 HBA 及其上的磁盘 | 见下文 |
| 网卡 | 社区反馈 VirtIO 网卡在部分环境下不稳定，遇到问题可以换成 E1000 | 以你实际测试结果为准 |
不要在 unRAID 虚拟机里再嵌套跑虚拟机/容器
unRAID 自身也提供 Docker 和虚拟机管理功能。在「跑在 PVE 虚拟机里的 unRAID」内部再开虚拟机或需要硬件加速的 Docker 应用，属于嵌套虚拟化，默认不工作，需要额外在 PVE 侧开启嵌套虚拟化支持，行为也不如物理机稳定。如果你的目标就是要用 unRAID 管理虚拟机，更适合让 unRAID 跑在物理机上。
创建与安装
- 建虚拟机：OS 类型选 Linux，Machine 和 BIOS 保持默认（SeaBIOS + i440fx 或 q35 均有人成功过，社区没有一致结论，遇到直通问题可以两者都试）。
- SCSI Controller 改成兼容性更好的选项（部分版本对
VirtIO SCSI single支持不稳定），具体以你测试的结果为准。 - 不挂载任何安装 ISO——unRAID 直接从上面直通进来的 USB 盘启动，U 盘上已经包含官方提供的启动文件（从 unRAID 官网下载并按官方说明写入 U 盘）。
Options → Boot Order里把直通的 USB 设备排在第一位。- 确认硬盘与 HBA 直通的前提条件都满足后，直通承载数据盘的整张 HBA。
直通 HBA 前确认它不会抢走 USB 启动设备
社区报告过一种情况：直通某些板载 HBA 之后，虚拟机的 PCI 设备枚举顺序变化，导致虚拟机不再从 USB 启动，反而尝试从这张 HBA 上的硬盘启动并卡在控制器自己的启动界面循环重启。
影响范围：仅在同时直通 HBA 又依赖 USB 启动时出现；不直通 HBA、或者数据盘用虚拟磁盘的场景不受影响。 前置条件：确认 Options → Boot Order 里 USB 设备排在最前，且 HBA 的直通不影响这个顺序——这一步需要实际开机验证，不能只看配置。 回退方式：如果出现启动循环，关机后在 Hardware 页临时移除 HBA 的 PCI 直通，确认虚拟机能正常从 USB 启动 unRAID 本体，再逐步排查 HBA 直通配置，不要在问题没解决前反复開关机尝试。
第一次启动之后
启动后，unRAID 会在控制台打印出它获取到的 IP，通过浏览器访问 http://tower.local（或打印出的 IP）进入 Web 界面完成阵列配置：分配奇偶校验盘和数据盘、启动阵列。这部分和 unRAID 在物理机上的操作完全一致，具体界面以官方文档为准。
网络不通先换网卡型号
如果启动后拿不到 IP（比如地址段变成 169.254.x.x），社区经验通常先怀疑两个方向：USB 盘本身有问题（换一块测试），或者 VirtIO 网卡驱动不兼容（临时换成 E1000 测试）。
检查结果
- Web 界面能正常访问，阵列状态显示为 Started。
存储 → 阵列里的磁盘数量、容量与直通的物理硬件一致。- 建一个共享，从另一台电脑验证能连接、能读写。
- 完整重启一次这台虚拟机（PVE 里 Stop 再 Start），确认 USB 授权正常识别、阵列自动重新启动。
- 检查校验（Parity Check）能正常发起并推进，这是判断阵列健康状态的关键指标。
备份与维护
直通的磁盘数据不在 PVE 备份里
和其他直通方案一样，vzdump 完全看不到直通给 unRAID 的 USB 盘和 HBA 上的物理磁盘，这些内容不会出现在任何 PVE 备份里。
unRAID 的阵列奇偶校验（Parity）提供的是冗余（防单块盘物理损坏），不是备份，解决不了误删、加密勒索或者阵列本身配置损坏。真正的数据备份需要依赖 unRAID 自身的备份类插件、或者把关键数据同步到阵列之外的另一份存储，规划思路见备份与恢复。
授权 U 盘本身要有备份
U 盘一旦损坏或丢失，授权和部分配置会跟着丢失（unRAID 官方文档提供了授权找回和 U 盘更换的流程）。定期用 unRAID 自带的 U 盘备份功能保存一份配置备份到别处，具体操作入口以你的版本界面为准。
常见问题
直通了 USB 盘，但虚拟机识别不到，或者一直重启。 先确认这块 U 盘本身在物理机上能正常引导 unRAID；确认 Boot Order 里 USB 排第一；检查是不是同时直通的 HBA 干扰了启动顺序（见上文警示）。
校验（Parity）速度明显比物理机慢很多。 检查 HBA 是否真的走了 PCI 直通而不是某种模拟层；确认虚拟机的 vCPU 和内存没有被过度超额分配挤占；也和宿主机上其他虚拟机的磁盘/网络负载有关。
想在 unRAID 里跑 Docker 应用或再开虚拟机。 技术上可行，但属于在虚拟机里嵌套虚拟化/容器，需要额外配置且社区稳定性反馈不如物理机，见上文警示。如果这是你的主要用途，评估直接在物理机上装 unRAID 是否更合适。
忘了授权和 U 盘怎么处理，能不能换一块虚拟磁盘继续用。 不能，这正是授权机制的设计目的。授权丢失或 U 盘损坏时，请通过 unRAID 官方的账户找回和 U 盘更换流程处理。
参考资料
- 硬盘与 HBA 直通：NAS 虚拟机的正确做法
- 硬件直通
- NAS 系统
- unRAID 官方文档与论坛："Licensing FAQ"、虚拟化相关的社区指南
- 备份与恢复