请不要把任何和邀请码有关的内容发到 NAS 节点。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
注意：由于本人文笔一般 以下信息本人通过 ai 进行润色整理
最近在折腾 Unraid 虚拟化环境下使用 GVT-g 给多个虚拟机共享核显，整体目标是让不同系统（ Windows / FNOS ）都能调用 Intel 核显进行硬件加速。
在实际过程中，DSM 和 Windows 基本“开箱即用”，但 FNOS 却踩了不少坑，这里做一个完整记录，给有类似需求的朋友一个参考。
一、环境说明
宿主系统：Unraid
核显方案：Intel GVT-g
虚拟机系统：
DSM （群晖）
Windows
FNOS
二、问题现象
在使用 GVT-g 插件分配核显时：
DSM ✅ 正常
Windows ✅ 正常
FNOS ❌ 直接报错，无法进入系统
三、问题分析 & 解决过程
这个问题并不是单一原因导致，而是多个因素叠加，我分阶段排查出来：
1️⃣ FNOS 镜像版本问题（关键坑）
我最开始使用的是：
FNOS 0.8 早期版本 ISO
结果：
一旦分配 GVT-g 核显 → 直接无法启动
后来测试发现：
👉 问题本质：引导 + 内核版本过旧
不仅 FNOS：
Debian 老版本也存在同样问题
✅ 解决方案：
更换 最新版本 FNOS ISO 镜像
✔️ 结果：
不再报错，可以正常启动虚拟机
⚠️ 但此时：
👉 仍然无法真正调用核显（只是“不报错”）
2️⃣ Unraid VM XML 配置问题（核心关键点）
当虚拟机能正常启动后，我开始排查为什么核显无法被识别。
查阅 FNOS 论坛后发现，需要手动修改 fons 虚拟机的 XML 配置。
找到 <hostdev> 节点，修改为：
<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci' display='off'>
<source>
<address uuid='4b30e853-b3f0-4056-8511-5677dcbe4003'/>
</source>
<alias name='hostdev0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
</hostdev>
⚠️ 关键点：
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' .../>
👉 这一行是关键中的关键！
为什么重要？
FNOS 对 PCI 设备位置有“隐式依赖”：
默认期望核显出现在 00:02.0
如果不手动指定：
会识别失败
3️⃣ i915 驱动参数问题（最终生效关键）
即使前两步完成，FNOS 仍然可能无法正常使用核显。
最终还需要修改 i915 驱动参数：
ssh 登录 fnos 系统后台，使用 root 权限进行如下操作
echo "options i915 enable_guc=0" > /etc/modprobe.d/i915.conf
update-initramfs -u
reboot
⚠️ 为什么要这样做？
GVT-g 环境下：
enable_guc 默认开启可能导致冲突
关闭后：
i915 更稳定
核显才能正常工作
四、最终效果
完成以上三步后：
系统 核显状态
Windows ✅ 正常
FNOS ✅ 正常
👉 成功实现：
多虚拟机共享核显
硬件加速正常调用
注意：
unraid 下的核显虚拟化有可能会导致 windows 虚拟机长时间运行卡死，导致 cpu 占用率其高，最终无法登录 unraid 的 webui 的情况。
我现在的解决办法是 windows 虚拟机内装了个定时关机插件，每天到凌晨 2 点关闭 windows 虚拟机，要用的时候再启动，目前稳定使用一年没出现过问题
最近在折腾 Unraid 虚拟化环境下使用 GVT-g 给多个虚拟机共享核显，整体目标是让不同系统（ Windows / FNOS ）都能调用 Intel 核显进行硬件加速。
在实际过程中，DSM 和 Windows 基本“开箱即用”，但 FNOS 却踩了不少坑，这里做一个完整记录，给有类似需求的朋友一个参考。
一、环境说明
宿主系统：Unraid
核显方案：Intel GVT-g
虚拟机系统：
DSM （群晖）
Windows
FNOS
二、问题现象
在使用 GVT-g 插件分配核显时：
DSM ✅ 正常
Windows ✅ 正常
FNOS ❌ 直接报错，无法进入系统
三、问题分析 & 解决过程
这个问题并不是单一原因导致，而是多个因素叠加，我分阶段排查出来：
1️⃣ FNOS 镜像版本问题（关键坑）
我最开始使用的是：
FNOS 0.8 早期版本 ISO
结果：
一旦分配 GVT-g 核显 → 直接无法启动
后来测试发现：
👉 问题本质：引导 + 内核版本过旧
不仅 FNOS：
Debian 老版本也存在同样问题
✅ 解决方案：
更换 最新版本 FNOS ISO 镜像
✔️ 结果：
不再报错，可以正常启动虚拟机
⚠️ 但此时：
👉 仍然无法真正调用核显（只是“不报错”）
2️⃣ Unraid VM XML 配置问题（核心关键点）
当虚拟机能正常启动后，我开始排查为什么核显无法被识别。
查阅 FNOS 论坛后发现，需要手动修改 fons 虚拟机的 XML 配置。
找到 <hostdev> 节点，修改为：
<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci' display='off'>
<source>
<address uuid='4b30e853-b3f0-4056-8511-5677dcbe4003'/>
</source>
<alias name='hostdev0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
</hostdev>
⚠️ 关键点：
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' .../>
👉 这一行是关键中的关键！
为什么重要？
FNOS 对 PCI 设备位置有“隐式依赖”：
默认期望核显出现在 00:02.0
如果不手动指定：
会识别失败
3️⃣ i915 驱动参数问题（最终生效关键）
即使前两步完成，FNOS 仍然可能无法正常使用核显。
最终还需要修改 i915 驱动参数：
ssh 登录 fnos 系统后台，使用 root 权限进行如下操作
echo "options i915 enable_guc=0" > /etc/modprobe.d/i915.conf
update-initramfs -u
reboot
⚠️ 为什么要这样做？
GVT-g 环境下：
enable_guc 默认开启可能导致冲突
关闭后：
i915 更稳定
核显才能正常工作
四、最终效果
完成以上三步后：
系统 核显状态
Windows ✅ 正常
FNOS ✅ 正常
👉 成功实现：
多虚拟机共享核显
硬件加速正常调用
注意：
unraid 下的核显虚拟化有可能会导致 windows 虚拟机长时间运行卡死，导致 cpu 占用率其高，最终无法登录 unraid 的 webui 的情况。
我现在的解决办法是 windows 虚拟机内装了个定时关机插件，每天到凌晨 2 点关闭 windows 虚拟机，要用的时候再启动，目前稳定使用一年没出现过问题
 |
1
WizardLeo 6 小时 26 分钟前
建议去 unraid 论坛中文板块发帖，方便后来者找资料。
|
Select Language