Démonter Ultron, de Proxmox à un Debian nu

Ultron est le nœud GPU de mon homelab, une station de travail Xeon mono-socket qui, pendant un an, a fait tourner Proxmox comme le reste du cluster. La semaine dernière, je l'ai effacé et j'ai réinstallé un Debian 13 (Trixie) nu, parce que la seule tâche que je veux vraiment de cette machine, faire tourner des charges CUDA sur son GPU, est justement celle qu'un hyperviseur rend plus difficile plutôt que plus simple. La réinstallation a pris vingt minutes. Faire charger le pilote a pris le reste de la soirée, presque entièrement sur une seule chose dont personne ne vous prévient : le Secure Boot refusant en silence un module non signé.

L'ordre des opérations qui marche réellement sur Trixie tient en quelques étapes, dont une que rien ne documente.

Pourquoi un hyperviseur était la mauvaise couche ici

Proxmox mérite sa place quand on consolide de nombreux invités sur une seule machine. Le calcul GPU est de forme inverse. Pour donner un vrai GPU à une machine virtuelle, on passe par le passthrough VFIO, le mécanisme qui détache un périphérique de l'hôte pour le confier à un invité. Il faut alors démêler les groupes IOMMU, ces blocs de périphériques que le matériel refuse de séparer, empêcher l'hôte de s'attacher à la carte par une liste noire, puis remettre l'appareil entier à exactement un invité. On finit par parler à son GPU à travers une machine virtuelle, la carte ne peut de toute façon appartenir qu'à une VM à la fois, et on traîne toute cette mécanique pour un nœud qui fait précisément une seule chose.

Une machine dont le seul but est un GPU n'a pas besoin d'un hyperviseur posé entre moi et nvidia-smi. En supprimant la couche, la carte revient sur le métal nu et la taxe du passthrough disparaît avec elle.

Le même matériel, deux piles. Le passthrough achète une flexibilité qu'un nœud GPU à usage unique n'emploie jamais.

Mettre nouveau en liste noire, la partie facile à oublier

Debian fournit nouveau, le pilote open source, et le charge au démarrage. Le module propriétaire ne s'attachera pas tant que nouveau tient la carte : le premier geste est donc de le mettre en liste noire et de reconstruire l'initramfs, pour que le changement soit en place dès le début du démarrage plutôt qu'après que le noyau a déjà réclamé le GPU.

# /etc/modprobe.d/blacklist-nouveau.conf
blacklist nouveau
options nouveau modeset=0

# puis régénérer l'initramfs pour que ça tienne au démarrage
sudo update-initramfs -u

Le pilote lui-même : laissez DKMS faire la compilation

Trixie garde le pilote NVIDIA dans le composant non-free et son firmware dans non-free-firmware : il faut donc élargir les sources avant que quoi que ce soit soit installable. Ensuite on installe les en-têtes du noyau et le paquet du pilote, et Debian utilise DKMS, le mécanisme qui recompile les modules noyau à chaque mise à jour, pour compiler le module contre votre noyau en cours d'exécution. D'où l'intérêt du pilote empaqueté plutôt que de l'installeur .run : DKMS recompile le module automatiquement à la prochaine mise à jour du noyau, si bien qu'un apt upgrade ne vous laisse pas discrètement avec un écran noir.

# ajoutez  contrib non-free non-free-firmware  à vos sources apt, puis :
sudo apt update
sudo apt install linux-headers-amd64 nvidia-driver

Le Secure Boot, ou pourquoi nvidia-smi m'a menti

Après le redémarrage, j'ai lancé nvidia-smi et j'ai obtenu ceci :

$ nvidia-smi
NVIDIA-SMI has failed because it couldn't communicate with the
NVIDIA driver. Make sure that the latest NVIDIA driver is installed
and running.

La carte allait bien et le module s'était compilé sans broncher. Le noyau refusait simplement de le charger, parce que le Secure Boot était activé et qu'un module compilé par DKMS n'est pas signé. Il y a deux issues. On peut désactiver le Secure Boot dans le firmware, ou bien enrôler une clé propriétaire de la machine (Machine Owner Key), signer le module avec, et garder la chaîne de confiance intacte. J'ai gardé le Secure Boot et enrôlé une clé, ce qui est une danse unique à travers le firmware au redémarrage suivant.

# enrôler la clé de signature DKMS, définir un mot de passe unique, puis redémarrer
sudo mokutil --import /var/lib/dkms/mok.pub
# au gestionnaire MOK bleu au redémarrage : Enroll MOK, saisir le mot de passe, redémarrer

Après ça, nvidia-smi est remonté proprement avec la carte et la version du pilote. Aucun log d'installation ne mentionne cette étape.

Toute la séquence. Toutes les cases sauf l'ambre sont mécaniques ; l'ambre est l'endroit où une compilation propre vous donne quand même un nvidia-smi mort.

Ce que j'ai récupéré

Un nvidia-smi nu, la carte entière sans machine virtuelle en travers, et un nœud qui fait maintenant tourner mon travail de mesure d'énergie Kokkos directement contre le matériel plutôt qu'à travers un invité. Le reste du cluster est toujours sous Proxmox : ces nœuds font le travail de consolidation pour lequel Proxmox est bon. Ultron ne faisait pas ce travail.

Reste à câbler la télémétrie de puissance de la machine dans le même tableau de bord que le travail GPU, pour que le nœud rapporte les joules par exécution à côté de l'utilisation. Garder un nœud sur métal nu au milieu d'un cluster Proxmox reste bancal côté supervision : pour l'instant il vit à côté du rang, pas dedans.