qKVMDocs
All pages

VNC servers

Any machine that runs a VNC server can be on the wall: a virtual machine whose hypervisor shows its screen that way (QEMU, libvirt and Unraid, by the port they give each guest: see Proxmox and virtual machines; a guest of Proxmox has a kind of its own), a desktop with TigerVNC, TightVNC, RealVNC or x11vnc on it, a management controller whose own VNC server is switched on. Choose VNC servers in Add KVMs, type the address with its port after a colon where it is not 5900 (192.168.1.20:5901), and the VNC password; or type vnc://192.168.1.20:5901 with KVMs and servers chosen, which says the same. The tile is named after the name the server gives itself. Find KVMs on my network lists what greets as a VNC server on ports 5900 and 5901.

What works, and how:

  • The picture. qKVM speaks RFB (RFC 6143), the protocol of VNC, in Python: versions 3.3, 3.7 and 3.8; the Raw, CopyRect, Hextile, ZRLE and Tight encodings, JPEG within Tight included (OpenBMC's console sends that); a screen that changes its size. It asks for one pixel format of its own choosing and never leaves that to the server. It stays connected for as long as the machine is on the wall, as a viewer that shares the server with whoever else is connected, and asks for what changed every quarter of a second while somebody looks at the wall, every ten seconds while nobody does. A server that pushes frames at its own pace (obmc-ikvm does) is read all the same, and what it pushes while nobody looks is let go of without being decoded. The screen is kept as three bytes a pixel: a 1920 by 1080 screen takes 6 MB, and a screen wider or taller than 8192 pixels, or of more than 16 million pixels in all, is not shown.
  • Keys and text from the action menu go as X11 keysyms, which is what the protocol has: the server's own keyboard layout turns them into keys. A key combination is pressed in order and let go of in the other. Typed text is sent character by character, each as the keysym of that character (Latin-1 characters as themselves, others as Unicode keysyms); what the machine makes of a character its layout has not got is the server's business. Ctrl+Alt+Del is a chord like any other.
  • The password goes the way VNC authentication has it: the server's challenge encrypted with DES under a key made of the password's first eight characters (the rest is not looked at, by any server). That is weak, as RFC 6143 itself says: anybody who can read the line can take the challenge and the answer away and try passwords against them at leisure, and the pictures and keys that follow are in the clear. Keep VNC servers on a network you trust or behind a tunnel, and give the wall a VNC password that is used for nothing else. Over plain vnc:// the answer to the challenge goes to whatever answers at that address, since the protocol gives the wall no way to tell the server from an impostor. Where a server speaks TLS from the first byte (some management controllers do), type vncs://: the certificate is remembered on first contact, as for every device, and nothing is sent to what shows another. VeNCrypt, which puts TLS inside the protocol, is not spoken; a server that offers only that, or another way of signing in that qKVM does not speak, is said to on its tile. A server that asks for no password (security type None) is added with the password left empty.
  • A rejected password is left alone, on the same ladder as a KVM's (a minute, five, fifteen, then an hour), and while it waits the server is still asked whether it is there, by its greeting alone (inside TLS at a vncs:// address). VNC servers shut an address out after a few wrong passwords, for you as well.
  • A VNC server has no number of its own: it is known by its address and by the name it gives itself, and a machine added under two addresses is two tiles.
  • What a VNC server cannot do from here: there is no power button, no reboot, no Wake-on-LAN list, no keep-awake; the action menu offers them until it knows better, and each answers that a VNC server cannot do that. There is no Open console either, since a VNC server has no page of its own; a console link typed into the tile (the hypervisor's page, say) is used as it is.
  • What a server sends is not believed. Every length is checked against the screen the server announced before room is taken for it; a rectangle outside the screen, a stream that inflates past what its rectangle can hold, a message of a kind qKVM does not read, floods and stalls end the connection with a named reason on the tile, and the server is left alone for a while: one that sent what qKVM does not take for fifteen seconds, then twice as long each time it does so again, four minutes at the most, until a connection to it goes well. One that lets qKVM in and hangs up, at once or after a frame, is connected to as one that is down is: a second later, then twice as long each time, a quarter of a minute at the most. A connection that drew a frame and is found there five seconds after it began (on a still screen, at its next answer, within a minute) is the server there again. One that ends every connection after a time of its own (TigerVNC's MaxConnectionTime, a proxy's limit) is connected to again at once the first time; each end after that, before a connection has served four minutes, waits longer (15 seconds, a minute, then five), and its tile says that it ends every connection, not that it is offline, also while nobody looks. Somebody who watches it enlarged, and keys sent to it, have it connected at once all the same. (A server that stops answering is one that is down, as above.) What a server's pictures cost to draw is shared out, since a few kilobytes can cost seconds of drawing: every server's pictures are drawn in the same two threads, a few milliseconds at a time, one server's in half of a thread's time at the most and every server's together in three quarters (each may take a second's worth at once). A server whose pictures cost much to draw is shown more slowly, and the others, and the rest of qKVM, go on: their pictures wait a few milliseconds at a time behind its own, some tens where a JPEG or a stream of a large screen is decoded in one go.

VNC support was typed from RFC 6143 and from TightVNC's description of its encoding, and tried against a stand-in server written for the purpose, which speaks every version, both ways of signing in and every encoding above, and misbehaves in the ways tested. A test against real servers (TigerVNC's Xvnc with a terminal in it, and QEMU's built-in server) is written for the automated tests on GitHub, where the two are installed for that job alone: it types into the terminal and reads back what arrived, asks the X server where the pointer went, and compares QEMU's screen with the screenshot QEMU takes of itself. It passed on Linux (Debian, and Ubuntu 24.04) and in the automated tests on GitHub. A libvirt guest's console was shown as a tile. RealVNC, TightVNC, x11vnc and a controller's own VNC server have not been tried: see Limits.

An iDRAC's own VNC server (iDRAC Enterprise, port 5901 where it is switched on in the iDRAC, with the VNC password set there) is a VNC server like any other: type vncs:// where its SSL encryption is on. That was built from Dell's documentation and has not been tried: whether that encryption is TLS from the first byte, as vncs:// speaks it, has not been seen.