WebRTC desktop console for Proxmox VE — looking for feedback

[rdmitry0911]

Hi guys, I've been working on a WebRTC console for Proxmox VE and would like to share it here. I wanted to use a VM desktop directly in the Proxmox web interface, with smoother scrolling, video and sound and copy/paste, without opening a separate remote desktop client. I've managed to get this working as an add-on for PVE 9 called QSM Direct. All dektop graphics runs smoothly. I can even watch youtube clips comfortably with it over the Internet, not only in LAN

It takes the VM's display from QEMU over D-Bus and streams it to the browser. The console uses the existing PVE login and VM.Console permission. For VMs, desktop capture and keyboard/mouse input don't need a remote desktop server inside the guest. Clipboard integration needs a guest component.

What works in the add-on:
- H.264 streaming with NVENC, QSV or VA-API, with CPU encoding as a fallback;
- virtio-gl for an accelerated Linux desktop, as well as non-GL display profiles;
- sound, microphone and text clipboard in both directions;
- the console inside the PVE interface or in a separate browser window.

My GPU test setup is PVE 9 with an RTX 3080 and a Linux KDE guest. The stream runs at 1280x800, 60 fps with NVENC. That is the stream rate; the number of different pictures depends on what the guest renders.

I also compared the two consoles on the same Standard VGA VM in a CPU-only lab. A 30 fps 720p clip delivered about 27 different pictures/s through QSM and 7 through noVNC, using about 20 and 120 Mbit/s respectively. The setup, method and results are here

One limitation worth mentioning: with the GL D-Bus display, QEMU cannot offer VNC or SPICE alongside it. A non-GL profile can keep VNC. The current add-on also needs TCP 8007 and UDP access from the browser to the node. Installation details are in the repository

There is also a graphical console for LXC containers with a KDE desktop, supplied as a separate add-on with software inside the container.

I've posted an RFC to pve-devel and prepared patches for qemu-server and pve-manager. This is still an add-on and an upstream proposal. Alexandre Derumier has a related RDP/Kyber series using QEMU's D-Bus display. I've tested its capture path on NVIDIA and prepared a fix; he has now replied and welcomed reworking his patches. I'd like the consoles to share the same D-Bus foundation.

RFC and discussion
Feature request

the prototype was developed with help from an AI coding assistant, and reviewed and tested the code myself.

Does anyone else use the PVE browser console for desktop work? I'd be interested in feedback, especially from people with Intel or AMD GPUs, as my hardware testing has mainly been on NVIDIA. Any feedback would be very much appreciated.

Thank you, Dmitry

 

[rdmitry0911]

Hi guys, I've been working on a WebRTC console for Proxmox VE and would like to share it here. I wanted to use a VM desktop directly in the Proxmox web interface, with smoother scrolling, video and sound and copy/paste, without opening a separate remote desktop client. I've managed to get this working as an add-on for PVE 9 called QSM Direct. All dektop graphics runs smoothly. I can even watch youtube clips comfortably with it over the Internet, not only in LAN

It takes the VM's display from QEMU over D-Bus and streams it to the browser. The console uses the existing PVE login and VM.Console permission. For VMs, desktop capture and keyboard/mouse input don't need a remote desktop server inside the guest. Clipboard integration needs a guest component.

What works in the add-on:
- H.264 streaming with NVENC, QSV or VA-API, with CPU encoding as a fallback;
- virtio-gl for an accelerated Linux desktop, as well as non-GL display profiles;
- sound, microphone and text clipboard in both directions;
- the console inside the PVE interface or in a separate browser window.

My GPU test setup is PVE 9 with an RTX 3080 and a Linux KDE guest. The stream runs at 1280x800, 60 fps with NVENC. That is the stream rate; the number of different pictures depends on what the guest renders.

I also compared the two consoles on the same Standard VGA VM in a CPU-only lab. A 30 fps 720p clip delivered about 27 different pictures/s through QSM and 7 through noVNC, using about 20 and 120 Mbit/s respectively. The setup, method and results are here

One limitation worth mentioning: with the GL D-Bus display, QEMU cannot offer VNC or SPICE alongside it. A non-GL profile can keep VNC. The current add-on also needs TCP 8007 and UDP access from the browser to the node. Installation details are in the repository

There is also a graphical console for LXC containers with a KDE desktop, supplied as a separate add-on with software inside the container.

I've posted an RFC to pve-devel and prepared patches for qemu-server and pve-manager. This is still an add-on and an upstream proposal. Alexandre Derumier has a related RDP/Kyber series using QEMU's D-Bus display. I've tested its capture path on NVIDIA and prepared a fix; he has now replied and welcomed reworking his patches. I'd like the consoles to share the same D-Bus foundation.

RFC and discussion
Feature request

the prototype was developed with help from an AI coding assistant, and reviewed and tested the code myself.

Does anyone else use the PVE browser console for desktop work? I'd be interested in feedback, especially from people with Intel or AMD GPUs, as my hardware testing has mainly been on NVIDIA. Any feedback would be very much appreciated.

Thank you, Dmitry

Hi guys, a small update. I've now moved the WebRTC console onto the shared
per-VM D-Bus foundation from Alexandre's patches. qemu-server owns the bus
and QSM connects to it as a consumer, so other console implementations can
use the same display too.

The native integration now uses the normal Proxmox API on8006 for both VMs
and LXC containers. TCP8007 and the separate certificate exception are no
longer needed for this version. WebRTC still needs UDP access between the
browser and the node.

I also fixed the Firefox connection and Reconnect issues I ran into during
VPN testing. I've checked VM video/Reconnect and the LXC graphical console
with the old signalling service stopped, including saving the container's
media settings through the PVE API.

The source and matching deb packages are here

This is a preview build with matching patched Proxmox packages; the release
notes list what to install. The shared-base patches are still an upstream
proposal. The older stock-PVE add-on continues to use8007.

If anyone tries this with Intel or AMD encoding, I'd be interested in how
it works on your setup. Thank you for any feedback.

 

[chrcoluk]

The shift to 8006 is good enough for me to try it out. Will try it on my local Proxmox.

 

[rdmitry0911]

Hi guys, a small update on the LXC desktop console.

I've now added the real SDDM login screen with the standard KDE Breeze theme. It has the usual user selection, password prompt and desktop session selector. SDDM/PAM handles authentication using the container's normal user accounts. Logging out brings you back to the login screen in the same browser console.

Different local users can also run desktops on separate console seats at the same time. Keyboard layout switching works on the login screen too; I've checked Russian input with Shift and German AltGr.

I've tested Firefox and Chromium, login/logout and reconnect on an unprivileged Ubuntu 24.04 container with Plasma Wayland. Plasma also uses hardware rendering on the RTX 3080 passed through to my test container. The Breeze theme comes from the normal distribution package; its files are unchanged.

Source and matching deb packages

The native SDDM profile is optional and needs to be enabled explicitly. For now I've qualified Ubuntu 24.04 / Qt 5 / Plasma Wayland. It also needs VKMS with configfs support in the host kernel. Setup, theme selection and rollback instructions

Signalling still uses the normal PVE API on 8006; WebRTC media needs UDP access. This remains a preview on the patched shared-platform setup.

@chrcoluk, thank you for offering to try it. I'd be interested to hear how it works on your setup. If anyone uses LXC for a desktop, feedback on the login and session behaviour would also be very welcome.

Also feedback on accessing the guests from android tablets / ios ipads would help a lot to move forward.

Thank you, Dmitry

 

[rdmitry0911]

Hi guys, another update on mouse responsiveness and video playback.

The LXC console can now draw the guest cursor locally in the browser, including its shape and hotspot. Moving the mouse no longer waits for the next video frame. This made a noticeable difference when using the desktop over VPN. I've also improved input delivery and capture timing.

I've made changes to video packet sizing, pacing and encoder buffering to improve playback over VPN. These video changes apply to both VM and LXC consoles using the native QSM Direct integration.

The maximum video bitrate is now configurable per VM or container in Settings, from 0.5 to 100 Mbit/s, with 8 Mbit/s as the default. With NVENC or software H.264, the working bitrate adapts to network conditions below that limit. Settings shows the current target. QSV and VA-API still use fixed rate control.

During testing I also found a problem where text and details repeatedly became blurry and sharp again, even on a static desktop. Unnecessary bitrate changes and full keyframes every half second both contributed to it. The latest build avoids those repeated changes and sends recovery keyframes when needed. I've now checked the fix in Firefox over the actual VPN connection, and the blur/sharpen pulsing is gone on that setup.

In controlled Firefox tests with an LXC desktop, I reduced the available bandwidth from 20 to 4 Mbit/s and then restored it. Both NVENC and software H.264 lowered their bitrate and returned to the configured 8 Mbit/s limit without reconnecting. The sudden bandwidth drop still caused brief recovery pauses. The test scripts and results are included with the release.

Source, deb packages and test results — shared22

Local cursor support for LXC needs the optional Sway 1.11/wlroots package; setup details are here. This remains a preview on the patched shared-platform setup.

If anyone tries it, I'd be interested in how mouse movement and video playback feel in your browser, especially over VPN or on a tablet. Please mention whether you're using a VM or LXC, your browser and the encoder.

Thank you, Dmitry

 

[rdmitry0911]

Hi guys, another update on Intel encoding, HEVC and adaptive bitrate.

QSV and VA-API now support adaptive bitrate too, for both H.264 and HEVC. The configured maximum remains the upper limit. I've also fixed Intel encoder issues that appeared during bitrate changes and low-bitrate playback.

I've tested HEVC with Intel QSV, Intel VA-API and NVIDIA NVENC using real Chrome receivers and an LXC desktop at 1280×800, 60 fps. In controlled network tests, I reduced the available bandwidth from 20 to 3 Mbit/s and then restored it. All three lowered their bitrate and returned to the configured 8 Mbit/s limit
without reconnecting. Moving pictures continued after recovery. The sudden bandwidth reduction still caused brief freezes, so there is more work to do here.

HEVC depends on the browser's WebRTC support. It worked in the tested Chrome 147/Linux configuration with hardware decoding. The tested Firefox build did not offer HEVC for WebRTC; automatic selection used H.264 instead. These results don't establish support across all browser and GPU combinations.

I also found a remaining issue while testing HEVC NVENC: occasional packet loss can still trigger an unnecessary bitrate reduction, making static text briefly become blurry and sharp again. In one run, a single lost packet was enough to lower the target from 8 to 6 Mbit/s. A separate fixed-bitrate control kept the
same text stable.

This remains open in the adaptive controller. The controller is shared by H.264 and HEVC, so I wouldn't call it HEVC-only, but I've reproduced this particular static-text case only with HEVC NVENC so far.

The video changes use the shared VM/LXC streaming code; the latest browser congestion tests were performed with LXC desktops.

Source, matching deb packages and test reports — shared24

This remains a preview requiring the matching patched Proxmox packages. If anyone tries Intel encoding or HEVC, I'd be interested in your results. Please include your GPU, browser, selected codec and encoder, and whether you're connecting over LAN or VPN.

Thank you, Dmitry

 

[rdmitry0911]

Hi guys, another update on stock PVE support, access through NAT and the remaining text-sharpness issue.

There is now a standalone package for official PVE 9, without installing rebuilt Proxmox packages. The patched shared-platform integration remains a separate upstream proposal.

I've also added an optional gateway for a node behind a router with only TCP 8006 forwarded. PVE HTTPS, QSM signalling and authenticated TURN over TCP share that port, so no extra public signalling port or incoming UDP range is needed. The browser uses the public hostname and port of the PVE page; the relay is configured with the node's LAN address. Direct UDP remains available where the network allows it, as TCP can add latency under packet loss.

A clarification about encryption: the UI, login and signalling use HTTPS, video/audio use SRTP, and input/clipboard use DTLS-protected data channels. The outer TURN connection currently uses plain TCP, not TURN/TLS. Its service messages are visible, while the desktop, sound and input payloads remain encrypted between browser and QSM. This is not an HTTPS-only transport.

The unnecessary bitrate reduction described in my previous post is fixed. A single lost packet in a short receiver report no longer makes the controller cut the target from 8 to 6 Mbit/s. With adaptation enabled, H.264 NVENC and HEVC NVENC static-text tests with occasional injected loss kept the target and text stable. Sustained congestion still lowers the bitrate and recovery returns it to the configured maximum. A large sudden bandwidth drop can still cause brief freezes.

I've checked VM and LXC video/reconnect in Chrome and Firefox in a controlled NAT lab allowing only TCP 8006 plus established traffic. I've also checked the gateway on my regular node with Firefox and Chromium using a test LXC. Those node checks were over LAN; they are not a completed test through my own Internet router.

The gateway is still an experimental, explicitly enabled single-node profile. It changes the PVE proxy listener and affects external SPICE after its service restarts. Please read the installation and rollback notes, especially for an existing patched setup or custom proxy configuration.

Source, matching debs, installation instructions and test reports:

Feedback from NAT/restricted networks would be very welcome. Please mention your browser, VM or LXC, codec/encoder and whether you're using the gateway or direct UDP.

Thank you, Dmitry

 

[rdmitry0911]

Hi guys, a small installation update.

I've added a signed APT repository for the standalone packages, so there's no need to download matching deb files manually for every update. It targets PVE 9 on Debian 13 (trixie), amd64, and contains only QSM packages. The official Proxmox packages stay in place.

Key fingerprint and repository setup:
https://rdmitry0911.github.io/qsm-rd/

After adding the repository as described there:

apt update
apt install qsm-archive-keyring qsm-pve-direct-standalone

The core is pulled in automatically. qsm-pve-direct-lxc is the optional host helper for LXC desktops; qsm-pve-direct-gateway provides the optional single-TCP-8006 gateway tools. Installing the gateway package does not enable it: please follow its activation and rollback instructions first. The qsm-console-guest package belongs inside a container, not on the PVE host.

The debs are the same stock3 build described in my previous post; this update adds signed APT distribution and upgrade instructions. Please mention your PVE version and any installation/update problems here or in the GitHub issues.

Thank you, Dmitry

 

[rdmitry0911]

Hi guys, an update on text sharpness and input reliability. The signed APT repository now has stock4.3.

The earlier packet-loss fix did not cover genuine bandwidth changes: resetting the encoder could still hange the quality of unchanged parts of the desktop, sometimes in horizontal bands. The worker now keeps its encoder settings and budgets pictures before encoding. A narrow connection reduces motion cadence rather than repeatedly changing the static background. Sudden large bandwidth drops can still cause recovery pauses.

In Firefox, controlled 8 → 2 → 8 Mbit/s target changes left the checked text region unchanged across 2111 frames. A separate Chromium test with an actual 20 → 1 → 20 Mbit/s connection recovered to 60 fps without reconnecting, with pauses during the abrupt drop. These checks cover NVENC H.264/HEVC and H.264 browser reception; I have not repeated Intel/AMD hardware qualification for this update.

There is also a more complete fix for repeated characters. Releasing keys on focus loss helped, but a delayed release could still let the guest start its own autorepeat. Exact typing is now the default: each press or real client repeat crosses as one complete action with its modifiers. The first character is immediate.

In Firefox with a real LXC desktop and a 900 ms control-delivery gap, one short press gave 8 characters in the old mode and 1 in Exact typing. Six confirmed client events gave six characters.

Exact clicks extends this to mouse, trackpad taps/clicks and touchscreen taps. A short click is sent on release with its coordinates and modifiers. Moving 4 pixels with a button down or holding for 250 ms starts a drag/hold; drag movement and release stay ordered. Fractional trackpad scroll deltas are retained, including horizontal scrolling. The existing touchscreen hold-to-drag gesture stays the same.

Double click, right click, intentional holds, dragging and both scroll axes passed the browser/desktop tests. I have not qualified a physical trackpad yet. Physical holds and Raw input remain available when an application needs immediate held input. A connection stall can end a drag early, and native double-click timing can still be affected by delivery jitter.

The common VM/LXC paths are updated. The standalone profile works with official PVE 9 packages. Source, all five matching debs, installation guides and test reports:

https://github.com/rdmitry0911/qsm-rd/releases/tag/v0.4.0-qsm-direct-20261024-stock4.3

For an existing installation using the signed APT repository:

apt update
apt install --only-upgrade qsm-pve-direct qsm-pve-direct-standalone qsm-pve-direct-lxc qsm-pve-direct-gateway

The --only-upgrade option skips uninstalled profiles. Reload the PVE page with cache bypass and reopen consoles. No VM/LXC reboot, guest-agent update or desktop reprovisioning is needed. If you previously selected Raw, choose Guest first with Exact typing and Exact clicks to try these defaults.

Feedback would be welcome, especially from Firefox/VPN and trackpad users. Please mention VM or LXC, browser, encoder/codec, and direct UDP or the TCP 8006 gateway.

Thank you,
Dmitry

 

[rdmitry0911]

Hi guys, another update on keyboard handling and the single-port setup. The signed APT repository now has stock4.13.

There is an explicit Capture keyboard button in the left toolbar and Settings. It requests fullscreen keyboard capture through the browser, so F11 is not needed. With supported capture, a short Esc and available browser shortcuts go to the guest. Opening Settings or switching to another host application no longer exits fullscreen. Held guest keys/buttons are released when focus leaves; returning resumes capture without restoring old holds. Release keyboard and Exit Full Screen are separate actions, and the toolbar handle stays at the left edge.

The existing Settings > Keyboard shortcut priority > Host shortcuts list now controls complete combinations, including modifier-only shortcuts. Alt+Tab, Meta+Tab and combinations such as Alt+Shift, Ctrl+Shift and Meta+Shift default to Host / browser. To use one in the guest, change its exact rule to Guest or remove it. Edits and removals persist. A reserved host shortcut no longer leaks its leading Alt/Meta press into the guest.

Completed modifier-only guest shortcuts are sent on the first release, without an extra timer, preserving the order in which the modifiers were pressed. This matters for layout switching. I checked both release orders through an actual VM USB keyboard and Plasma: Alt+Shift worked, and Meta+Shift worked after adding that binding in the guest. QSM's routing rule does not configure the guest's layout shortcut.

Guest first also respects logical Option/Command remapping. OS-reserved shortcuts can still be handled by the host before a web page receives them; Send to guest buttons remain available. The automated Mac modifier cases are modelled on Linux, so feedback from physical Macs would be useful.

I've also checked the optional TCP 8006 gateway on another stock PVE 9.2 node with a Debian 13 / Plasma Wayland LXC desktop in Firefox. Video, control and pointer channels connected through TURN over TCP on 8006; the separate service listeners stayed on loopback. PVE and QSM therefore share the existing public port, with no extra incoming UDP range. The gateway remains an explicitly enabled single-node profile; its activation and rollback instructions still apply. Media/input payloads remain encrypted; outer TURN control uses plain TCP, as described in the earlier post.

Source, matching debs, installation guides and test reports (https://github.com/rdmitry0911/qsm-rd/releases/tag/v0.4.0-qsm-direct-20261025-stock4.13)

Signed APT repository and setup (https://rdmitry0911.github.io/qsm-rd/)

For an existing APT installation:

apt update
apt install --only-upgrade qsm-pve-direct qsm-pve-direct-standalone qsm-pve-direct-lxc qsm-pve-direct-gateway

This upgrades the profiles already installed. Reload PVE with cache bypass and reopen consoles, then click Capture keyboard. These input/UI fixes need no guest package update or guest reboot. Restarting QSM services interrupts existing console connections while guests keep running.

Feedback on layout shortcuts, remapped Mac modifiers and the 8006 gateway would be welcome. Please include your browser/OS, VM or LXC, the shortcut rule and the guest's own binding.

Project sponsor: Takt (https://taktcycles.com/).

Thank you, Dmitry

 

[rdmitry0911]

Hi guys, I've added an experimental mixed-content mode for sharper text and faster desktop updates while video is playing.

The existing video stream is still there. QSM now also sends small, losslessly compressed pixel tiles for text and other compressible UI areas over a separate WebRTC data channel. The browser draws these above the video, using the guest's actual pixels. There is no OCR or replacement font rendering. Frequently changing areas stay in the video path and can be refined when they settle.

I specifically tested typing in a separate text window overlapping a playing clip. The entered string arrived without missing or repeated characters, and the uncovered part of the clip kept moving. Scrolling, moving, resizing and closing the window also passed the checks, including sampling its old position for reappearing tiles.

In one controlled Firefox/LXC run, the median visible response to a typed key in that overlapping window went from 157 to 59 ms on a 20 Mbit/s link, and from 176 to 75 ms with the downlink limited to 2 Mbit/s. Each case used 15 keys and a guest-drawn marker updated by the text field. These are small laboratory measurements at LAN RTT, not an RDP comparison or a claim about every Internet connection. A 512x128 text-area crop matched all 65,536 guest pixels exactly.

There are still limits: a large newly opened text window needed about 4.5 seconds for full refinement at the narrow target. The video still encodes the whole desktop; this first version has no CopyRect/scroll protocol or separately cropped video stream. Live mixed-content testing so far covers LXC, Firefox and H.264/NVENC; the installed service was also checked with libx264. Equivalent VM, HEVC, QSV and VA-API runs are still needed. The implementation uses the common VM/LXC capture path, but that does not replace those tests.

Source, experimental debs, installation and test reports:
https://github.com/rdmitry0911/qsm-rd/releases/tag/v0.4.0-qsm-direct-20261027-exact-ui-exp6-source1

This is a separate experimental build, 0.4.0+stock4.14~exp6. The signed APT feed remains on stock4.13. The mode is off by default in the package: enable Settings > Experimental exact UI after installing the matching experimental profiles and reloading PVE. There is also a documented node default; an explicit browser choice overrides it. No guest package update or guest reboot is needed. Restarting QSM services interrupts console connections while guests keep running.

The extra layer uses the existing DTLS-protected WebRTC connection. With the optional single-port gateway, it also goes through TCP 8006; no additional public port is required.

Feedback on mixed text/video windows would be useful, especially on VMs and on higher-latency links. Please include the browser, codec/encoder, guest type, transport and whether the text window overlaps video.

Project sponsor: Takt (https://taktcycles.com/).
Thank you, Dmitry

 

[rdmitry0911]

Hi guys, the mixed-content mode from my last post is now on by default, and this version is on the signed APT repository: 0.4.0+stock4.14~exp216.

Text, menus and other UI areas no longer wait for the video encoder. They arrive as the guest's own pixels, losslessly, and video is cropped to what is actually moving. Scrolling and window drags reuse pixels the browser already has instead of sending them again.

I measured interface responsiveness against RDP, because that is the feel people expect. PVE container with NVENC in Chromium, against Windows Server 2025 RDS with FreeRDP, on a flat backdrop, with QSM first and RDP second:

20 Mbit/s, 15 ms one-way delay:
- typing 45 / 39 ms
- click 45 / 67 ms
- first drag movement 54 / 92 ms
- drag lag 44 / 48 ms
- wheel, settled 68 / 41 ms

2 Mbit/s gives almost the same numbers. At 100 ms delay, typing and wheel are 6-28 ms behind RDP, click and the start of a drag are 14-35 ms ahead, and drag lag is equal.

Please read those with the limits. The client was FreeRDP, not mstsc, and OS, toolkit and compositor all differ, so this is not a clean single-variable test. A flat backdrop is the best case: at 2 Mbit/s and 100 ms, with text behind the moved window, drag lag rises to about 290 ms. QSM also used about 3 MB where RDP used 50-107 KB in the same run.

VMs are not at this level yet. In my QEMU test guest with KWin, the same type, click and wheel actions take about 155-175 ms, and dragging over text at 2 Mbit/s reaches about 400 ms. Removing window shadows took that from 300-426 ms to about 180 ms. The guest package has a small helper for it, qsm-desktop-effects reduce. It only runs if you run it, since it changes how the desktop looks.

Clips hold up too. A real 720p60 clip, full screen, at 2 Mbit/s runs at about 44 fps on NVENC in a container and 49-51 fps on Intel QSV/VA-API in a VM, with median SSIM around 0.95. These are distinct source frames, not received frames. On the container sound path, sound follows the picture by about 30-40 ms.

Known problems: with the mode turned off, a full-screen clip at 2 Mbit/s stays near 15 fps with sound about 200 ms ahead. HEVC works but gives fewer frames for three times the bytes, so I still recommend H.264. Automated runs of this version did not cover a Mac, a phone or a tablet.

One warning: do not enable hardware video decoding inside a VirGL guest. With zero-copy the guest hit an illegal command buffer at the first frames, and one run reset the host's AMD GPU. Software decoding in the guest works correctly.

To update, include every QSM profile you have installed:

apt update
apt install --only-upgrade qsm-archive-keyring qsm-pve-direct qsm-pve-direct-standalone

Add qsm-pve-direct-lxc and qsm-pve-direct-gateway if you use them. Then reload PVE with cache bypass and reopen your consoles. Restarting the QSM services interrupts open consoles, but guests keep running and don't need an update or a reboot. To turn the mode off, use Console settings > Exact UI.

Release notes, source, debs and raw test runs: https://github.com/rdmitry0911/qsm-rd/releases/tag/v0.4.0-qsm-direct-20261106-stock4.14-exp216

APT repository: https://rdmitry0911.github.io/qsm-rd/

Reports from VMs, Macs, phones and higher-latency links would be the most useful right now. Please include the browser, guest type, encoder and whether you are on direct UDP or the TCP 8006 gateway.

Project sponsor: Takt (https://taktcycles.com/).
Thank you, Dmitry

 

[rdmitry0911]

Hi guys, the console now has a two-pane file manager, like AnyDesk's, and this version is on the signed APT repository: 0.4.0+stock4.14~exp223.

Files in the console's toolbar shows your computer on the left and the guest on the right. Files and folders copy both ways, and on the guest's side you can make a folder, rename and delete. The console keeps running underneath.

No new port is needed. Transfers go over a WebSocket on the same path as the console's signal requests, so on a node with the gateway it is still only TCP 8006. A transfer takes whatever bandwidth the console leaves: keys, UI, video and sound go first.

It does not get around the guest's login or lock. The files are served by a helper in the logged-in user's desktop session, with that user's permissions, and a locked session refuses new work. On the PVE side, browsing and downloading need VM.Console and VM.GuestAgent.FileRead, and uploads and changes also need VM.GuestAgent.FileWrite. A role with VM.Console alone gets no file access.

Numbers from my lab:
- 10 Gbit/s LAN through TLS and the gateway's HAProxy: about 100 MiB/s steady each way, 70-79 MiB/s for a whole 1 GiB file including the ramp
- into and out of a real KVM VM through its virtio port: 77 and 79 MiB/s
- 20 Mbit/s path: the transfer gets 18 Mbit/s, and the console stays where it was, apart from typing 5-10 ms slower during a download
- 2 Mbit/s path: the transfer gets 1.1-1.8 Mbit/s, and the console gets up to about 25 ms slower while it runs
- a clip keeps its frame rate during a download; with an upload it recovered from the narrow phase about 3 fps lower

Browser notes. Chrome and Edge let you open a folder of your computer in the left pane, but Chrome refuses your home folder, Desktop, Documents and Downloads themselves and system folders, and says they "contain system files". Make a folder inside Downloads, for example QSM, and choose that. Firefox gives a web page no folder access, so there you choose files with Add files... or Add folder..., or drop them on the pane. Downloads go to the browser's Downloads folder and are listed in the pane, and a folder downloads as one .tar.

Known limits: a lost connection starts the current file over, there is no resume yet. 10 Gbit/s is not filled. During an upload into a VM a clipboard paste can wait about 200 ms. Linux guests only, and the texts are in English. My automated runs did not cover a VM through a real PVE console (that was on a stand with the real agent and virtio port), a lossy path, a Mac, a phone or a tablet.

Two fixes in this version matter even if you never open the file manager. A TCP connection that sent nothing could stall the TLS handshake and keep every new console out of a node without the gateway. And on a container's native login, a slow logind under memory pressure could end every desktop on the seat.

To update the node, include every QSM profile you have installed:

apt update
apt install --only-upgrade qsm-archive-keyring qsm-pve-direct qsm-pve-direct-standalone

Add qsm-pve-direct-lxc and qsm-pve-direct-gateway if you use them. Then reload PVE with cache bypass and reopen your consoles. Restarting the QSM services interrupts open consoles, but guests keep running.

For the file manager the guest needs its package updated too. In a container with the native login, update qsm-console-guest, and the helper starts at the next desktop login. In a VM, update qsm-desktop-agent and run:

sudo qsm-desktop-agent-setup USER
sudo systemctl restart qsm-desktop-agent@USER

The desktop session survives that restart, and the helper starts at the next login.

Release notes, source, debs and raw test runs:
https://github.com/rdmitry0911/qsm-rd/releases/tag/v0.4.0-qsm-direct-20261107-stock4.14-exp223

APT repository:
https://rdmitry0911.github.io/qsm-rd/

Reports from VMs, Windows clients, Macs and slow or lossy links would help most. Please include the browser, guest type and whether you are on direct UDP or the TCP 8006 gateway.

Project sponsor: Takt (https://taktcycles.com/).
Thank you, Dmitry