Proxmox sur ThinkStation P340 : la Quadro dans la VM

L’hôte est un Lenovo ThinkStation P340 sous Proxmox VE. La carte graphique dont il est question est une NVIDIA Quadro P1000. Elle est attribuée à une machine virtuelle Debian, la VM des services. Tout ce qui suit sur le matériel vu par cette VM a été constaté dedans. Tout ce qui concerne les réglages de l’hôte est un principe général : l’hôte n’était pas accessible.

Ce que la VM est

La VM tourne sous Debian 13 (trixie). Le 3 octobre 2026, son noyau est passé de 6.12.107 à 6.12.111, paquet Debian. C’est une VM QEMU/KVM. Elle se présente comme une machine i440FX avec SeaBIOS, et non comme une machine Q35 avec OVMF. Elle a 6 vCPU, un Intel Core i7-10700T, et environ 11 Go de mémoire.

Cette description est celle de la VM, pas une photo des cases cochées dans Proxmox. Voir une machine i440FX ne prouve pas, à soi seul, quelle option PCIe est sélectionnée sur l’hôte.

Ce que la VM voit du GPU

Dans la VM, la carte est une NVIDIA Quadro P1000, puce GP107GL, avec 4 Go de mémoire. Ses deux fonctions PCI sont présentes : la partie VGA, pilotée par nvidia, et la partie audio HDMI, pilotée par snd_hda_intel. La VM garde aussi un affichage émulé, bochs, comme carte VGA principale. Le GPU NVIDIA est une carte secondaire, utilisée pour le calcul et la vidéo.

Le pilote est le NVIDIA 550.163.01, paquets Debian, module compilé par DKMS. nvidia-smi annonce CUDA 12.4. Le pilote nouveau est sur liste noire. Le mode persistance est désactivé. Le NVIDIA Container Toolkit est en version 1.20.1. Pilote et toolkit ont été installés le 3 octobre 2026, entre 13 h 20 et 13 h 25, en même temps que le nouveau noyau. La VM a redémarré à 13 h 27.

Docker ne prend pas le GPU par défaut

La configuration du démon Docker, modifiée le même jour à 13 h 25, déclare le runtime nvidia. Le runtime par défaut reste pourtant runc. L’accès au GPU ne passe pas par ce runtime nvidia. Il passe par une demande de périphérique, l’équivalent de --gpus all ou d’une réservation de périphérique dans un fichier Compose, avec les capacités gpu, compute, video et utility.

L’extrait suivant illustre ce mécanisme. Le nom du service est fictif. Ce n’est pas une copie d’un fichier du serveur.

services:
  exemple:
    image: exemple
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu, compute, video, utility]

Un seul conteneur demande le GPU. Au relevé, il s’en servait pour du décodage et du transcodage matériel, et occupait environ 550 Mo de mémoire vidéo. Son nom n’est pas publié ici. Les autres conteneurs ne reçoivent pas la carte : il faut la demander, elle n’est pas prêtée à toute la VM Docker d’un coup.

Ce qui est cohérent avec un passthrough de la carte entière, c’est seulement le constat côté VM : les deux fonctions, vidéo et audio, y apparaissent. Cela ne remplace pas la lecture de l’hôte. Le jour où cette lecture sera possible, cet article pourra dire si l’option PCIe est cochée, et comment vfio est chargé. En attendant, la partie sûre est celle de la VM : la Quadro est là, le pilote répond, et Docker ne la donne qu’au conteneur qui la demande.