[sanity-check requested] iGPU passthrough to privileged Debian 12 LXC

Tommmii

Well-Known Member
Jun 11, 2019
71
13
48
54
I'm preparing for a migration for Proxmox from a system based on dual Xeon L5640 to a system running a i7-6700T. (don't ask).

One of the containers is a Plex media server.
The Xeons have no iGPU, but never had any issues with transcoding. 24 cores FTW !!! :cool:
The i7 needs the iGPU to lend a helping hand while transcoding, or it's "All aboard for the express to CPU-meltdown-ville !!".
So it's iGPU passthrough setup for the first time, for me. :eek:

Here's what I've got, and I believe it works. Given htop output & Plex dashboard transcoding graphs & intel_gpu_top numbers while transcoding.


My Notes on iGPU passthrough from Proxmox host to an LXC:

On the Proxmox host we have :
Code:
root@pve:~# ls -l /dev/dri
total 0
drwxr-xr-x 2 root root         80 Feb 15 09:29 by-path
crw-rw---- 1 root video  226,   0 Feb 15 09:29 card0
crw-rw---- 1 root render 226, 128 Feb 15 09:29 renderD128

So, I'm concluding the LXC's video group will need access to card0 , and the render group access to renderD128. Right ?

Obtain these groupids inside the LXC by doing :
Code:
cat /etc/group | grep -E "video|render"
video:x:44:plex
render:x:106:plex
Hmm, that's handy, user plex is already member of those groups.

44 is the groupid for group 'video' inside the lxc,
and 106 is the groupid for group 'render' inside the lxc.

Using the GUI, in the LXC's Resources we add Device Passthroughs :
Code:
dev0: /dev/dri/card0,gid=44
dev1: /dev/dri/renderD128,gid=106

In humanspeak, do these lines mean "allow the container's gid 44 access to host device /dev/dri/card0",
and "allow the container's gid 106 access to host device /dev/dri/renderD128" ?
We don't care about the GIDs on the host, only about what group in the container has access to the device (grp video has access to card0, grp render can access renderD128) ?



These are the only steps I took, and things just seem to function.
No drivers in the LXC nor on the host, no faffing about in grub or uefi bootloader, no nothing .

Something that struck me as odd, and I'd like to know what happened is this :
Accidentally I swapped the GIDs for the device mounts, I gave card0 gid 106, and renderD128 gid 44.
Things still worked. I tested it many times, swapping the gids around... iGPU was still functional in the LXC, regardless.
Why ?? o_O

Besides putting this online for the instruction & entertainment of others, I would love it of you could comment on this... perhaps I've overlooked something ?
Thanks for reading this long post all the way to here & thank you for any input !!
Tom.
 
Last edited:
Just curious if the container instance has the uidmap package installed? I have seen where uid/gid mappings are ignored when that package is not installed on other platforms - so was just curious. Maybe the gid mapping is just ignored?
 
Just curious if the container instance has the uidmap package installed?
My unprivileged Ubuntu container does not have it installed but the devices do get the video group. For example dev0: /dev/dvb/adapter0/demux0,gid=44,uid=0 gives crw-rw---- 1 root video 212, 1 feb 15 09:07 demux0
Accidentally I swapped the GIDs for the device mounts, I gave card0 gid 106, and renderD128 gid 44.
Things still worked. I tested it many times, swapping the gids around... iGPU was still functional in the LXC, regardless.
Why ?? o_O
Your plex user is a member of of both groups. It therefore probably does not matter which of the two groups is used for any device; the plex user can still access it (because it belongs to the group either way).
 
  • Like
Reactions: dj423
Just curious if the container instance has the uidmap package installed? I have seen where uid/gid mappings are ignored when that package is not installed on other platforms - so was just curious. Maybe the gid mapping is just ignored?
uidmap doesn't seem to be installed.


Your plex user is a member of of both groups. It therefore probably does not matter which of the two groups is used for any device; the plex user can still access it (because it belongs to the group either way).
That would make total sense ! Dankuwel for the insight.