Nous venons de lancer le service. Le site et le service sont encore en cours de finition : nous vous prions d’excuser d’avance d’éventuelles imprécisions ou maladresses. Vous avez repéré une erreur ou quelque chose ne fonctionne pas comme prévu ? Écrivez-nous, nous corrigerons rapidement.

← Tous les projets
FR
Au-delà de TAKT

qsm-rd

QSM Direct remplace l’image noVNC de la console web de Proxmox VE par un flux vidéo WebRTC, dans le même onglet du navigateur, avec la même connexion PVE et la même permission VM.Console. Rien n’est installé côté client, et pveproxy et pvedaemon fonctionnent sans modification.

  • Proxmox VE
  • WebRTC
  • LXC
Statut
Version 0.4.0. HEVC est expérimental, et la migration à chaud d’une VM avec QSM Display1 n’a pas été qualifiée. Une demande de fonctionnalité a été déposée auprès de Proxmox (bug #8106) ; un RFC et des séries de correctifs pour qemu-server et pve-manager sont préparés dans le dépôt.
Licence
GPL-3.0-or-later ; le script de console PVE, le service de signalisation, la console LXC et la page de visualisation sont sous AGPL-3.0-or-later.
Plateformes
Nœuds Proxmox VE 9 ; côté client, un navigateur avec H.264 et Opus en WebRTC.

Le problème résolu

La console noVNC standard envoie les rectangles d’écran modifiés. Pour travailler dans un bureau en cours d’exécution, avec de la vidéo, du défilement ou des interfaces animées, cela donne peu d’images distinctes par seconde pour une bande passante élevée, et pas de 3D dans l’invité. QSM Direct encode l’affichage de l’invité en vidéo sur le nœud et le diffuse vers le navigateur. Le README publie une comparaison mesurée avec noVNC standard, y compris les cas où noVNC reste le meilleur outil : la première image, un événement de pointeur isolé et tout ce qui précède le démarrage d’un OS.

Fonctionnalités principales

  • H.264 par défaut via NVENC, QSV, VA-API ou libx264 sur le CPU ; HEVC comme choix explicite et expérimental par VM.
  • Invités VirGL avec OpenGL et 3D, ou adaptateurs Standard VGA, VirtIO et VMware sans GPU.
  • Son (Opus), micro du navigateur dans l’invité et presse-papiers texte dans les deux sens ; dans une VM, le presse-papiers nécessite un agent invité optionnel.
  • Les mouvements du pointeur passent par leur propre voie non ordonnée, qui ne garde que le dernier état, et ne peuvent pas s’accumuler derrière une image chargée.
  • Conteneurs LXC avec un bureau KDE Plasma : une console par tty, chacune avec son propre écran de connexion.

Fonctionnement

Le navigateur envoie son offre WebRTC à un service de signalisation local au nœud, sur le port TLS 8007. Le service vérifie le ticket PVE du navigateur et la permission VM.Console via le propre /access/ticket de PVE, puis transmet l’offre à un service terminal qui lance un worker média par VM. Le worker lit l’affichage D-Bus de QEMU, encode l’image et le son et les envoie directement au navigateur ; les entrées reviennent par le même chemin. Tous les spectateurs d’une même VM partagent un seul flux d’encodeur.

apt install ./qsm-pve-direct_*.deb
systemctl enable --now qsm-pve-direct-terminal.service qsm-pve-direct-signal.service

Prérequis

  • Proxmox VE 9 (pve-manager 9.x) ; le paquet se construit sur Debian 13 et s’installe sur chaque nœud susceptible d’exécuter la VM.
  • Navigateur : Chrome, Edge, Chromium avec codecs propriétaires, Safari, ou Firefox avec le plugin OpenH264.
  • Réseau : TCP 8006 et 8007 et UDP entrant depuis les réseaux des opérateurs ; un nom d’hôte pour lequel le certificat du nœud est valide.
  • Encodeur : NVENC, QSV, VA-API ou le CPU (environ un demi-cœur par console ouverte avec libx264) ; le profil VirGL nécessite un périphérique de rendu DRM. Jusqu’à 16 sessions de console par nœud.

Cette page résume le README et la documentation du dépôt à la date d’octobre 2026. La référence reste le dépôt lui-même.