企业官网建设流程全解析

很多人第一次把 UNRAID 装进 PVE 虚拟机，折腾到凌晨两点，最后卡在“阵列里那块盘显示为设备缺失”这一行红字上。我当年也是这么过来的。这台组合本身不复杂——PVE 提供虚拟化和硬件直通能力，UNRAID 提供灵活的存储池、共享和 Docker 生态，两者叠在一起，等于用一台机器同时干掉了“虚拟化平台”和“NAS”两件事。但它有一个和其他虚拟机完全不同的脾气：UNRAID 极其依赖对底层物理磁盘的“真实视野”，一旦你把它当成一台普通 Linux 虚拟机来建，后面几乎必然会翻车。下面我把从硬件确认、虚拟机参数、磁盘直通、网络配置到阵列建立的完整链路拆开讲一遍，包括我在每个环节踩过的坑，适合已经装好 PVE、想在同一台机器上再叠一层 NAS 的人参考。

1. 为什么把 UNRAID 塞进 PVE 虚拟机里跑

1.1 裸机 UNRAID 与嵌套方案的本质差别

裸机装 UNRAID 是最省心的路线：硬盘、网卡、USB 引导盘全部原生可见，SMART 能读、磁盘能休眠、阵列行为和你预期完全一致。代价是这台机器基本被 UNRAID 独占，你没法再顺手跑个软路由、跑个 Windows 测试机、或者折腾几个不同的 Linux 发行版。我自己就吃过这个亏——早期一台裸机 UNRAID 用了两年，后来想加个测试环境，只能再买一台机器，电费和空间都翻倍。

把 UNRAID 放进 PVE 虚拟机，本质是用一层 hypervisor 换取资源复用。PVE 负责硬件抽象和资源切分，UNRAID 只在一个受控的环境里做它擅长的事。听起来很美，但关键约束在于：UNRAID 的存储阵列不是传统的 RAID，它对每块成员盘都是独立文件系统直接读写，校验盘通过实时计算奇偶校验来容错。这意味着它需要看到磁盘的真实设备节点，能拿到磁盘序列号、容量、SMART 状态，而不是一个被 QEMU 包装过的虚拟盘。所以整个方案的成败，八成压在“磁盘怎么交给虚拟机”这一个问题上。

很多人一上来就在 PVE 网页界面点“创建虚拟机”，然后把物理盘当普通虚拟盘挂进去，结果 UNRAID 里根本识别不到可用于阵列的裸设备，或者识别到了但容量显示异常。这不是 PVE 的错，是路径选错了。

1.2 这套组合真正适合的人群和场景

我个人认为，PVE 套 UNRAID 最适合三种人。第一种是家里只有一台性能还不错的机器，既想跑 NAS 做文件共享和备份，又想在 PVE 上开几个轻量虚拟机做软路由、内网服务、测试环境，一台机器全包。第二种是已经把 PVE 当主力的用户，数据盘本来就挂在 PVE 主机上，但受够了手工管理 ZFS 数据集和 Samba 配置的繁琐，想换成 UNRAID 那种“插盘就能用、界面点点就会”的管理方式。第三种是喜欢折腾的人，想先在这套组合上验证自己的存储方案，等摸清楚了再决定要不要迁移到裸机。

反过来，有两种情况我建议直接放弃这个念头。一是你对性能极度敏感，比如要用 UNRAID 里跑的虚拟机做主力办公机或游戏机——多一层虚拟化带来的延迟和调度开销是实实在在的，虽然不夸张，但在高负载下能明显感觉到。二是你只有一块盘或者两块盘，本来就没什么阵列需求，那直接用 PVE 自带的 ZFS 或者 LVM 建存储就够了，再套一层 UNRAID 纯属增加故障点。

提示：如果你打算长期使用某个项目，虚拟机方案更适合做“先行验证”，把配置、阵列布局、Docker 清单都跑通之后，再考虑是否迁移到裸机。反过来从裸机迁移到虚拟机要麻烦得多。

2. 动手之前，先把硬件和磁盘的账算清楚

2.1 CPU 虚拟化能力和 IOMMU 分组必须先验证

在 PVE 主机上第一件事不是建虚拟机，而是确认两件事：CPU 虚拟化扩展是否打开，IOMMU 分组是否干净。前者决定了虚拟机能不能跑起来，后者决定了你的 HBA 卡能不能整卡直通。

先看虚拟化扩展。登录 PVE 的 SSH，执行：

grep -E 'vmx|svm' /proc/cpuinfo | head -1

只要输出里有vmx（Intel）或svm（AMD）就说明 BIOS 里的虚拟化开关是打开的。如果什么都没输出，去主板 BIOS 里找 Intel VT-x 或者 SVM Mode，打开它。这一步听起来很基础，但我遇到过一次很诡异的情况：主板更新 BIOS 之后虚拟化开关被重置了，PVE 上的虚拟机全部启动失败，报的是“KVM 不可用”，查了半天才发现是固件设置问题。

接着确认 IOMMU。在 PVE 8 里，编辑/etc/default/grub，在GRUB_CMDLINE_LINUX_DEFAULT里加上：

intel_iommu=on iommu=pt

AMD 平台把intel_iommu=on换成amd_iommu=on。然后执行update-grub并重启。重启后检查是否生效：

dmesg | grep -e DMAR -e IOMMU

看到 “DMAR: IOMMU enabled” 之类的输出就算成功。接下来是看分组，这条命令我建议你直接存下来：

for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}:" for d in $g/devices/*; do echo -e "\t$(lspci -nns ${d##*/})" done done

输出里如果一块 SATA 控制器或者 HBA 卡独占一个分组，那恭喜你，整卡直通很干净。如果它和别的设备挤在同一个分组里，就得考虑是加装 ACS 补丁内核（比较折腾，也有风险），还是退而求其次走单盘映射的方案。我自己的经验是，消费级主板上板载 SATA 控制器经常和一堆小设备挤在一起，所以后来我干脆加了张独立的 HBA 卡专门负责数据盘，直通起来省心太多。

2.2 硬盘角色的划分要提前想明白

在建虚拟机之前，先拿张纸把每块盘的用途写清楚。UNRAID 的阵列有个硬性规则：校验盘的容量必须大于或等于阵列中最大的数据盘，这一点没得商量。所以如果你手上有一块 16T 和几块 8T，那 16T 要么当校验盘，要么单独做缓存，不能混着用。

我一般的规划是这样的：

这里有个容易被忽略的点：不要把 PVE 系统盘所在的控制器整卡直通给虚拟机。我曾经见过有人把唯一的 SATA 控制器直通出去，结果 PVE 主机直接失联，只能重装。如果你要用整卡直通，务必确认那块卡上没有任何 PVE 系统盘或者正在被 PVE 挂载的数据盘。

2.3 引导介质怎么准备，直接影响后面的授权

UNRAID 的引导方式和普通系统不一样，它是从一个 U 盘启动的，而且授权是跟引导设备的唯一标识绑定的。这一点非常关键，因为你在虚拟机里怎么提供这个引导设备，决定了后续授权能不能顺利识别。

目前主流有两种做法。第一种是把物理 U 盘直通给虚拟机，用lsusb找到它的厂商和产品 ID：

lsusb

输出类似Bus 001 Device 004: ID 0781:5567 SanDisk Corp. Cruzer Blade，那0781:5567就是你要的。然后在虚拟机配置里加：

qm set 200 -usb0 host=0781:5567

这种做法的好处是引导设备就是真实的物理设备，标识不变，只要之前做好的引导盘插上就能直接用，配置和授权都不会丢。我目前用的就是这种方式，插上去虚拟机重启几次都没出过问题。

第二种是把引导盘做成镜像文件挂载。做法是先在一台机器上把 U 盘内容dd成镜像，然后把镜像作为虚拟磁盘挂到虚拟机里引导。这种做法灵活，不占用 USB 口，但引导设备的标识会变化，需要按官方流程重新处理授权。所以如果你已经用物理 U 盘跑了很久，我建议直接直通 USB，别折腾镜像。

注意：不论用哪种方式，引导盘的配置目录一定要定期备份。UNRAID 的界面里有导出配置的入口，把这个备份文件存到别的地方，比什么快照都实在。

3. 在 PVE 里创建这台“特殊”的虚拟机

3.1 命令行建机比网页点选更可控

PVE 的网页创建向导很好用，但它默认的参数对 UNRAID 并不友好，而且有些选项藏得比较深。我习惯直接用命令行建，参数一目了然，也方便复现。先创建一台基础虚拟机：

qm create 200 \ --name unraid \ --ostype l26 \ --machine q35 \ --bios ovmf \ --cpu host \ --sockets 1 \ --cores 4 \ --memory 16384 \ --balloon 0 \ --scsihw virtio-scsi-single \ --net0 virtio,bridge=vmbr0 \ --onboot 1 \ --agent 1

上面这几行里，我刻意加了一个--balloon 0。内存气球在普通虚拟机上是个好东西，能在主机内存紧张时回收虚拟机内存，但对 UNRAID 来说，它的 ZFS 缓存、Docker 容器和虚拟机都吃内存，气球机制会导致性能曲线非常难看——有时候快有时候卡，你根本找不到原因。所以直接关掉气球，给一个固定值，宁可多留点余量。

3.2 机型、BIOS 和 CPU 类型这几个参数为什么这么填

--machine q35选的是新一代的虚拟芯片组，相比默认的 i440fx，它对 PCIe 设备的模拟更接近真实硬件，直通和外设识别都更顺。这个参数不写的话默认是 i440fx，装 UNRAID 也能跑，但有些 PCIe 相关功能会受限。

--bios ovmf表示使用 UEFI 引导。UNRAID 从 6.10 版本开始支持 UEFI 启动，用 OVMF 的好处是引导过程更规范，也方便后续挂 EFI 分区。不过要注意，用了 OVMF 就必须给它建一个 EFI 磁盘，否则虚拟机启动会直接报错：

qm set 200 --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=0

这里的pre-enrolled-keys=0很重要。如果你保持默认值 1，OVMF 会预置安全启动的密钥，而 UNRAID 的引导程序没有签名，安全启动就不会放行，结果就是开机直接掉进 UEFI Shell 里，什么提示都没有。我在这上面浪费过整整一个晚上，最后发现是安全启动拦住了引导。

--cpu host让虚拟机透传主机的 CPU 特性，包括各种指令集扩展。这对 UNRAID 来说意义不小，因为它内部的 ZFS、加密、压缩等功能都依赖较新的指令集，用默认的kvm64会损失不少性能。

3.3 磁盘控制器和缓存策略的选择

--scsihw virtio-scsi-single是我强烈推荐的一个设置。相比默认的virtio-scsi-pci，single 版本给每个磁盘分配独立的队列，配合iothread能把并行 I/O 的性能优势发挥出来，对多盘阵列的场景帮助明显。

对于系统盘和虚拟磁盘，我会额外配一下缓存策略。QEMU 的磁盘缓存有几档，含义差别很大：

对直通的物理盘，我一律用cache=none。理由很直白：UNRAID 自己有文件系统和校验逻辑，如果再叠一层主机页缓存，一是数据一致性难以保证，二是磁盘休眠基本就别想生效了——主机随时可能因为缓存刷盘把盘唤醒。

如果是本地 LVM 上的虚拟系统盘，用writeback问题不大，毕竟那上面放的是虚拟机镜像，不是你的宝贵数据。

4. 磁盘直通：UNRAID 阵列能不能活的关键

4.1 整卡直通和单盘映射的根本区别

这是全文最重要的一个选择。UNRAID 的阵列成员盘，本质上需要“裸设备访问”，而虚拟化层有两种方式提供它。

整卡直通是把整块 HBA 或 SATA 控制器通过 PCIe 直通交给虚拟机。虚拟机会以为它独占这块卡，能枚举卡上所有磁盘，读到完整的序列号、型号、SMART 信息，也能下发休眠指令。这是最接近裸机的方案，UNRAID 的各种磁盘管理功能都能正常工作。代价是这块卡上的资源对 PVE 主机完全不可见了，而且 IOMMU 分组必须干净。

单盘映射是用 PVE 的qm set命令把主机上的某个物理块设备直接分配给虚拟机：

qm set 200 -scsi1 /dev/disk/by-id/ata-WDC_WD40EFRX_1234567890

注意这里必须用/dev/disk/by-id/下面的稳定路径，而不是/dev/sdb这种随时会变的设备名。UNRAID 认盘的时候会记录设备标识，如果 PVE 重启后磁盘顺序变了，用/dev/sdX会导致虚拟机认到错误的盘，严重的话就是数据损坏。我自己有过一次教训：给机器加了块新盘，重启后sdb变成了sdc，虚拟机的配置还指向sdb，结果 UNRAID 把一个不属于阵列的盘当成成员盘，报了“设备缺失”的错，折腾了很久才理清楚。

单盘映射的缺点也很明确：UNRAID 里看到的是一块虚拟盘，SMART 数据基本读不到（界面里的 SMART 信息会显示为空或者不可用），磁盘休眠也几乎失效。好处是 IOMMU 分组不干净的时候也能用，配置灵活。

4.2 用 qm set 映射物理盘的完整过程

假设你已经确认了要交给 UNRAID 的物理盘，第一步是在 PVE 主机上确认它没有被挂载、没有文件系统、没有加入任何 ZFS 池：

lsblk -f

看到某个盘没有挂载点、没有文件系统类型，才说明它是空闲的。如果它之前属于某个 ZFS 池，先用zpool destroy处理掉，别硬来。

第二步，找到它的稳定路径：

ls -l /dev/disk/by-id/ | grep -i ata

第三步，把它挂到虚拟机上。这里有个细节：如果虚拟机的 SCSI 控制器已经用来挂引导盘了，注意编号别冲突。我一般让引导盘占sata0，数据盘从scsi1开始排：

qm set 200 -scsi1 /dev/disk/by-id/ata-WDC_WD40EFRX_XXX,cache=none,aio=native qm set 200 -scsi2 /dev/disk/by-id/ata-WDC_WD40EFRX_YYY,cache=none,aio=native qm set 200 -scsi3 /dev/disk/by-id/ata-WDC_WD40EFRX_ZZZ,cache=none,aio=native

aio=native在 Linux 主机上配合cache=none能拿到最好的直通性能，因为它是异步的，不需要 QEMU 额外开线程池。如果换aio=threads，虚拟机会占一个 iothread，性能会略低一些。

第四步，检查虚拟机配置文件确认磁盘顺序和参数无误：

cat /etc/pve/qemu-server/200.conf

这个文件我建议每次改完都看一眼。因为 UNRAID 认盘是按顺序和 ID 走的，如果这里顺序错了，它会提示“磁盘顺序变更”，虽然一般能自动识别，但总归是个隐患。

4.3 直通之后，SMART、序列号和休眠还剩多少

这是很多人关心的点。我实测下来结论是这样的：单盘映射的情况下，UNRAID 的磁盘页面能看到容量、能看到型号（型号是从虚拟设备信息里来的），但SMART 数据读不到，温度信息也没有。对于只想跑个 NAS 存文件的人来说，这问题不大，反正你有 PVE 主机可以监控硬盘健康。但如果你很在意磁盘健康预警，那就得整卡直通。

整卡直通的做法稍微复杂点。先在 PVE 主机上找到 HBA 卡的 PCI 地址：

lspci -nnk | grep -A3 -i 'sata\|sas'

拿到类似03:00.0的地址后，把它绑定到 vfio 驱动。创建/etc/modprobe.d/vfio.conf：

options vfio-pci ids=1000:0072

其中1000:0072是设备的 vendor:device ID，从lspci -nn的输出里能看到。同时要在黑名单里屏蔽掉它原来的驱动，比如：

blacklist mpt3sas blacklist ahci

然后update-initramfs -u -k all并重启。重启后用lspci -nnk确认这个设备使用的是vfio-pci，再在虚拟机里加：

qm set 200 -hostpci0 0000:03:00,pcie=1

整卡直通成功之后，UNRAID 里会看到卡上所有磁盘，SMART、序列号、休眠全部正常。我在一台机器上跑了两年多，磁盘休眠确实生效了，功耗和噪音都明显下降。

一个忠告：黑名单驱动之前，务必确认你的 PVE 系统盘不在这个控制器上。否则重启后系统盘失去驱动，机器直接起不来，只能进恢复模式抢救。

5. 网络打通：从 PVE 网桥到 UNRAID 的 br0

5.1 网桥模式下虚拟网卡型号的选择

PVE 默认建好的vmbr0就是一个 Linux 网桥，虚拟机接上去就等同于接在同一个二层网络里，同网段的设备能直接互相访问。这一步基本不用改。

麻烦的是虚拟网卡的型号。我给的命令里用的是virtio，这是性能最好的选择，UNRAID 较新的内核版本都自带virtio_net驱动，开机就能识别。但如果你用的是比较老的 UNRAID 版本，内核里可能没有这个驱动，开机后会显示“没有网络接口”，界面也进不去，这时候就抓瞎了。

我的做法是先保险地试e1000，跑起来之后再考虑换成virtio。切换方法：

qm set 200 --net0 virtio,bridge=vmbr0

换完之后进 UNRAID，在“网络设置”里会看到新网卡，重新配置一下 IP 就行。两种型号的实际性能差距，在日常文件共享场景下感受不明显，但如果你跑大量小文件传输或者要跑内网服务，virtio 的优势就出来了。

另外，如果你的 PVE 主机有多个物理网口，且你已经把其中一个专门分给了虚拟机用的网桥，那 UNRAID 里的br0桥接配置会比较自然。如果只有一个网口，所有流量都挤在vmbr0上，也能跑，只是要注意别把 PVE 管理口和 UNRAID 的业务口抢出问题来。

5.2 UNRAID 侧配置静态 IP 的完整流程

虚拟机第一次启动后，UNRAID 默认用 DHCP 拿地址。你可以在 PVE 里看虚拟机的控制台输出，找到它拿到的 IP，然后浏览器访问http://那个IP。进去第一件事就是把网络设置改成静态地址，理由很简单：这是个 NAS，IP 飘来飘去会让所有挂载、Docker 映射、内网服务全部失效。

在 UNRAID 的“设置 - 网络设置”里，把“获取 IP 地址”从 DHCP 改成静态，然后填：

• IPv4 地址：比如192.168.1.10
• 子网掩码：255.255.255.0
• 网关：你的路由器地址
• DNS：路由器地址或者公共 DNS

这里有个坑：改完网络设置之后不要点“应用”，直接关机再启动。因为 UNRAID 在运行中重启网络栈的时候，如果配置有错，你可能就再也连不上了，只能通过 PVE 的虚拟控制台去改。我吃过这个亏，改成了192.168.1.10，结果和路由器地址撞了，整个网络抖动，最后只能用 PVE 控制台连进去手动改回来。

静态 IP 配好之后，把vmbr0上的 DHCP 服务确认没在瞎发地址，别让同一个网段有两个 DHCP 服务器。这个在家庭环境里很容易出问题，尤其是你 PVE 里还跑了软路由的情况下。

5.3 同网段互访和主机名解析的几个细节

网络通不通用ping就能验证。在 PVE 主机上ping 192.168.1.10，在 UNRAID 上ping一下 PVE 主机的地址，两边通就说明基础链路没问题。

接下来几个细节值得处理一下。第一，UNRAID 的主机名和 SMB 名称建议改成有辨识度的，别用默认的Tower，不然你有两台设备的时候会分不清谁是谁。第二，如果要在 PVE 里访问 UNRAID 的共享，直接在 PVE 上挂载 SMB 或者 NFS 都行，但注意挂载路径别和 PVE 自己的存储冲突。第三，如果你在 UNRAID 里启用了br0桥接（比如要跑虚拟机用独立的 IP），那会占用一个物理网口，虚拟环境下这个操作需要谨慎，因为网卡是虚拟的，桥接行为跟物理机不一样。

我一般不用 UNRAID 的桥接功能，虚拟机直接在 PVE 层面管，网络拓扑更清晰。UNRAID 只负责存储和 Docker，职责单一，出问题的概率小得多。

6. 首次开机到阵列建立的完整过程

6.1 引导设备和授权绑定的那些事

虚拟机第一次开机，你会看到 UNRAID 的引导菜单和一堆内核日志。如果卡在引导阶段不动了，最常见的原因是引导设备没配对。这时候回到 PVE 检查虚拟机的boot顺序，确认 USB 或者引导盘在前：

qm set 200 --boot order=usb0;sata0

顺序写错了也没关系，进去 BIOS 改一下就行，PVE 的控制台里按 Esc 就能进 UEFI 设置界面。

引导成功之后，你会看到 UNRAID 的 Web 界面。第一次进去需要设置 root 密码，然后开始注册授权。这里就是前面强调引导设备的原因：授权是跟引导盘的唯一标识绑定的，你换一个引导设备，就得重新走一遍流程。所以一旦跑起来，就别随便动引导盘了。

如果你之前已经在别的地方用过 UNRAID，可以把导出的配置直接恢复进去，阵列布局、共享设置、Docker 容器都在里面。我迁移过一次，用配置备份恢复之后，除了磁盘顺序需要确认一遍，其他都是原样，省了大量重配时间。

6.2 建立阵列的顺序和校验盘的取舍

进入“主界面”，所有被识别到的磁盘会列出来。这时候你会看到“阵列操作”区域，需要给每块盘分配角色。

顺序是这样的：先选校验盘（如果有），再选数据盘。UNRAID 有个设计我得夸一下——阵列里的数据盘可以单独读取，这也是它和其他 RAID 方案最大的不同。就算校验盘挂了，你拔下任何一块数据盘插到别的机器上，都能直接读出里面的文件。这个特性在数据恢复场景下价值极高。

校验盘要不要配，我的建议是看数据重要性。如果你存的都是些能重新下载的影视资源，完全可以不配，省一块盘的钱和电。但如果有照片、文档、工作资料这类不可再生的数据，一块校验盘是底线。注意校验盘只提供一块盘损坏的容错，两块盘同时坏就救不回来了，所以重要数据还是要有异地备份。

阵列建立之后会有一个“奇偶校验”的过程，盘越多、容量越大，同步时间越长。8T 的盘大概要十几个小时，这个过程中不要动阵列，不要拔盘，让它跑完。

6.3 共享、用户和 Docker 的落地配置

阵列起来之后，先把共享建好。UNRAID 的共享概念比较直观：一个共享就是一个顶层目录，可以指定它使用哪块盘、是主存储还是缓存优先。我一般这样分：

• media：影视资源，直接放阵列，不用缓存
• documents：文档和照片，用缓存优先，写入快
• backup：备份目标，直接放阵列
• appdata：Docker 应用数据，必须放 SSD 缓存池，否则数据库类的容器会被机械盘拖死

appdata这一条尤其重要。刚开始我把 Docker 的 appdata 放在阵列上，结果一些用 SQLite 的容器响应慢得离谱，日志里全是 I/O 等待。后来移到 SSD 缓存池，问题立刻消失。

Docker 服务需要在设置里启用，还要指定镜像文件的位置。默认镜像放在/var/lib/docker，重启就没了，必须改到缓存池上，路径类似/mnt/cache/docker.img。虚拟机也建议放在缓存池，用 SSD 跑系统盘，体验完全不一样。

7. 踩坑实录：我在这个过程里遇到的五个坑

7.1 开机掉进 UEFI Shell，什么提示都没有

这是我遇到的第一个坑，表现是虚拟机启动后直接停在一个黑底白字的命令行界面上，像是个简易的 Shell，敲什么都没反应。当时以为是引导盘没做好，重新做了一遍还是这样。

排查过程是这样的：先在 PVE 控制台里按 Esc 进 UEFI 设置，看引导设备列表里有没有那个 U 盘。有，说明设备识别正常。然后在 UEFI 里手动执行引导，能看到 UNRAID 的启动菜单一闪而过又被踢回来。这时候我才想到安全启动的问题——果然，去看虚拟机的 EFI 磁盘配置，pre-enrolled-keys=1。

解决办法就是前面提过的，把 EFI 磁盘重建，指定pre-enrolled-keys=0：

qm set 200 --delete efidisk0 qm set 200 --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=0

重建 EFI 磁盘会清掉里面的 UEFI 变量，所以虚拟机的引导顺序之类设置会重置，记得重新配一遍。

7.2 阵列里磁盘显示“设备缺失”的几种原因

这个报错我在不同阶段遇到过三次，原因完全不同，值得单独说一下。

第一次是设备路径用了/dev/sdX，加了一块新盘之后顺序变了，UNRAID 认到的盘和记录的对不上。改成/dev/disk/by-id/之后问题消失，这也是我后来一直坚持用稳定路径的原因。

第二次是磁盘之前属于一个 ZFS 池，虽然我用zpool destroy删了池，但盘上还残留着 ZFS 的元数据标签，UNRAID 读盘的时候识别到了，判定这块盘“不属于阵列”。解决办法是用wipefs -a清掉盘上的所有签名：

wipefs -a /dev/disk/by-id/ata-XXX

注意：这条命令会清掉磁盘上的所有文件系统签名，执行前务必确认这块盘的数据已经不需要了，或者已经备份好了。

第三次比较隐蔽：我在 PVE 主机上不小心把这块盘挂载了一下（想看看里面有什么），结果挂载点虽然在重启后消失了，但/etc/fstab里留了一行记录，导致系统启动时尝试挂载已经分配给虚拟机的盘，两者抢设备，UNRAID 里就报设备缺失。教训是，分配出去的物理盘，在 PVE 主机上必须保持“完全不管”的状态，fstab里不能有任何相关记录。

7.3 网络时通时断，问题出在网卡型号和 MTU

有一段时间我发现 UNRAID 的 Web 界面偶尔打不开，但过一会儿又好了，ping也是断断续续。查了很久没找到原因，直到我在 PVE 里看虚拟机的网络流量，发现有大包超时的情况。

最后定位到两点。一是网卡型号用了e1000，在高负载下虚拟网卡的模拟开销比较大，容易出现丢包。换成virtio之后明显好转。二是 MTU 不一致，我在 PVE 的vmbr0上设了 jumbo frame，但 UNRAID 侧的网卡还是默认的 1500，导致大包传输时被丢弃。统一成 1500 之后就稳定了。

这个经验告诉我，虚拟化环境下的网络问题，先从“两端参数是否一致”查起，比一开始就怀疑硬件要高效得多。

7.4 快照和 UNRAID 阵列的相处方式

PVE 的快照功能很好用，但它只能快照虚拟磁盘，对直通的物理盘完全无能为力。我一开始没意识到这点，给 UNRAID 虚拟机做了个快照，然后改了些配置，想着出问题就回滚。结果回滚之后，虚拟机的引导配置回到了旧状态，但阵列里的数据盘还是新的，配置和数据对不上，UNRAID 报了一堆错。

正确的心态是：直通盘上的数据，快照保护不了。UNRAID 自己的配置备份（导入导出功能）才是可靠的保护手段，阵列数据的保护靠的是校验盘和外部备份。给跑 UNRAID 的虚拟机做快照，最多只能拿来保护引导配置，别指望它保护数据。

7.5 性能对不上，CPU 类型和缓存策略的影响

有段时间我总觉得 UNRAID 里的文件传输速度比裸机慢一截，测了一下大概差 20% 左右。排查下来有几个原因叠加。

CPU 类型从默认的kvm64改成host之后，压缩和校验计算的速度明显提升，因为host模式会透传主机的指令集扩展。磁盘缓存策略从writeback改成none配合aio=native，减少了双重缓存带来的开销。还有一个是内存给少了，ZFS 需要足够的内存做 ARC 缓存，我给到 16G 之后，热数据的读取速度提升非常明显。

处理完之后，性能差距缩小到 5% 以内，日常用基本感觉不到。所以如果你觉得虚拟化方案的性能不对劲，先别急着下结论说“虚拟化就是慢”，把这几项调一遍再测。

8. 长期维护：升级、备份和资源分配的经验

跑起来只是开始，长期稳定才是考验。我在两台机器上跑了三四年，总结了几条经验。

PVE 大版本升级之前，一定先把 UNRAID 虚拟机关机。PVE 升级过程会重启主机，如果虚拟机设了onboot=1，升级到一半的 PVE 可能还没准备好，虚拟机启动会出各种奇怪的问题。我现在养成的习惯是，升级前qm stop 200，升级完确认 PVE 正常，再手动启动。

引导盘的备份要定期做。UNRAID 界面里能导出配置压缩包，我一般每个月导一次，存到阵列里和外部存储各一份。这个文件包含了你所有的阵列布局、共享设置、用户和 Docker 配置，恢复起来比重新配一遍快太多。

资源分配上，别把 PVE 主机的资源榨干。如果你的 PVE 主机有 32G 内存，给 UNRAID 16G 是比较舒服的分配，留一部分给 PVE 自己和其他虚拟机。CPU 核心数也一样，UNRAID 的 ZFS 和校验计算是多线程的，核心给少了会拖慢，但给太多也没意义，4 到 6 个核心对家庭场景够用了。

还有一点，UNRAID 里的虚拟机功能我基本不用。既然已经在 PVE 上跑，虚拟机就统一在 PVE 里管理，网络、存储、备份策略都在一层里，比跨两层管理清晰。UNRAID 我只让它干两件事：管存储和跑 Docker。职责越单一，出问题的面就越小。

最后分享一个我用了很久的小技巧：把 UNRAID 的 Web 界面地址和 PVE 的管理地址都加进浏览器书签栏，再在 PVE 里给这台虚拟机加个描述，写清楚它用了哪些物理盘、直通方式是什么、引导盘是哪个 USB 设备。等你半年后再来看这台虚拟机，不至于对着配置发呆，重新翻一遍/etc/pve/qemu-server/200.conf才知道当初怎么设的。