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é.

Voici pourquoi l'hyperviseur devait partir, et l'ordre des opérations qui marche réellement sur Trixie.

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, ce qui veut dire démêler les groupes IOMMU, empêcher l'hôte de jamais s'attacher à la carte par une liste noire, et 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.

Le raisonnement était donc simple : une machine dont le seul but est un GPU n'a pas besoin d'un hyperviseur posé entre moi et nvidia-smi. On effondre la pile, on met la carte sur le métal nu, et la taxe du passthrough disparaît avec la couche qui l'avait créée.

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 pour compiler le module contre votre noyau en cours d'exécution. Ce détail est toute la raison d'utiliser le pilote empaqueté plutôt que 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. Cette unique étape est la différence entre une installation propre et une installation qui marche, et c'est celle que les logs d'installation ne mentionnent jamais.

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, ce qui est correct, parce que ces nœuds font le travail de consolidation pour lequel Proxmox est vraiment bon. Ultron n'a simplement jamais été ce nœud-là.

La prochaine chose sur cette machine, c'est de câbler sa télémétrie de puissance dans le même tableau de bord qu'alimente le travail GPU, pour que le nœud rapporte les joules par exécution à côté de l'utilisation. Si vous faites tourner un cluster Proxmox mixte et avez une façon plus propre de garder un nœud GPU sur métal nu dans le rang sans la taxe du passthrough, dites-le-moi, je n'en ai pas encore trouvé une que j'aime.