Bonjour à tous, aujourd’hui nous allons parler technique et surtout faire un article relativement rapide sur une problématique que j’avais et que j’ai réussi à résoudre. L’idée étant de vous exposer la problématique, le pourquoi du comment et de synthétiser de manière simple la solution afin de vous éviter de multiples recherches google. Comme vous l’avez dans le titre on va parler de Proxmox.

Proxmox c’est quoi et pourquoi

Tout d’abord je vous invite fortement à vous rendre sur le site domopi et de le mettre en favoris et de parcourir cet article :

proxmox

Cet article vous expose brièvement au début ce qu’est Proxmox. Mais en une phrase à retenir, Proxmox est un hyperviseur de machines virtuelles et de containers. Il faut savoir que je possédais déjà un hyperviseur de ce type dans ma baie dans un serveur, c’était VmWare. Cependant j’ai décidé de changer de serveur. Je prévois donc de remiser mon Optiplex avec core i5 et je me suis donc procuré ceci :

proxmox

Ceci est un Nuc de marque AsRock. J’ai pris ce modèle car je voulais absolument un core I7-1185G7 ou un core I7-1165G7 et en ce moment c’est compliqué niveau stock. En effet je souhaitais avoir un I7 car avec l’hyperthreading, cela double les cores disponibles et surtout je voulais un dernière génération pour deux raisons :

  • bon ben on est technophile ou pas donc on est toujours attiré par la dernière génération
  • bénéficier des dernières avancées de transcodage des dernières puces Intel (Quicksync notamment)

Le dernier point est très intéressant quand on utilise un système comme Plex, Emby ou Jellyfin. Et c’est mon cas depuis peu.

Alors tout ça on en parlera dans d’autres articles, présentation du nuc, installation de Proxmox, gestion Emby etc. Mais aujourd’hui on va se focaliser sur un sujet précis qui peut concerner certaines personnes.

Nuc Proxmox et passage du IGPU : pourquoi ?

Il faut le savoir Proxmox permet de créer des Machines virtuelles et aussi des LXC (Linux Container).

L’avantage d’un LXC c’est d’utiliser beaucoup moins de ressources qu’une VMs. On verra dans un article la nuance entre Machines Virtuelles / LXC / Docker. Et il est aussi plus facile de passer un IGPU à un LXC (même s’il y a des choses à savoir) et surtout il se retrouve pas bloqué par une VM, le IGPU reste partagé dans un LXC et peut être utilisé par le host (la machine qui héberge proxmox) ou d’autres LXC.

Pourquoi s’embêter avec ça ? Pour une raison simple :

  • si votre serveur à besoin de transcoder (que ce soit Plex, Emby, Jellyfin) si il utilise les cores du processeur, vous allez le saturer à quasi 100% pour un moindre flux
  • si au contraire vous pouvez utiliser les capacités de transcodage de la puce, vous pourrez transcoder aisément sans impact sur le CPU, des flux même 4K HDR et même plusieurs en même temps

Nuc Proxmox et passage du IGPU : les faits

Tous ceux qui ont essayé le savent, le IGPU de l’hôte n’est pas utilisable dans un LXC de manière native. Pour s’en rendre compte c’est simple il suffit d’installer vainfo dans le container.

apt install vainfo

Ensuite on l’exécute et on obtient ceci :

proxmox

Et BOUM !!! Il ne voit aucune info d’accélération matérielle.

Alors que la même commande exécutée sur le host donne :

proxmox vainfo host

La puce graphique est détectée et la liste (bien plus longue que le screen) de ses capacités apparaît.

Donc la deux solutions s’offraient à moi :

  1. installer mon serveur vidéo sur le Host à côté de Proxmox
  2. me casser la tête et réussir à rendre la puce visible et exploitable dans un LXC et pouvoir containeriser mon serveur vidéo (Emby, Plex ou Jellyfin)

Bien évidemment c’est l’option 2 que j’ai retenu en premier lieu et en me disant si vraiment je me casse les dents alors je peux me rabattre sur la solution 1.

Nuc Proxmox et passage du IGPU : la réalisation

Alors je vous épargne les nombreuses lectures, échecs etc. Pour vous emmener directement à l’essentiel.

Tout d’abord il nous faut trouver ce qui gère cet IGPU sur le host. Puisque comme on l’a vu avant sur lui tout marche.

Pour cela on va taper cette commande :

ls -l /dev/dri

proxmox host dri

C’est ici que se trouve cette fameuse gestion on y trouve notamment

  • card0 qui appartient au groupe video
  • render qui appartient au groupe render

Les groupes sont importants et on le verra plus tard. Autre chose d’important est de noter les numéros 226,0 et 226,128. Ils peuvent être différents chez vous.

Si vous êtes curieux vous pouvez taper cette commande au sein même de votre container pour découvrir ceci :

proxmox lxc dri

On comprend tout de suite le problème.

Vous vous doutez que si je fais un article c’est qu’il y a une solution. Et au final elle est très simple.

Première chose à faire dans Proxmox :

On va se rendre sur Proxmox pour aller arrêter notre container et au passage noter son id :

proxmox container list

Ici je repère mon container Emby et son id qui est donc le 101. (Alors oui j’utilise Emby, je vous ferai un article pour vous exposer mon comparatif Plex/Emby/Jellyfin et pourquoi pour le moment je reste sur Emby).

On arrête ensuite le container.

Deuxième chose à faire dans Proxmox :

Muni de cette précieuse info nous allons aller dans le shell de l’host pour aller éditer la configuration du container. En effet ce que nous allons rajouter n’est pas disponible dans l’interface graphique et Proxmox nous permet d’aller rajouter encore plus d’options en ligne de commande.

On tape donc

nano /etc/pve/lxc/101.conf

Le 101 est à remplacer par votre ID à vous bien évidemment.

On obtient donc la config de votre container. Vous verrez que cela correspond aux informations que vous avez configuré via l’interface graphique.

Et on va rajouter ceci à la fin du fichier :

lxc.cgroup2.devices.allow: c 226:0 rwm
lxc.cgroup2.devices.allow: c 226:128 rwm
lxc.mount.entry: /dev/dri dev/dri none bind,optional,create=dir

Attention ceci est sous Proxmox 7 et supérieur, pour des versions plus anciennes de Proxmox il faut remplacer cgroup2 par cgroup.

Il vous faut aussi remplacer le 226:0 et 226:128 par vos valeurs à vous que l’on a récupérées précédemment.

Ces trois lignes vont :

  • autoriser 226:0 au lxc
  • autoriser 226:128 au lxc
  • monter le répertoire /dev/dri et son contenu dans le lxc

On sauve et on peut relancer notre container.

Troisième chose à faire dans le container :

Nous allons vérifier si tout est bon dans le container :

On vérifie que /dev/dri existe avec :

ls -l /dev/dri

proxmox dri container

Super tout est là, allons voir ce que nous dit vainfo en tapant vainfo :

proxmox

Oh mais dis donc c’est génial ça.

Quatrième chose à faire dans le container :

Alors là tout le monde est content, tout semble bon. Mais en tout cas sur Emby a cette étape là dans les paramètres avancés de transcodage vous ne verrez ni QuickSync ni VAAPI. Et là on peut y passer un moment. Et la raison est simple…

Vous vous rappelez les groupes video et render dont je vous ai parlé plus tôt ? Regardez bien mon screen dans le container :

proxmox dri container

C’est marrant ça tiens dis donc. Dans le container (Debian 11 en tout cas) on retrouve video et input… Tiens je me demande si Emby quand il s’installe se met bien dans les bons groupes.

On va vérifier :

nano /etc/group

proxmox list groups

NOOOONNN, j’ai passé tout ce temps à faire, défaire refaire, alors que vainfo donnait tout bon et que je comprenais pas pour ça. Emby n’est pas dans le groupe input…. Bon allons le rajouter dans le container :

usermod -a -G input emby

On relance le container dans le doute et puis :

proxmox emby

On l’a fait !!!!

Proxmox passtrough IGPU : Conclusion

Voilà on a réussi on a Emby en LXC avec usage complet comme si il était sur le Host du IGPU et de l’accélération matériel.

proxmox result

On le voit très bien ici mon fils qui regarde sur sa tablette un épisode. Sa tablette ayant du mal avec le H.265. J’ai forcé volontairement  un débit a 1 Mbps pour avoir un fort transcodage. On voit que le système utilise bien QuickSync. On a donc un transcodage à la volée sans utilisation du CPU (charge de 3% chez moi).

Alors je sais que cet article est plutôt technique. Mais comme tout quand on cherche quelque-chose on se dit que d’autres aussi se sont posés la question et donc je me suis dit un partage qui concernera peu de gens mais qui sera utile.

D’ailleurs ce tuto s’applique pour Emby, Plex, JellyFin ou pour tout autre besoin de vouloir containeriser et passer le IGPU au container.



Share.

About Author

Je m’appelle Ludovic Sarakha j’ai 37 ans et je suis habitant de Clermont-Ferrand. Concernant les études il faut savoir que bien que j’ai travaillé dans l’informatique (SSII internationale) et maintenant dans la domotique, j’ai un doctorat de Chimie des matériaux. Je suis un autodidacte passionné d'informatique, de domotique et de tout ce qui tourne autour des objets connectés

5 commentaires

  1. Bonjour, merci pour ce très bon article je suis justement en train de me pencher sur le sujet est-ce que ça fonctionnerait aussi avec un mini pc à base de Ryzen ? Merci

  2. Salut et merci pour ton tuto
    J’ai un NUC 10 I7.
    j’ai suivi ta procédure mais dans le contener LXC (Debian 11) quand je le redémarre apres la modif du fichier de conf depuis l’hote, je vois bien by-path, card0, renderD128 mais avec les groupes nobody et nogroup.
    vainfo ne donne aucune info d’accélération matérielle.
    Tu as une idée ?

    • En parallèle, pourrais tu nous donner les options de ton container. C’est peut etre le souci. Unprivileged container est il coché ? Pourquoi avoir nfs dans tes options ?

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.