[SOLVED] Warum und wie funktioniert NoVNC
- Thread starter TErxleben
- Start date
Ich kann dir keinen detaillierten technischen Breakdown geben wie das alles genau implementiert ist in Proxmox. Aber noVNC ist ein JavaScript-basierter VNC-Client, der für die Proxmox-Webkonsole verwendet wird und die VNC-Ausgabe über HTML5/Canvas im Browser darstellt. Die virtuelle Grafikkarte stellt dabei den Bildschirminhalt bzw. Framebuffer der VM bereit. QEMU hat einen integrierten VNC-Server, der diesen Bildschirminhalt über das VNC-Protokoll bereitstellt. noVNC verbindet sich damit und stellt die empfangenen Bildschirminformationen anschließend im Browser dar.
Vereinfacht gesagt: VM → virtuelle Grafikkarte/Framebuffer → QEMU VNC-Server → VNC → noVNC → HTML5 Canvas → Browser
Vereinfacht gesagt: VM → virtuelle Grafikkarte/Framebuffer → QEMU VNC-Server → VNC → noVNC → HTML5 Canvas → Browser
Last edited:
Eigentlich ist die QEMU-Schicht die einzige logische Zwischenschicht, die VNC eben grundsätzlich mitbringt.
Nach längerer vorher vergeblicher Suche, habe ich auch eine Bestätigung gefunden:
https://www.qemu.org/docs/master/tools/qemu-vnc.html
Bei LXC gibts die QEMU-Schicht ja gar nicht, da läuft es anders. PVE startet dort
Der Browser redet nie direkt mit dem VNC-Server. Der lauscht nur auf localhost. pveproxy leitet das per WebSocket auf Port 8006 weiter (
vncterm. Das ist ein kleiner VNC-Server, der intern ein Terminal emuliert und darin lxc-console laufen lässt. Für noVNC sieht das dann genauso aus wie eine VM, ist aber nur eine gerenderte Textkonsole. Beim Node-Shell läuft das ähnlich. Wer xterm.js als Konsole nimmt, bekommt über termproxy direkt den Textstream und gar kein VNC.Der Browser redet nie direkt mit dem VNC-Server. Der lauscht nur auf localhost. pveproxy leitet das per WebSocket auf Port 8006 weiter (
.../vncwebsocket in der API), und die Auth läuft über das VNC-Ticket aus dem vncproxy-Call. Deshalb klappt die Konsole auch ohne extra offene Ports und mit den normalen PVE-Rechten (VM.Console).