PVE + Arc Loader 群晖部署:核显 SR-IOV、跨机型数据救援与 NVMe 存储池重建实录

发表于 分类于 阅读次数： 本文字数： 4.3k 阅读时长 ≈ 16 分钟

一次完整的 PVE 9.1 + DSM 7.2.2 (SA6400) 部署过程:从 SR-IOV 核显直通,到跨机型(SA6400 ↔ NAS-8100T)三盘数据迁移,再到突破 NVMe 兼容性限制重建存储池。包含所有踩坑点和最终方案。

目录

环境信息

硬件

组件 型号
CPU Intel Pentium Gold 8505 (Alder Lake-UP3, 12 代)
核显 UHD Graphics (Device ID 8086:46b3)
系统盘 Samsung SSD 980 1TB (nvme1n1,PVE 系统)
NAS 数据盘 1 Fanxiang S100Pro 256GB SATA SSD (sda)
NAS 数据盘 2 TOSHIBA HDWG740UZSVC 4TB HDD (sdb)
NAS 数据盘 3 Predator GM7 2TB NVMe (nvme0n1)

软件

组件 版本
Proxmox VE 9.1.1 (Debian 13 Trixie)
PVE 内核 7.0.2-2-pve(初始 6.17.2,后被 apt 升级)
Arc Loader 3.1.0
DSM 7.2.2-72806
模拟机型 SA6400 (Atom C3xxx, epyc7002 平台)

数据状态

三块 NAS 数据盘均含有重要数据:

  • sda(256G SSD)→ 来自 NAS-8100T 机型,标签 NAS-8100T:2
  • sdb(4T HDD)→ 来自 SA6400,标签 SA6400:3
  • nvme0n1(2T NVMe)→ 来自 SA6400,标签 SA6400:4,含 MyDocker (24G, 146905 文件) 和 HighSpeed (2.1G, 2032 文件)

核心需求:保留三块盘所有数据,启用核显硬解,跑 Docker 项目集合。

Part 1: PVE 9.1 SR-IOV 核显配置

1.1 安装 Proxmox 内核与 Headers

PVE 9 默认 ISO 安装后,只启用了企业订阅源,需切换到非订阅源才能装齐内核 headers。

报错示例

# 直接执行会失败
apt install proxmox-default-kernel proxmox-default-headers
# Error: Unable to locate package proxmox-default-headers

解决:配置非订阅源

PVE 9 使用 deb822 格式的 .sources 文件:

# 1. 禁用企业源(401 报错)
mv /etc/apt/sources.list.d/pve-enterprise.sources /etc/apt/sources.list.d/pve-enterprise.sources.disabled
mv /etc/apt/sources.list.d/ceph.sources /etc/apt/sources.list.d/ceph.sources.disabled

# 2. 添加非订阅源(中科大镜像,国内更快)
cat > /etc/apt/sources.list.d/pve-no-subscription.sources << 'EOF'
Types: deb
URIs: https://mirrors.ustc.edu.cn/proxmox/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

# 3. 更新 + 安装
apt update
apt install -y proxmox-default-kernel proxmox-default-headers

💡 关键:PVE 9 的 metapackage 是 proxmox-default-headers,不是 proxmox-headers-X.Y 直接拼接。

1.2 安装 i915 SR-IOV DKMS 模块

# 安装编译工具
apt install -y build-essential dkms sysfsutils

# 下载并安装 i915-sriov-dkms
wget -O /tmp/i915-sriov-dkms_2026.05.06_amd64.deb \
  "https://github.com/strongtz/i915-sriov-dkms/releases/download/2026.05.06/i915-sriov-dkms_2026.05.06_amd64.deb"
dpkg -i /tmp/i915-sriov-dkms_2026.05.06_amd64.deb

1.3 配置内核启动参数

编辑 /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on i915.enable_guc=3 i915.max_vfs=7 module_blacklist=xe"

参数说明:

参数 作用
intel_iommu=on 启用 Intel VT-d / IOMMU
i915.enable_guc=3 启用 GuC + HuC 固件加载(SR-IOV 必需)
i915.max_vfs=7 最多创建 7 个 VF(Intel UHD 上限)
module_blacklist=xe 禁用 xe 驱动,避免抢占

更新 GRUB 与 initramfs:

update-grub
update-initramfs -u

1.4 配置 sysfs 自动创建 VF

echo "devices/pci0000:00/0000:00:02.0/sriov_numvfs = 7" > /etc/sysfs.conf
systemctl enable --now sysfsutils

重启:

reboot

1.5 验证 SR-IOV 成功

# 应该看到 1 PF + 7 VF
lspci -nn | grep -i vga

# 期望输出:
# 00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-UP3 GT1 [UHD Graphics] [8086:46b3] (rev 0c)
# 00:02.1 VGA compatible controller [0300]: ...
# ... (.1 - .7 共 7 个 VF)

# 验证 VF 数量
cat /sys/devices/pci0000:00/0000:00:02.0/sriov_numvfs    # 应输出 7
cat /sys/devices/pci0000:00/0000:00:02.0/sriov_totalvfs  # 应输出 7

# 验证 IOMMU
dmesg | grep -e DMAR -e IOMMU

Part 2: 创建群晖 VM 并配置直通

2.1 创建 VM(关键参数)

PVE Web UI 创建 VM(假设 ID 100):

类别 配置
OS Do not use any media
System Machine: q35 / BIOS: OVMF (UEFI) / EFI Disk: ☑
Disks 删除默认磁盘,稍后手动添加
CPU Type: host / Cores: 4
Memory 12 GB(根据需求,禁用 Ballooning)
Network Bridge: vmbr0 / Model: Intel E1000

⚠️ 创建时不要勾“Start after created”。

2.2 导入 Arc Loader 引导镜像

# 把 arc.img 导入为 sata0(必须 SATA 引导)
qm importdisk 100 /root/arc.img local-lvm --format raw

# Web UI 把 Unused Disk 设置为 sata0
# 启动顺序:order=sata0
qm set 100 -boot order=sata0

2.3 三块盘 SATA 仿真直通

qm set 100 \
  -sata1 /dev/disk/by-id/ata-Fanxiang_S100Pro_256GB_MX_00000000000010031,ssd=1,discard=on \
  -sata2 /dev/disk/by-id/ata-TOSHIBA_HDWG740UZSVC_4550A014FX6J,discard=on \
  -sata3 /dev/disk/by-id/nvme-Predator_SSD_GM7_M.2_2TB_PSBH53380701353,ssd=1,discard=on

💡 NVMe 走 SATA 仿真直通的好处:配置简单,PVE 仍可访问。代价:DSM 看作 SATA SSD,不能用作真正的 NVMe 缓存。

2.4 添加核显 VF 直通

# 把 VF1(00:02.1)透传给 DSM
qm set 100 -hostpci0 0000:00:02.1,pcie=1

⚠️ 永远不要把 PF(00:02.0)透传给 VM,否则会让所有 VF 崩溃,整机核显挂掉。

2.5 启动前的最终配置确认

qm config 100

关键配置项:

balloon: 0
bios: ovmf
boot: order=sata0
cores: 4
cpu: host
hostpci0: 0000:00:02.1,pcie=1
machine: q35
sata0: local-lvm:vm-100-disk-1,size=1852M
sata1: /dev/disk/by-id/ata-Fanxiang...
sata2: /dev/disk/by-id/ata-TOSHIBA...
sata3: /dev/disk/by-id/nvme-Predator...

Part 3: Arc Loader 引导 DSM

3.1 关键决策:机型选择

SA6400 vs DS920+ 的权衡:

维度 SA6400 DS920+
老数据兼容性(我的 sdb/nvme0n1) ✅ 完美匹配 ❌ 机型不匹配,无法识别
原生 i915 核显硬解 ❌ 无 ✅ 支持
Docker + GPU 硬解(VAAPI/QSV) ✅ 通过 Docker 也能用 ✅
NVMe 作为存储池 ⚠️ 需要 nvmesystem addon ✅ 原生

最终选择 SA6400——保留旧数据优先,核显硬解走 Docker 容器路径。

3.2 Arc Loader 启动流程

启动 VM 后进入 Arc Loader 菜单:

qm start 100

Auto Mode 的特点

Auto Mode 会扫描已有盘的 RAID 标签自动选机型——正好我的盘标签是 SA6400:3 / SA6400:4,Arc 自动选了 SA6400,省了手动选择。

必须勾选的 Addons

通过 Webconfig (http://<VM_IP>:7080)操作 Addons 最方便。Arc 3.1.0 关键 addons:

Addon 状态 作用
acpid ✅ 默认 ACPI 电源管理
arcdns ✅ 默认 Arc DNS
cpuinfo ✅ 默认 显示真实 CPU 型号
hddb ✅ 默认 加 DSM 兼容性 + M.2 Volume
reducelogs ✅ 默认 减少日志
storagepanel ✅ 默认 存储面板增强
updatenotify ✅ 默认 更新通知
vmtools ✅ 默认 qemu-ga + open-vm-tools
nvmesystem ⚠️ 必须手动勾 让 NVMe 可作为存储池(关键!)
nvmevolume ⚠️ 必须手动勾 让 M.2 当 Volume 用

💡 第一次部署的最大坑:Auto Mode 不会自动启用 nvmesystem / nvmevolume,导致 NVMe 在 DSM 里完全看不到。改完 addons 后选 Rebuild Loader (existing) 重新打包(几分钟,不用重新下载 pat)。

3.3 DSM 启动后的初步状态

# /proc/mdstat
md3 : active raid1 sata3p5[0]              # sdb (4T 东芝)
md2 : active raid1 sata2p3[2]              # sda (256G SSD)
md1 : active raid1 sata3p2[0] sata2p2[3]   # DSM swap
md0 : active raid1 sata3p1[0] sata2p1[3]   # DSM 系统

# /dev/dri/
card0  renderD128                          # ✅ 核显硬解可用!
  • ✅ Volume1 (256G SSD) 自动恢复
  • ✅ Volume2 (4T HDD) 自动恢复
  • ✅ 核显 /dev/dri/renderD128 在(Auto Mode 居然加了 i915)
  • ❌ Volume3 (NVMe) 显示「丢失」

Part 4: 数据救援(关键章节)

4.1 问题诊断

进入 DSM 存储管理器,看到:

存储池 3 - 丢失
RAID 类别:Synology Hybrid RAID (SHR) (无数据保护)
必需硬盘信息:M.2 硬盘 1 (SSD), HS/MAXIO - Predator SSD GM7 M.2 2TB (1.9 TB)

关键的 SSH 诊断(在 DSM 内执行):

ls /dev/nvme*
# 输出:/dev/nvme-fabrics  (没有 nvme0n1!)

真相揭示

由于 PVE 走的是 SATA 仿真直通,DSM 内核根本没识别为 NVMe 物理设备,而是把它当作普通 SATA 盘:

fdisk -l 2>/dev/null | grep "Disk /dev"
# Disk /dev/sata2: 238.5 GiB   ← sda (256G SSD)
# Disk /dev/sata3: 3.7 TiB     ← sdb (4T HDD)
# Disk /dev/sata4: 1.9 TiB     ← nvme0n1 (2T NVMe!) ⭐

NVMe 在 DSM 里是 /dev/sata4,不是 /dev/nvme0n1。

4.2 验证数据完整性(只读)

# 看分区表
fdisk -l /dev/sata4
# /dev/sata4p1   8G    Linux raid autodetect  ← 原 SA6400 系统
# /dev/sata4p2   2G    Linux raid autodetect  ← 原 swap
# /dev/sata4p5   1.9T  Linux raid autodetect  ← 数据分区!

# 验证 RAID 元数据(关键)
mdadm --examine /dev/sata4p5
# Name : SA6400:4
# State : clean
# Array Size : 1989673280 KiB (1897.50 GiB)
# Checksum : f4c031d6 - correct  ✅

4.3 三层只读组装挂载

整个救援流程的核心,确保绝对只读:

mount /mnt/rescue (ro)            ← 第 1 道:挂载 ro
    ↓
/dev/vg3/volume_3 (LV)            ← LVM 层
    ↓
/dev/md10 (read-only)             ← 第 2 道:md readonly 拒绝任何写
    ↓
/dev/sata4p5 (NVMe 物理分区)      ← 数据原位置,绝不被改

第一步:只读组装 RAID

mdadm --assemble --readonly /dev/md10 /dev/sata4p5
# mdadm: /dev/md10 has been started with 1 drive.

cat /proc/mdstat | grep md10
# md10 : active (read-only) raid1 sata4p5[0]

第二步:看文件系统类型

blkid /dev/md10
# /dev/md10: UUID="BoDCIL-..." TYPE="LVM2_member"

是 LVM,需要进一步处理。

第三步:激活 vg3 中的 LV

vgchange -ay vg3
#   2 logical volume(s) in volume group "vg3" now active

lvs vg3
#   volume_3              vg3  -wi-a-----  1.85t

blkid /dev/vg3/volume_3
# /dev/vg3/volume_3: LABEL="2025.07.06-08:36:47 v72806" TYPE="btrfs"  ← Btrfs!

💡 DSM 的 vgchange 不支持 --readonly 选项,但底层 md 是 readonly,任何写穿透都会被拒绝,依然安全。

第四步:挂载 Btrfs

mkdir -p /mnt/rescue
mount -t btrfs -o ro /dev/vg3/volume_3 /mnt/rescue
ls /mnt/rescue/
# 看到 MyDocker  HighSpeed  @eaDir  #recycle  ✅

4.4 抢救数据到 volume2

mkdir -p /volume2/rescue_volume3

rsync -avh --progress /mnt/rescue/MyDocker  /volume2/rescue_volume3/
rsync -avh --progress /mnt/rescue/HighSpeed /volume2/rescue_volume3/

# 验证
echo "原 MyDocker:  $(find /mnt/rescue/MyDocker -type f | wc -l)"
echo "新 MyDocker:  $(find /volume2/rescue_volume3/MyDocker -type f | wc -l)"
echo "原 HighSpeed: $(find /mnt/rescue/HighSpeed -type f | wc -l)"
echo "新 HighSpeed: $(find /volume2/rescue_volume3/HighSpeed -type f | wc -l)"

救援结果

项目 原数据 已复制 状态
MyDocker 24G / 146,905 文件 24G / 146,905 文件 ✅
HighSpeed 2.1G / 2,032 文件 2.1G / 2,032 文件 ✅

100% 完整恢复,MD5/文件数完全一致。

4.5 卸载临时挂载

umount /mnt/rescue
vgchange -an vg3
mdadm --stop /dev/md10

Part 5: NVMe 兼容性突破与存储池重建

5.1 第一次创建存储池失败

数据救出来后,尝试在 DSM 里重新创建存储池 3,结果:

硬盘要求 - 无法选择以下硬盘:
硬盘 3 / SATA / SSD / 1.9 TB / 良好
原因:当前 DSM 版本不支持此硬盘

SA6400 是企业机型,默认硬件兼容性数据库(hddb)较严格。直通的 NVMe 在 DSM 看来是 QEMU HARDDISK 2.5+,不在白名单。

cat /sys/block/sata4/device/vendor   # QEMU
cat /sys/block/sata4/device/model    # HARDDISK
cat /sys/block/sata4/device/rev      # 2.5+

5.2 用 syno_hdd_db 自动加白名单

社区工具 Synology_HDD_db(007revad)专门解决这个问题:

cd /root
wget -O syno_hdd_db.sh \
  "https://raw.githubusercontent.com/007revad/Synology_HDD_db/main/syno_hdd_db.sh"
chmod +x syno_hdd_db.sh

# -n 包含 NVMe / -r 重启相关服务 / -f 强制更新
./syno_hdd_db.sh -nrf

输出:

Synology_HDD_db v3.6.125
SA6400 x86_64 DSM 7.2.2-72806-3
HDD/SSD models found: 3
HARDDISK,2.5+,2048 GB
HARDDISK,2.5+,256 GB
HARDDISK,2.5+,4000 GB
HARDDISK (2.5+) already exists in sa6400_host_v7.db   ✅
Disabled support disk compatibility.                  ✅
NVMe support already enabled.                         ✅
Drive db auto updates already disabled.               ✅

5.3 第二次失败:盘上有 RAID 残留

reboot 后再次创建,**仍然报”不支持”**。原因:之前删除”丢失”的存储池只是清除 DSM 配置,NVMe 物理盘上的 RAID superblock + LVM 元数据还在:

mdadm --examine /dev/sata4p5
# 元数据还在,DSM 把它视为「已被使用」

5.4 彻底擦除 NVMe 元数据

⚠️ 执行前再三确认 /volume2/rescue_volume3/ 数据备份完整。

# 1. 停 LVM/RAID 引用
vgchange -an vg3 2>/dev/null
vgremove -y vg3 2>/dev/null
pvremove -y /dev/md10 2>/dev/null

# 2. 擦除 RAID superblock
for p in /dev/sata4p1 /dev/sata4p2 /dev/sata4p5; do
    mdadm --zero-superblock "$p" 2>/dev/null
done

# 3. 擦除分区表头部 100MB
dd if=/dev/zero of=/dev/sata4 bs=1M count=100 conv=fsync

# 4. 擦除盘尾 100MB(GPT 备份头位置)
DISK_SIZE=$(blockdev --getsize64 /dev/sata4)
SEEK_MB=$(( (DISK_SIZE / 1024 / 1024) - 100 ))
dd if=/dev/zero of=/dev/sata4 bs=1M count=100 seek=$SEEK_MB conv=fsync

# 5. 刷新分区表
partprobe /dev/sata4
sync

# 6. 让 DSM 重新扫描
synodiskpath --enum
synospace --enum

# 7. 重启 DSM
reboot

5.5 创建新存储池 3 + Volume3

DSM 重启后,Web UI 操作:

  1. 存储管理器 → 存储池 → 创建 → RAID 类型 Basic → 选 硬盘 3(无红字!) → 跳过硬盘检查 → 应用
  2. 存储空间 → 创建 → 选刚建的存储池 3 → 文件系统 Btrfs → 应用

完成后 /volume3 自动挂载,1.85T 可用。

5.6 创建共享文件夹

控制面板 → 共享文件夹 → 新增:

  • MyDocker / 位置:volume3 / 不加密 / 不启用回收站
  • HighSpeed / 位置:volume3 / 不加密 / 不启用回收站

Part 6: 数据迁移到 Volume3

6.1 跨卷复制

ssh admin@<DSM_IP>
sudo -i

# rsync 复制(Btrfs → Btrfs,跨卷必须 cp/rsync,mv 不行)
rsync -avh --progress /volume2/rescue_volume3/MyDocker/  /volume3/MyDocker/
rsync -avh --progress /volume2/rescue_volume3/HighSpeed/ /volume3/HighSpeed/

# 修复权限和 ACL
synoacltool -enforce-inherit /volume3/MyDocker
synoacltool -enforce-inherit /volume3/HighSpeed

💡 注意 rsync 末尾的 /:MyDocker/ → MyDocker/ 是复制内容到目标内,避免双层嵌套。

6.2 验证一致性

echo "===== 大小对比 ====="
du -sh /volume2/rescue_volume3/MyDocker /volume2/rescue_volume3/HighSpeed
du -sh /volume3/MyDocker /volume3/HighSpeed

echo "===== 文件数对比 ====="
echo "rescue MyDocker:  $(find /volume2/rescue_volume3/MyDocker -type f | wc -l)"
echo "volume3 MyDocker: $(find /volume3/MyDocker -type f | wc -l)"
echo "rescue HighSpeed: $(find /volume2/rescue_volume3/HighSpeed -type f | wc -l)"
echo "volume3 HighSpeed:$(find /volume3/HighSpeed -type f | wc -l)"

6.3 清理临时副本

rm -rf /volume2/rescue_volume3/
df -h /volume2  # 看空间释放

6.4 Container Manager 恢复 Docker 项目

MyDocker 含原 SA6400 的所有 docker-compose 项目。在 Container Manager 重新导入:

# 找所有 compose 文件
find /volume3/MyDocker -name "docker-compose.yml" -o -name "compose.yml"

每个项目目录:

  1. Container Manager → 项目 → 新增
  2. 项目目录:对应的 /volume3/MyDocker/<项目>
  3. 来源:使用现有的 docker-compose.yml
  4. 启动

最终 19 个容器全部恢复运行:

server-management-frontend-prod   server-management-backend-prod
webhook                            lucky                            filebrowser
gitea                              shared-postgres                  termix
guacd                              frps                             homeassistant
embyserver                         openlist                         haproxy
nginx                              frpc                             aliyundrive-webdav
it-tools                           nexterm                          qbittorrent

踩坑点与经验总结

🐛 坑 1:PVE 9 包名变了

错误 正确
proxmox-headers-6.17.2-1-pve proxmox-default-headers
proxmox-headers-6.17 proxmox-default-headers(metapackage)
apt install pve-headers 不存在,改用 proxmox-headers-$(uname -r)

🐛 坑 2:PVE 9 默认只启用企业源

ISO 安装后,apt update 直接报 401 Unauthorized。必须切换到 pve-no-subscription 源。

deb822 格式的源文件没有 Enabled 字段就是默认启用,要禁用必须显式加 Enabled: false 或重命名文件。

🐛 坑 3:Auto Mode 不会启用 nvmesystem

Arc Loader 的 Auto Mode 很智能(自动选机型 SA6400 太精准),但不会自动加 nvmesystem / nvmevolume addon。不加这俩,SA6400 的 NVMe 在 DSM 里完全看不到。

解决:Webconfig (:7080) → Addons → 手动勾选 → Rebuild Loader (existing)。

🐛 坑 4:NVMe 在 DSM 里不是 nvme0n1

走 SATA 仿真直通后,DSM 内核完全不认识 NVMe,把它识别为 /dev/sata4(按 SATA 槽位编号)。导致直接执行 mdadm --examine /dev/nvme0n1p5 报 “No such file or directory”。

正确做法:用 fdisk -l 看所有 sata 设备,找容量匹配的那一个。

🐛 坑 5:vgchange 不支持 –readonly

DSM 自带的 LVM2 工具版本不支持 vgchange --readonly 选项。

解决:用 vgchange -ay vg3(底层 md 已是 readonly,LV 即使激活为 RW 也无法穿透写入)。

🐛 坑 6:syno_hdd_db 不够,还要清盘

仅运行 syno_hdd_db.sh 加白名单不够——盘上残留的 RAID superblock 和 LVM 元数据会让 DSM 仍然拒绝使用。

完整清理三步:

  1. mdadm --zero-superblock 擦 RAID 元数据
  2. dd 擦盘头 100MB(分区表 + LVM PV)
  3. dd 擦盘尾 100MB(GPT 备份头)

🐛 坑 7:跨卷迁移用 mv 不行

Btrfs(volume2)→ Btrfs(volume3)是两个独立文件系统,mv 只是 inode 指针,跨文件系统时实际仍在做复制,但中断后状态不可预期。

正确做法:rsync -avh --progress,可断点续传 + 进度可见。

✅ 经验 1:三层只读保护

数据救援时坚持”双保险”:

  • mount 层:-o ro
  • md 层:mdadm --assemble --readonly

任何一层 readonly 都能阻止穿透写入,数据万无一失。

✅ 经验 2:先备份再清盘

每次执行破坏性操作(zero-superblock、dd、vgremove)之前:

  • 确认数据已 rsync 到其他卷
  • 确认目标卷数据完整(大小 + 文件数)
  • 才执行擦除

✅ 经验 3:Arc Loader 的 Webconfig 是神器

http://<VM_IP>:7080 提供完整的 Web 界面操作 Addons、Sysinfo、Filemanager,比 noVNC 里的 ncurses 菜单方便 10 倍。

✅ 经验 4:跨机型救援可行性

  • 同机型(SA6400 ↔ SA6400):✅ 完美,DSM 自动识别恢复
  • 跨同代机型(SA6400 ↔ DS920+):⚠️ 需要手动 mdadm,可能成功
  • 跨平台(SA6400 ↔ NAS-8100T):⚠️ 取决于 RAID 元数据是否标准,本案例中 sda 也成功识别

附录:关键命令速查

PVE 主机侧

# 切换到非订阅源(中科大)
cat > /etc/apt/sources.list.d/pve-no-subscription.sources << 'EOF'
Types: deb
URIs: https://mirrors.ustc.edu.cn/proxmox/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

# 安装内核 + headers
apt install -y proxmox-default-kernel proxmox-default-headers

# 验证 SR-IOV
lspci -nn | grep -i vga
cat /sys/devices/pci0000:00/0000:00:02.0/sriov_numvfs

# VM 配置查看与修改
qm config 100
qm set 100 -boot order=sata0 -cores 4
qm set 100 -hostpci0 0000:00:02.1,pcie=1
qm start 100
qm shutdown 100
qm status 100

# 直通磁盘(by-id 路径,稳定不变)
qm set 100 -sata1 /dev/disk/by-id/<id>,ssd=1,discard=on

DSM 内(数据救援)

# 1. 找 NVMe 真实设备节点
fdisk -l 2>/dev/null | grep "Disk /dev/sata"

# 2. 看 RAID 元数据
mdadm --examine /dev/sata4p5

# 3. 只读组装
mdadm --assemble --readonly /dev/md10 /dev/sata4p5

# 4. 激活 LVM
vgchange -ay vg3

# 5. 看文件系统
blkid /dev/vg3/volume_3

# 6. 只读挂载
mkdir -p /mnt/rescue
mount -t btrfs -o ro /dev/vg3/volume_3 /mnt/rescue

# 7. 救数据
rsync -avh --progress /mnt/rescue/重要目录/ /volume2/backup/

# 8. 清理
umount /mnt/rescue
vgchange -an vg3
mdadm --stop /dev/md10

DSM 内(兼容性 + 清盘)

# 加白名单
wget -O syno_hdd_db.sh \
  "https://raw.githubusercontent.com/007revad/Synology_HDD_db/main/syno_hdd_db.sh"
chmod +x syno_hdd_db.sh
./syno_hdd_db.sh -nrf

# 彻底清盘(谨慎!)
mdadm --zero-superblock /dev/sata4p1 /dev/sata4p2 /dev/sata4p5
dd if=/dev/zero of=/dev/sata4 bs=1M count=100 conv=fsync
DISK_SIZE=$(blockdev --getsize64 /dev/sata4)
SEEK_MB=$(( (DISK_SIZE / 1024 / 1024) - 100 ))
dd if=/dev/zero of=/dev/sata4 bs=1M count=100 seek=$SEEK_MB conv=fsync
partprobe /dev/sata4
synodiskpath --enum
reboot

DSM 内(数据迁移与权限)

# 跨卷复制(必须 rsync,不能 mv)
rsync -avh --progress /volume2/source/ /volume3/dest/

# 修复 ACL
synoacltool -enforce-inherit /volume3/MyDocker

# 验证一致性
echo "原: $(find /volume2/source -type f | wc -l)"
echo "新: $(find /volume3/dest -type f | wc -l)"

最终成果

  • ✅ PVE 9.1 + Alder Lake 核显 SR-IOV(7 个 VF)
  • ✅ DSM 7.2.2 (SA6400) 通过 Arc Loader 正常引导
  • ✅ 三块盘数据全部保留(同机型 SA6400 + 异机型 NAS-8100T 均成功)
  • ✅ NVMe 兼容性突破,作为独立 Volume3 (Btrfs, 1.85T)
  • ✅ MyDocker 24G / 146905 文件 / HighSpeed 2.1G / 2032 文件,100% 完整迁移
  • ✅ 19 个 Docker 容器全部恢复运行
  • ✅ 核显在 DSM 内可用(/dev/dri/renderD128),Docker 容器可走 VAAPI/QSV 硬解

致谢:

文档创建时间:2026-05-10