maur5 · November 17, 2024 04:51 · Apr 7, 2024 · Apr 6, 2024 · Apr 5, 2024 · Apr 5, 2024
diff --git a/vGPU-windows-VM.md b/vGPU-windows-VM.md
@@ -1,12 +1,12 @@
-## aso of 2024.04.06 i am no longer able to get this to work - i am on kernel 6.5.13-3-pve
 
 # add vGPU to a Windows 11 or Server 2022 VM
-1. boot VM without vGPU and display set to default
-2. install VirtIO drivers
-3. shutdown VM and change display to VirtIO-GPU
-4. change CPU type to 'host'
-5. Now add the vGPU pool as a PCI device
-6. when creating a VM add a PCI device and add the poool as follows:
+1. create VM with CPU set to host DO NOT CHANGE THIS
+3. boot VM without vGPU and display set to default
+4. install windows 11
+5. install VirtIO drivers [as of 4.6.2024 do not install guest tools - this may cause repair loops] 
+6. shutdown VM and change display to VirtIO-GPU
+7. Now add the vGPU pool as a PCI device
+8. when creating a VM add a PCI device and add the poool as follows:
 <p align="center">
 <img width="450" alt="image" src="https://user-images.githubusercontent.com/11369180/263501244-b619f36c-2176-49e5-bca1-302d0b2ff5c7.png">
 </p>

diff --git a/vGPU-windows-VM.md b/vGPU-windows-VM.md
@@ -1,3 +1,5 @@
+## aso of 2024.04.06 i am no longer able to get this to work - i am on kernel 6.5.13-3-pve
+
 # add vGPU to a Windows 11 or Server 2022 VM
 1. boot VM without vGPU and display set to default
 2. install VirtIO drivers

diff --git a/proxmox-vGPU.md b/proxmox-vGPU.md
@@ -9,6 +9,8 @@ This gists assumes you are not running ZFS and are not passing any other PCIE de
 
 This gist assumes you are not running proxmox in UEFI Secure boot - if you are please refer entirely to dereks blog.
 
+ALSO pleas refere to the comments section as folks have found workarounds and probably corrections (if the mistakes remain in my write up it is because i have't yet tested the corrections) 
+
 Note:i made no changes to the BIOS  defaults on the Intel Nuc 13th Gen.  This just worked as-is. 
 
 [this gist is part of this series](/76e94832927a89d977ea989da157e9dc)

diff --git a/proxmox-vGPU.md b/proxmox-vGPU.md
@@ -7,7 +7,7 @@ As such please refer to that for pictures, here i will capture the command lines
 
 This gists assumes you are not running ZFS and are not passing any other PCIE devices (as both of these can require addtional steps - see Derek's blog for more info)
 
-This gist assumes you are not running proxmox in UEFI Secure boot - if you are please refer entirely to deteks blog.
+This gist assumes you are not running proxmox in UEFI Secure boot - if you are please refer entirely to dereks blog.
 
 Note:i made no changes to the BIOS  defaults on the Intel Nuc 13th Gen.  This just worked as-is. 
 

diff --git a/proxmox-vGPU.md b/proxmox-vGPU.md
@@ -7,6 +7,8 @@ As such please refer to that for pictures, here i will capture the command lines
 
 This gists assumes you are not running ZFS and are not passing any other PCIE devices (as both of these can require addtional steps - see Derek's blog for more info)
 
+This gist assumes you are not running proxmox in UEFI Secure boot - if you are please refer entirely to deteks blog.
+
 Note:i made no changes to the BIOS  defaults on the Intel Nuc 13th Gen.  This just worked as-is. 
 
 [this gist is part of this series](/76e94832927a89d977ea989da157e9dc)

diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -96,11 +96,11 @@ if the group names do not say video and render then you did something wrong
 
 **Note: YYMV **
 
-For example plex transcoded just fine on my system. 
+For example plex HW transcoded just fine on my system. 
 
-Emby on the otherhand seems to interrogate the kernel driver directly and gets the wrong answers - this is an issue with their detection logic not supporting this scenario.
+Emby on the otherhand seems to interrogate the kernel driver directly and gets the wrong answers - this is IMHO an issue with their detection logic not supporting this scenario.
 
-Another example is intel_gpu_top which doesn't seem to work in this mode either
+Another example is intel_gpu_top which doesn't seem to work in this mode either - this is because it only works with the PMUs not the VFs (so somoene said)
 
 Or maybe i just have no clue what i am doing, lol.
 

diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -100,7 +100,7 @@ For example plex transcoded just fine on my system.
 
 Emby on the otherhand seems to interrogate the kernel driver directly and gets the wrong answers - this is an issue with their detection logic not supporting this scenario.
 
-Another example However is intel_gpu_top doesn't work in this mode as i don't think that actually uses the /dev/dri path to access the device...
+Another example is intel_gpu_top which doesn't seem to work in this mode either
 
 Or maybe i just have no clue what i am doing, lol.
 

diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -82,7 +82,17 @@ root:44:1
 
 after this you should be able to start up the container and run vainfo and perform transcoding. 
 
-check permissions with `ls -la /dev/dri` the `card0` should have user of nobody and group of video, the `renderD128` should have a user of nobody and a group of render - if they have other names you got your idmapping and numbers muddled.  
+check permissions with `ls -la /dev/dri` it should look like this:
+```
+root@vGPU-debian-test:~# ls -la /dev/dri
+total 0
+drwxr-xr-x 2 root   root         80 Oct  7 00:22 .
+drwxr-xr-x 7 root   root        500 Oct  7 00:22 ..
+crw-rw-rw- 1 nobody video  226,   0 Oct  4 21:42 card0
+crw-rw-rw- 1 nobody render 226, 128 Oct  4 21:42 renderD128
+```
+if the group names do not say video and render then you did something wrong
+
 
 **Note: YYMV **
 

diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -84,9 +84,15 @@ after this you should be able to start up the container and run vainfo and perfo
 
 check permissions with `ls -la /dev/dri` the `card0` should have user of nobody and group of video, the `renderD128` should have a user of nobody and a group of render - if they have other names you got your idmapping and numbers muddled.  
 
-Note: YYMV for example plex trancoded just. Emby on the otherhand interrogates the kernel driver directly and gets the wrong answers - this is an issue with their detection logic not supporting this scenario.
+**Note: YYMV **
+
+For example plex transcoded just fine on my system. 
+
+Emby on the otherhand seems to interrogate the kernel driver directly and gets the wrong answers - this is an issue with their detection logic not supporting this scenario.
 
 Another example However is intel_gpu_top doesn't work in this mode as i don't think that actually uses the /dev/dri path to access the device...
 
+Or maybe i just have no clue what i am doing, lol.
+
 ---work in progress 2023.10.6---
 
diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -82,6 +82,8 @@ root:44:1
 
 after this you should be able to start up the container and run vainfo and perform transcoding. 
 
+check permissions with `ls -la /dev/dri` the `card0` should have user of nobody and group of video, the `renderD128` should have a user of nobody and a group of render - if they have other names you got your idmapping and numbers muddled.  
+
 Note: YYMV for example plex trancoded just. Emby on the otherhand interrogates the kernel driver directly and gets the wrong answers - this is an issue with their detection logic not supporting this scenario.
 
 Another example However is intel_gpu_top doesn't work in this mode as i don't think that actually uses the /dev/dri path to access the device...

diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -80,9 +80,11 @@ root:106:1
 root:44:1
 ```
 
-after this you should be able to start up the container and run vainfo (tested) and perform transcoding (not tested) 
+after this you should be able to start up the container and run vainfo and perform transcoding. 
 
-However i found that intel_gpu_top doesn't work in this mode as i don't think that actually uses the /dev/dri path to access the device...
+Note: YYMV for example plex trancoded just. Emby on the otherhand interrogates the kernel driver directly and gets the wrong answers - this is an issue with their detection logic not supporting this scenario.
 
----work in progress 2023.10.14---
+Another example However is intel_gpu_top doesn't work in this mode as i don't think that actually uses the /dev/dri path to access the device...
+
+---work in progress 2023.10.6---
 
diff --git a/vGPU-windows-VM.md b/vGPU-windows-VM.md
@@ -21,16 +21,14 @@ If you follow the guide successfully, in Device Manager you will see:
 You have 2 options (or more) to use your iGPU. Because Windows 11 decide on its own which graphics to use.
 
 1. Setup Remote Desktop Connection in Windows 11 and set the display to none in VM Hardware settings.
-
-This will force the Windows to use the iGPU.
 - Pro: No configuration per app, Responsive Connection.
 - Con: No proxmox console.
 
-Inside Windows Set which graphics preference to use per application in Display Settings -> Graphics Settings-
+2. Inside Windows Set which graphics preference to use per application in Display Settings -> Graphics Settings-
 - Pro: Have proxmox console.
 - Con: Need to configure per application / program.
 ----
 
 
-2. If you hit automatic repair loop at any point shutdown the machine and edit its conf file in /etc/pve/qemu-server and add
+If you hit automatic repair loop at any point shutdown the machine and edit its conf file in /etc/pve/qemu-server and add
 `args: -cpu Cooperlake,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,+vmx`
diff --git a/vGPU-windows-VM.md b/vGPU-windows-VM.md
@@ -15,13 +15,12 @@
 **From @rinze24:**
 ----
 If you follow the guide successfully, in Device Manager you will see:
+- Microsoft Basic Display Adapter - If you use Display in VM Settings
+- Intel iGPU - passthrough
 
-Microsoft Basic Display Adapter - If you use Display in VM Settings
-Intel iGPU - passthrough
+You have 2 options (or more) to use your iGPU. Because Windows 11 decide on its own which graphics to use.
 
-You have 2 option (or more) to use your iGPU. Because Windows 11 decide on its own which graphics to use.
-
-Setup Remote Desktop Connection in Windows 11 and set the display to none in VM Hardware settings.
+1. Setup Remote Desktop Connection in Windows 11 and set the display to none in VM Hardware settings.
 
 This will force the Windows to use the iGPU.
 - Pro: No configuration per app, Responsive Connection.
@@ -33,5 +32,5 @@ Inside Windows Set which graphics preference to use per application in Display S
 ----
 
 
-If you hit automatic repair loop at any point shutdown the machine and edit its conf file in /etc/pve/qemu-server and add
+2. If you hit automatic repair loop at any point shutdown the machine and edit its conf file in /etc/pve/qemu-server and add
 `args: -cpu Cooperlake,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,+vmx`
diff --git a/vGPU-windows-VM.md b/vGPU-windows-VM.md
@@ -18,15 +18,18 @@ If you follow the guide successfully, in Device Manager you will see:
 
 Microsoft Basic Display Adapter - If you use Display in VM Settings
 Intel iGPU - passthrough
+
 You have 2 option (or more) to use your iGPU. Because Windows 11 decide on its own which graphics to use.
 
 Setup Remote Desktop Connection in Windows 11 and set the display to none in VM Hardware settings.
+
 This will force the Windows to use the iGPU.
-Pro: No configuration per app, Responsive Connection.
-Con: No proxmox console.
-Inside Windows Set which graphics preference to use per application in Display Settings -> Graphics Settings
-Pro: Have proxmox console.
-Con: Need to configure per application / program.
+- Pro: No configuration per app, Responsive Connection.
+- Con: No proxmox console.
+
+Inside Windows Set which graphics preference to use per application in Display Settings -> Graphics Settings-
+- Pro: Have proxmox console.
+- Con: Need to configure per application / program.
 ----
 
 

diff --git a/vGPU-windows-VM.md b/vGPU-windows-VM.md
@@ -12,7 +12,8 @@
 7. now boot into VM and install latest IrisXe drivers from intel
 9. you should now have graphics acceleration availble to apps wether you connect by webcolse VNC, SPICE or an RDP client
 
-From@
+**From @rinze24:**
+----
 If you follow the guide successfully, in Device Manager you will see:
 
 Microsoft Basic Display Adapter - If you use Display in VM Settings
@@ -26,6 +27,8 @@ Con: No proxmox console.
 Inside Windows Set which graphics preference to use per application in Display Settings -> Graphics Settings
 Pro: Have proxmox console.
 Con: Need to configure per application / program.
+----
+
 
 If you hit automatic repair loop at any point shutdown the machine and edit its conf file in /etc/pve/qemu-server and add
 `args: -cpu Cooperlake,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,+vmx`
diff --git a/vGPU-windows-VM.md b/vGPU-windows-VM.md
@@ -12,5 +12,20 @@
 7. now boot into VM and install latest IrisXe drivers from intel
 9. you should now have graphics acceleration availble to apps wether you connect by webcolse VNC, SPICE or an RDP client
 
+From@
+If you follow the guide successfully, in Device Manager you will see:
+
+Microsoft Basic Display Adapter - If you use Display in VM Settings
+Intel iGPU - passthrough
+You have 2 option (or more) to use your iGPU. Because Windows 11 decide on its own which graphics to use.
+
+Setup Remote Desktop Connection in Windows 11 and set the display to none in VM Hardware settings.
+This will force the Windows to use the iGPU.
+Pro: No configuration per app, Responsive Connection.
+Con: No proxmox console.
+Inside Windows Set which graphics preference to use per application in Display Settings -> Graphics Settings
+Pro: Have proxmox console.
+Con: Need to configure per application / program.
+
 If you hit automatic repair loop at any point shutdown the machine and edit its conf file in /etc/pve/qemu-server and add
 `args: -cpu Cooperlake,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,+vmx`
diff --git a/proxmox-vGPU.md b/proxmox-vGPU.md
@@ -35,7 +35,7 @@ deb http://deb.debian.org/debian bookworm non-free
 and save the file
 
 ```
-apt install intel-media-va-driver-non-free intel-gpu-tools vainfo
+apt update && apt install intel-media-va-driver-non-free intel-gpu-tools vainfo
 ```
 
 This next step copies a driver missing on proxmox installs and will remove the -2 error for this file in dmesg.

diff --git a/proxmox-vGPU.md b/proxmox-vGPU.md
@@ -35,7 +35,7 @@ deb http://deb.debian.org/debian bookworm non-free
 and save the file
 
 ```
-apt install intel-media-va-driver-non-free intel-gpu-tools
+apt install intel-media-va-driver-non-free intel-gpu-tools vainfo
 ```
 
 This next step copies a driver missing on proxmox installs and will remove the -2 error for this file in dmesg.

diff --git a/proxmox-vGPU.md b/proxmox-vGPU.md
@@ -30,7 +30,7 @@ add the following lines:
 deb http://deb.debian.org/debian bookworm non-free-firmware
 
 #non-free drivers and components
-deb http://deb.debian.org/debian bookworm contrib non-free
+deb http://deb.debian.org/debian bookworm non-free
 ```
 and save the file
 

diff --git a/proxmox-vGPU.md b/proxmox-vGPU.md
@@ -140,22 +140,6 @@ The pool should now look like this:
 
 ![image](https://user-images.githubusercontent.com/11369180/263501200-281d3125-fd54-401c-bf18-22f5df721b3f.png)
 
-## add vGPU to a Windows 11 or Server 2022 VM
-1. boot VM without vGPU and display set to default
-2. install VirtIO drivers
-3. shutdown VM and change display to VirtIO-GPU
-4. change CPU type to 'host'
-5. Now add the vGPU pool as a PCI device
-6. when creating a VM add a PCI device and add the poool as follows:
-<p align="center">
-<img width="450" alt="image" src="https://user-images.githubusercontent.com/11369180/263501244-b619f36c-2176-49e5-bca1-302d0b2ff5c7.png">
-</p>
-
-7. now boot into VM and install latest IrisXe drivers from intel
-9. you should now have graphics acceleration availble to apps wether you connect by webcolse VNC, SPICE or an RDP client
-
-If you hit automatic repair loop at any point shutdown the machine and edit its conf file in /etc/pve/qemu-server and add
-`args: -cpu Cooperlake,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,+vmx`
 
 Note: machines with PCI pass through devices cannot be live migrated, they must be shutdown, migrated offline to the new node and then started.
 

diff --git a/vGPU-windows-VM.md b/vGPU-windows-VM.md
@@ -0,0 +1,16 @@
+# add vGPU to a Windows 11 or Server 2022 VM
+1. boot VM without vGPU and display set to default
+2. install VirtIO drivers
+3. shutdown VM and change display to VirtIO-GPU
+4. change CPU type to 'host'
+5. Now add the vGPU pool as a PCI device
+6. when creating a VM add a PCI device and add the poool as follows:
+<p align="center">
+<img width="450" alt="image" src="https://user-images.githubusercontent.com/11369180/263501244-b619f36c-2176-49e5-bca1-302d0b2ff5c7.png">
+</p>
+
+7. now boot into VM and install latest IrisXe drivers from intel
+9. you should now have graphics acceleration availble to apps wether you connect by webcolse VNC, SPICE or an RDP client
+
+If you hit automatic repair loop at any point shutdown the machine and edit its conf file in /etc/pve/qemu-server and add
+`args: -cpu Cooperlake,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,+vmx`
diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -1,5 +1,5 @@
 # How to get working in a privileged container
-wow this one is hard....
+wow this one is hard.... you can avoid the id mapping stuff by not using a privileged container...
 
 ## Assumptions:
 1. you have a debian 12 container, you added the non-free deb and have installed the non-free drivers as per the host instructions
@@ -24,7 +24,7 @@ usermod -a -G video root
 
 ### Add lxc device mapping
 
-Here you add a line foe the card uyou want and the rendere.
+Here you add a line for the card uyou want and the rendere.
 Note if you map a VF (card) to a container it means that is hard mapped, if you have that VF in a pool for VMs please remove it from the pool (this means also these containers cannot be HA)
 
 In the example below i chose card6 - which is renderD134
@@ -42,7 +42,7 @@ lxc.mount.entry: /dev/dri/renderD134 dev/dri/renderD128 none bind,optional,creat
 
 
 
-### Add ID mapping
+### Add ID mapping (only needed in unprivileged)
 1. add the following... and here it gets complex as it will vary based on the numbers you recorded earlier - let me try... the aim is to have a continguois block of mappings but the syntax is um difficult...
 
 ```
@@ -72,7 +72,7 @@ lxc.idmap: g 106 104 1
 lxc.idmap: g 107 100107 65429
 ```
 
-4. add your two CT values to `nano /etc/subgid`
+4. add your two CT values to `nano /etc/subgid`  (only needed in unprivileged)
 
 in my case:
 ```

diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -80,7 +80,9 @@ root:106:1
 root:44:1
 ```
 
-after this you should be able to start up the container and run vainfo and intel_gpu_top
+after this you should be able to start up the container and run vainfo (tested) and perform transcoding (not tested) 
+
+However i found that intel_gpu_top doesn't work in this mode as i don't think that actually uses the /dev/dri path to access the device...
 
 ---work in progress 2023.10.14---
 
diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -80,10 +80,7 @@ root:106:1
 root:44:1
 ```
 
-5. in the contaier
+after this you should be able to start up the container and run vainfo and intel_gpu_top
 
-
-you will need to reboot
-
-after this you should be able to run vainfo and verify all is working
+---work in progress 2023.10.14---
 
diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -21,15 +21,37 @@ usermod -a -G video root
 ## Edit container conf file
 1. These are stored in /etc/pve/lxc and have the VMID.conf anme
 2. `nano /etc/pve/lxc/VMID.conf`
-3. add the following... and here it gets complex as it will vary based on the numbers you recorded earlier - let me try... the aim is to have a continguois block of mappings but the syntax is um difficult...
+
+### Add lxc device mapping
+
+Here you add a line foe the card uyou want and the rendere.
+Note if you map a VF (card) to a container it means that is hard mapped, if you have that VF in a pool for VMs please remove it from the pool (this means also these containers cannot be HA)
+
+In the example below i chose card6 - which is renderD134
+These are mapped into the container as card0 and renderD128
+Change your numbers as per your own VF / card mappings
+
+```
+lxc.cgroup2.devices.allow: c 226:6 rwm
+lxc.mount.entry: /dev/dri/card6 dev/dri/card0 none bind,optional,create=file
+
+lxc.cgroup2.devices.allow: c 226:134 rwm
+lxc.mount.entry: /dev/dri/renderD134 dev/dri/renderD128 none bind,optional,create=file
+
+```
+
+
+
+### Add ID mapping
+1. add the following... and here it gets complex as it will vary based on the numbers you recorded earlier - let me try... the aim is to have a continguois block of mappings but the syntax is um difficult...
 
 ```
 lxc.idmap: u 0 100000 65536
 lxc.idmap: g 0 100000 CTVGID
 lxc.idmap: g CTVGID HSTVGID 1
-lxc.idmap: g CTVGID+1 1000CTVGID+1 CTRGID-CTVGID-1
+lxc.idmap: g CTVGID+1 1000{CTVGID+1} CTRGID-CTVGID-1
 lxc.idmap: g CTRGID HSTVGID 1
-lxc.idmap: g HSTVGID 100HSTVGID 65429
+lxc.idmap: g CTRGID+1 100{CTRGID+1} 65536-{CTRGID+1}
 ```
 
 so as an example, these are my values:
@@ -40,14 +62,14 @@ video:    44 > 44
 render:  104 > 106
 ```
 
-this is what i added to my VMID.conf file
+this is what i added to my VMID.conf file (in  my case /etc/pve/lxc/107.conf
 ```
 lxc.idmap: u 0 100000 65536
 lxc.idmap: g 0 100000 44
 lxc.idmap: g 44 44 1
-lxc.idmap: g 45 100045 60
+lxc.idmap: g 45 100045 61
 lxc.idmap: g 106 104 1
-lxc.idmap: g 105 100106 65430
+lxc.idmap: g 107 100107 65429
 ```
 
 4. add your two CT values to `nano /etc/subgid`

diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -8,8 +8,15 @@ wow this one is hard....
 5 that you have va info fully working
 
 ## Create Container
-1. create container privileged, with debian 12, don't start it
+1. create container privileged, with debian 12, starts it
 2. apt update, apt upgrade, install non free drivers, vainfo and intel_gpu_top tools
+3. add root to user and video groups (this will mean when we get to ID mapping you don't need to tart about with user mappings - only group ones)
+
+```
+usermod -a -G render root
+usermod -a -G video root
+```
+4. shutdown container
 
 ## Edit container conf file
 1. These are stored in /etc/pve/lxc and have the VMID.conf anme
@@ -53,10 +60,7 @@ root:44:1
 
 5. in the contaier
 
-```
-usermod -a -G render root
-usermod -a -G video root
-```
+
 you will need to reboot
 
 after this you should be able to run vainfo and verify all is working

diff --git a/vGPU-container b/vGPU-container
@@ -1,6 +0,0 @@
-# How to get working in a privileged container
-wow this one is hard....
-
-## Assumptions:
-1. you have a debian 12 container
-2. you have run `cat /etc/groups` in the container and noted down the GID for render (lets call that CTRGID) and gid for video (lets call that CTVGID).

diff --git a/vGPU-container-privileged.md b/vGPU-container-privileged.md
@@ -0,0 +1,63 @@
+# How to get working in a privileged container
+wow this one is hard....
+
+## Assumptions:
+1. you have a debian 12 container, you added the non-free deb and have installed the non-free drivers as per the host instructions
+2. you have run `cat /etc/groups` in the container and noted down the GID for render (lets call that CTRGID) and gid for video (lets call that CTVGID).
+4. you have run `cat /etc/groups` in the container and noted down the GID for render (lets call that HSTRGID) and gid for video (lets call that HSTVGID).
+5 that you have va info fully working
+
+## Create Container
+1. create container privileged, with debian 12, don't start it
+2. apt update, apt upgrade, install non free drivers, vainfo and intel_gpu_top tools
+
+## Edit container conf file
+1. These are stored in /etc/pve/lxc and have the VMID.conf anme
+2. `nano /etc/pve/lxc/VMID.conf`
+3. add the following... and here it gets complex as it will vary based on the numbers you recorded earlier - let me try... the aim is to have a continguois block of mappings but the syntax is um difficult...
+
+```
+lxc.idmap: u 0 100000 65536
+lxc.idmap: g 0 100000 CTVGID
+lxc.idmap: g CTVGID HSTVGID 1
+lxc.idmap: g CTVGID+1 1000CTVGID+1 CTRGID-CTVGID-1
+lxc.idmap: g CTRGID HSTVGID 1
+lxc.idmap: g HSTVGID 100HSTVGID 65429
+```
+
+so as an example, these are my values:
+
+```
+        host > ct
+video:    44 > 44
+render:  104 > 106
+```
+
+this is what i added to my VMID.conf file
+```
+lxc.idmap: u 0 100000 65536
+lxc.idmap: g 0 100000 44
+lxc.idmap: g 44 44 1
+lxc.idmap: g 45 100045 60
+lxc.idmap: g 106 104 1
+lxc.idmap: g 105 100106 65430
+```
+
+4. add your two CT values to `nano /etc/subgid`
+
+in my case:
+```
+root:106:1
+root:44:1
+```
+
+5. in the contaier
+
+```
+usermod -a -G render root
+usermod -a -G video root
+```
+you will need to reboot
+
+after this you should be able to run vainfo and verify all is working
+
diff --git a/vGPU-container b/vGPU-container
@@ -0,0 +1,6 @@
+# How to get working in a privileged container
+wow this one is hard....
+
+## Assumptions:
+1. you have a debian 12 container
+2. you have run `cat /etc/groups` in the container and noted down the GID for render (lets call that CTRGID) and gid for video (lets call that CTVGID).
diff --git a/proxmox-vGPU.md b/proxmox-vGPU.md
@@ -105,7 +105,7 @@ echo "devices/pci0000:00/0000:00:02.0/sriov_numvfs = 7" > /etc/sysfs.conf
 ```
 **REBOOT**
 
-## Testing
+## Testing On Host
 
 ### check devices ###
 
@@ -120,6 +120,7 @@ if they don't then check all steps carefully
 
 ### Validate with VAInfo
 validate with `vainfo` you should see no errors (note this needs the drivers and tool i said to install at the top)
+and `vainfo --display drm --device /dev/dri/cardN` where N is a number from 0 to 7 - this will show you the acceleration endpoints for each VF
 
 ### Check you can monitor the VFs - if not you have issues
 monitor any VF renderer in real time with `intel_gpu_top -d drm:/dev/dri/renderD128` there is one per VF - to see them all use `ls -l /dev/dri`

diff --git a/proxmox-vGPU.md b/proxmox-vGPU.md
@@ -160,9 +160,7 @@ Note: machines with PCI pass through devices cannot be live migrated, they must
 
 # EVERYTIME THE KERNEL IS UPDATED IN PROXMOX YOU SHOULD DO THE FOLLOWING
 ```
-update the kernel
-reboot
-apt install pve-headers-$(uname -r)
-dkms install -m i915-sriov-dkms -v 6.1 --force
+update the kernel using proxox ui
+dkms install -m i915-sriov-dkms -v 6.5 --force
 reboot
 ```
diff --git a/proxmox-vGPU.md b/proxmox-vGPU.md
@@ -9,7 +9,7 @@ This gists assumes you are not running ZFS and are not passing any other PCIE de
 
 Note:i made no changes to the BIOS  defaults on the Intel Nuc 13th Gen.  This just worked as-is. 
 
-[this gist is part of this series](scyto/76e94832927a89d977ea989da157e9dc)
+[this gist is part of this series](/76e94832927a89d977ea989da157e9dc)
 
 ## Preparation
No results found