本文以 N5105/Jasper Lake 为背景说明 PVE LXC 核显直通。PVE 8.1 提供设备参数、8.2 起提供对应图形界面；设备权限、驱动与固件要求需按实际硬件核对。
LXC 与宿主机共享内核。这里让容器访问宿主机的 DRI 设备节点，并不是把整块 PCI 显卡独占交给虚拟机；宿主机仍使用 Intel 驱动。GPU 的编码、解码和色调映射是不同能力，不能因为 /dev/dri 出现就认定整个转码流程已加速。
一、检查 PVE 宿主机
lspci -k | grep -A3 -E 'VGA|Display'
ls -l /dev/dri
uname -r
journalctl -b -k | grep -Ei 'i915|drm|dmc|guc|huc'
原 N5105 输出示例：
00:02.0 VGA compatible controller: Intel Corporation JasperLake [UHD Graphics]
Kernel driver in use: i915
crw-rw---- 1 root video 226, 0 ... card0
crw-rw---- 1 root render 226, 128 ... renderD128
检查实际的 render 节点，多个 GPU 的编号可能不同。N5105 不支持 AV1 硬件编解码。当前 Jellyfin 文档也提示，Jasper Lake 的 Linux QSV 依赖已弃用的 Intel MediaSDK；如新版运行时不再支持，应改用 VA-API，而不是假设 QSV 会长期兼容。Intel 硬件加速文档
低功耗编码与 HuC 固件
普通硬件解码与启用 Intel Low-Power 编码不是同一件事。先检查日志是否存在固件缺失或 HuC 认证失败。固件文件名随内核、固件包和硬件变化，并非所有机器都需要或提供 ehl_guc_70.1.1.bin。
对于仍使用 i915、且官方文档要求手动加载 HuC 的旧代核显，可在确认没有重复或冲突的设置后，编辑 /etc/modprobe.d/i915.conf：
options i915 enable_guc=2
enable_guc=3 不适合作为所有 Intel GPU 的统一设置。部分新 GPU 已默认启用相关功能；使用 xe 驱动的 GPU 也不适用此 i915 参数。需要修改时更新启动镜像，然后单独重启：
update-initramfs -u
# 使用 GRUB 的主机更新 GRUB；其他引导方式按 PVE 引导文档处理
update-grub
reboot
重新连接后再检查，而不是写成 reboot && uname -r：
uname -r
journalctl -b -k | grep -Ei 'i915|guc|huc|firmware'
原机器成功时的关键日志为：
GT0: GuC firmware i915/ehl_guc_70.1.1.bin version 70.1.1
GT0: HuC firmware i915/ehl_huc_9.0.0.bin version 9.0.0
GT0: HuC: authenticated for all workloads
只有看到相关固件和认证成功，才考虑开启低功耗编码；日志中仅出现 GuC/HuC 字样也可能是在报错。内核更新使用与当前 PVE 大版本匹配的官方仓库，不把“内核至少 5.19”当作所有 N5105 场景的最低要求。PVE 引导管理
二、把 render 设备交给 LXC
PVE 8.1 的设备参数与 8.2 起的图形界面
dev[n] 设备参数从 PVE 8.1 提供，资源页面的设备直通入口从 8.2 提供；8.1 使用 API/CLI，8.0 不能直接照抄此项。Proxmox 8.2 官方发布说明
优先保留非特权容器。以 root 登录 PVE，在容器的 资源 → 添加 → 设备直通 中选择实际的 /dev/dri/renderD128，高级选项里的 GID 填写容器内部设备使用组的数字 ID。先查询：
pct config 104
pct exec 104 -- getent group render
例如容器内 render 组 GID 是 106 时，对应配置类似：
dev0: /dev/dri/renderD128,gid=106,mode=0660
106 只是示例，必须换成自己的结果；若已有 dev0，应使用空闲编号。通常转码只需要 render 节点，额外 card 节点只在确有需要时添加。配置生效后在容器内检查设备权限，原生安装 Jellyfin 时将服务用户加入对应组，并重启服务以取得新组权限。
PVE 7 的旧配置
PVE 7 已结束支持。仅为维护旧环境保留以下原理示例；优先规划升级。旧版手工配置应限制到实际设备：
lxc.cgroup2.devices.allow: c 226:128 rwm
lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file
r/w/m 分别代表读、写、创建设备节点（mknod），其中 m 不是“映射”。不需要为了这一个设备清空 capability 限制、把 AppArmor 设置为 unconfined、或允许所有设备。
不能直接把既有容器的 unprivileged: 1 改成 0。 非特权容器的磁盘 UID/GID 已做映射，直接改标志可能使数据权限错误。确需在旧版使用特权容器时，应先备份、按支持的方法恢复成新的特权容器，再检查文件所有者与业务；当前官方文档给出的旧版转换方式也是备份后恢复。Jellyfin 的 PVE 配置说明、pct 设备参数
三、容器内安装 Jellyfin
安装、缓存、字体和插件配置使用 LinuxServer 镜像示例。官方 jellyfin/jellyfin 也支持 Intel 硬件加速，不能笼统认为需要第三方“优化版”才支持 Intel GPU。
LXC 中再运行 Docker 时，设备要继续传入 Docker：
--device=/dev/dri/renderD128:/dev/dri/renderD128
这是 docker run 参数，不是 YAML。LinuxServer 镜像会处理其 abc 用户的设备组权限；其他镜像可能需要将 render 节点的数字 GID 加入补充组。LXC 的 nesting/keyctl 与 Docker 兼容性单独按 PVE 文档设置，不用一组取消隔离的参数来兜底。
LinuxServer 镜像的 OpenCL 色调映射模块按其维护者说明添加：
-e DOCKER_MODS="linuxserver/mods:jellyfin-opencl-intel"
OpenCL 是 HDR/DV→SDR 色调映射的一种方法，不能把这个环境变量解释为所有 Intel 解码加速的必要条件。QSV VPP 的适用硬件和能力也不同，应按实际硬件和驱动验证支持情况。LinuxServer 镜像说明
以下截图是 2024 年界面的操作记录，当前选项位置可能变化：
四、验证实际转码
在 Jellyfin 后台选 QSV 或 VA-API，按硬件能力勾选编码格式、填入正确的 render 路径。先测试普通 H.264/HEVC，再测试 HDR 色调映射，低功耗编码最后单独验证。
用客户端降低码率或分辨率，明确触发转码；直接播放通常不会使用服务端转码引擎。检查 FFmpeg 日志中的硬件解码器、编码器、滤镜和错误，再在宿主机用 intel_gpu_top 观察 Video/VideoEnhance 等引擎活动。ls -l /dev/dri、lspci 和容器能启动只证明部分前提，不是硬件转码验收。
评论区