Confier toute la carte graphique à une machine virtuelle prive le bureau hôte et les autres invités d'accès. L'intervenant ouvre sur ce compromis brutal et demande pourquoi donner une carte à un invité devrait la retirer à tout le reste. La réponse tient au passage direct de l'appareil entier : détaché de son pilote hôte pour affectation, il part à un seul invité, et l'hôte comme les autres invités ne peuvent plus l'utiliser en même temps.
La mécanique recoupe le guide de passage PCI sur archlinux.org : détachement du pilote hôte, affectation via groupes IOMMU, perte d'affichage côté hôte. Qui a essayé sur un portable à un seul GPU connaît la douleur ; le bureau hôte ne revient qu'à l'arrêt de l'invité. L'intervenant érige cette propriété exclusive en problème et y place la promesse : l'accès sans la propriété.
Transmettre la requête au lieu de la carte
Le projet expérimental virtio-nvgpu inverse le chemin. Sa fiche GitHub le résume en une ligne : un périphérique virtio pour un accès NVIDIA quasi natif dans des invités KVM. La carte reste chez l'hôte pendant que les invités transmettent leurs requêtes au pilote hôte. Ce qui traverse la frontière n'est pas le matériel mais des opérations vers le logiciel qui le pilote. Des chemins distincts s'ouvrent ainsi pour un deuxième, troisième et quatrième invité sans acheter une autre carte.
Le passage le plus pédagogique suit une seule demande de tampon. Une application dans un invité Linux veut un tampon graphique pour une image. Le pilote NVIDIA en mode utilisateur reste inchangé dans l'invité ; un petit module de transfert dans le noyau invité fait passer la requête via une file virtio vers l'arrière-plan hôte. Les lecteurs de la documentation QEMU reconnaîtront la forme : frontal dans l'invité, dorsal chez l'hôte, discipline de file entre eux.
Avant d'atteindre le pilote hôte, l'arrière-plan traduit les références. Pointeurs mémoire, poignées de ressources et descripteurs peuvent changer de sens d'un côté à l'autre, donc l'arrière-plan les convertit en équivalents compris par l'hôte. Puis une fenêtre mémoire partagée ouvre deux vues sur le même tampon, côté invité et côté hôte, sans copie double. Une fois le mappage établi, le chemin de rendu documenté s'en sert ; chaque appel de dessin n'exige plus de message transmis.
Garder le pilote utilisateur inchangé est l'astuce. Les applications parlent au pilote connu pendant que module et arrière-plan font la paperasse. Un second invité peut brancher son propre chemin vers la même carte. La différence avec les montages vGPU et MIG documentés par Nvidia compte ici : découpage temporel ou matériel d'un côté, requêtes transmises et mémoire mappée de l'autre. L'intervenant insiste ; on ne peut emprunter les garanties d'un autre système.
Quatre invités, une carte : le résultat mesuré
Les chiffres viennent d'une RTX 3060 avec la même charge synthétique. Un invité seul a produit 102,9 images par seconde. Quatre invités avec cette charge ont tourné vers 26 chacun, soit 103,69 au total. La base TechPowerUp liste cette carte à 3584 coeurs CUDA et 12 Go de GDDR6 ; dans cet essai les mêmes calcul et mémoire ont tout fait, rien n'a été multiplié. Quatre sonnettes, une seule cuisine : plus de façons de demander, même cuisine.
Les conditions sont explicites : chauffe de 8 secondes puis course de 30 secondes, travail identique dans les quatre invités. Comme le note le résumé Linuxiac, ce sont des résultats internes sans confirmation indépendante. Surtout, rien ne promet quota fixe, équité ni tranche protégée de mémoire graphique . Quatre est le nombre rapporté, pas un maximum mesuré. Quatre applications lourdes et différentes formeraient un tout autre essai.
Le second coût existe même à un seul invité : le surcoût de transmission. Dans un cas synthétique une image hôte de 2 millisecondes a ralenti de 1,7 % dans l'invité ; dans un cas bien plus court une image hôte de 0,05 milliseconde a ralenti de 40,8 %. Les auteurs attribuent l'écart court surtout au réveil de l'invité après le matériel. Un petit poids paraît énorme sur un tout petit travail, donc les pourcentages doivent voyager avec leurs durées d'origine. Aucune promesse quasi native n'en découle.
Ce à quoi cela sert, ce à quoi non
La cible annoncée est la diffusion sans tête : l'invité produit une image et la sert en flux vidéo avec encodage H.264 , vue sur écran distant. La sortie physique est hors sujet. Le lisez-moi vise l'interface vidéo Vulkan pour présentation et encodage dans les invités ; quatre sessions légères ont tourné ensemble. De quoi viser plusieurs environnements Linux distants avec accès graphique.
La liste des non compte autant. Des invités non fiables exigent une isolation sûre ; l'auxiliaire isolé et l'infrastructure multi-locataire sont inachevés, donc l'usage conjoint ne prouve aucune séparation. CUDA en est à l'énumération de l'appareil ; aucun calcul achevé, inférence locale ou entraînement n'est montré. La compatibilité dépend de l'interface transmise, l' ABI de pilote ; garder le pilote inchangé ne rend pas tout mélange de versions compatible. L'utilisateur de bureau unique n'y gagne rien de démontré ; ajouter des invités à une carte saturée ne crée aucune ressource.
Moments clés
Commentaire de l’IA
"La discipline de mesure fait la valeur du propos : les chiffres sont annoncés sans détour et ce qui n'a pas été montré est nommé un par un."
Évaluation de l’IA
La contre-thèse la plus forte est simple : le partage résout l'accès, pas la capacité. Quatre invités se partageant la même charge synthétique ont maintenu le total à 103,69 images par seconde, avec environ 26 chacun, loin des 102,9 de l'invité unique. Le comportement de quatre applications lourdes et différentes ensemble n'a jamais été mesuré, donc aucune leçon de capacité ne peut en être tirée.
La liste des manques est longue et assumée : aucun quota fixe ni équité garantie, aucune tranche protégée de mémoire prouvée, infrastructure d'isolation et auxiliaire isolé inachevés, CUDA au stade de l'énumération seulement, Windows et jeu multi-utilisateur hors sujet. La documentation Nvidia décrit le partitionnement matériel MIG avec isolation forte, ce que cette expérience n'offre pas. La documentation QEMU décrit déjà des chemins virtio-gpu intégrés, donc la dépendance à une interface de pilote de plus reste un risque propre.
L'intérêt probable de l'intervenant est d'orienter les curieux plutôt que de vendre une installation : aucun conseil d'installation pour le bureau unique, une liste de suivi pour les amateurs de machines virtuelles Linux. Ce ton équilibré inspire confiance. Pourtant la contradiction interne sur le support multi-invité suggère une discipline de version encore fragile sur GitHub ; le résumé Linuxiac souligne de même le statut expérimental.
La conclusion pratique est étroite : si plusieurs invités Linux ont besoin d'accélération graphique en même temps et que des sessions légères à distance suffisent, le projet mérite suivi ; avec 12 Go de mémoire la RTX 3060 forme une base raisonnable pour de tels essais selon la base TechPowerUp. Si une charge sature déjà la carte, le passage direct mono-invité du guide archlinux.org reste la voie prévisible. Avant d'éviter un achat, exigez des mesures de votre application, par invité et au total.
Sources
7 liens ; aucun autre article publié ne les cite. Stories sharing a link do not confirm each other; a source's origin is not inferred from how often it is cited.
virtio-nvgpu · partage gpu · kvm · rtx 3060 · machines virtuelles