Proxmox and virtual machines

A virtual machine on Proxmox VE is a tile of its own: its screen, whether it runs, and its power buttons, all through Proxmox's own API with an API token. Nothing is installed in the guest or on the Proxmox host.

The token. In Proxmox (Datacenter > Permissions):

A user for the wall, wall@pve say (realm Proxmox VE authentication server; it needs no password of its own).
A role with VM.Audit (to see the guests and whether they run), VM.Console (their screens and keys) and VM.PowerMgmt (the power buttons; leave it out for a wall that only looks).
A pool with the guests the wall is to show, and the role given on the pool (Permissions > Add, path /pool/<name>).
An API token for the user (API Tokens > Add). With Privilege Separation on, as it comes, the token has only what is given to the token itself: give it the role on the pool as well. Its secret is shown once.

Then choose Virtual machines on Proxmox VE in Add KVMs, type the host's address (192.168.1.5, its port after a colon where it is not 8006), the token's ID (wall@pve!wall) where the user name goes and its secret as the password. The virtual machines the token may see are listed with their number, name, node and whether they run; tick the ones to put on the wall. To add one at once, put its number after the address (192.168.1.5/100), or paste the address Proxmox's own page shows for it. The tile is named after the guest. Containers are not listed (see below).

What a guest's tile gives:

Whether it runs, is paused or is stopped, asked of Proxmox every five seconds (a question Proxmox writes down nowhere). A stopped guest is there, and dark, as a server that is off is.
Its screen, while it runs: on the tile, enlarged, and on the live line, where Control sends its keys and the pointer. Send keys, Type text and the saved actions that press keys work as for a KVM; typed text goes as each character's keysym, as to a VNC server, and the guest's own keyboard layout decides.
The power buttons: Power on (Proxmox's start), Shut down (its shutdown: the guest is asked, through ACPI or its agent), Hold power button (its stop: the plug pulled), Press reset button (its reset). What is so already is left as it is and says so, as for a server, and switching on and stopping are waited for until they are seen: while Proxmox's task for the command runs, or its high availability carries the command out, up to a minute, and then the button says that it is still under way (it may yet be done), not that it failed; a task that ends in an error is said at once, in Proxmox's words. A guest with nothing in it that hears a request to shut down goes on running; the tile shows it, and Hold power button stops it.
Open console leads to the guest's console on Proxmox's own page (signed in there, as yourself).

The screen, and what it costs Proxmox. Proxmox has no picture of a guest to hand out. The screen is in the console Proxmox's own page opens: qKVM asks for a ticket (vncproxy), opens the WebSocket that ticket is for (vncwebsocket) and reads the protocol of VNC over it, with the password that came with the ticket. What was measured on Proxmox VE 9.2, and what qKVM does about it:

Every console opened is a task in the node's task log, which its owner reads. So qKVM holds one console per guest while somebody looks at its tile, and lets go of it five minutes after nobody does; it opens another only where one ended. A stopped guest is asked for none. A console that fails is asked for again after 15 seconds, then after a minute, 5, 15 and 30 minutes. What a tile costs in tasks: none while nobody looks at it; one each time somebody begins to look after five minutes or more without; a tile on a screen that shows the wall all day, one a day, and one more each time the guest is started or qKVM restarted. A console held for four hours was not ended by Proxmox.
Each console held costs the host two processes and about 120 MB of its memory, and little processor time: twenty guests' consoles held at once, each looked at once a second, took 2.4 GB of the host's memory and under a third of one of its cores (Alpine Linux at its login prompt, a blinking cursor). Holding a console instead of opening one for every picture is what keeps the task log readable; letting go of it five minutes after the last look is what keeps that memory free for the guests while nobody looks.
The first picture comes about a second after a tile is first looked at. Nineteen asked for at once came within 7.2 seconds, half of them within 6.2: Proxmox starts each console's processes as it is asked.
On the wall's side a guest whose tile is looked at costs what a server's screen does: about 5 % of one core of the computer qKVM runs on, most of it making a JPEG of its screen once a second.
The ticket is used at once, and once: Proxmox waits ten seconds for its one connection, and gives no answer at all to a second use, so qKVM gives up on an upgrade that is not answered within eight seconds. The password that comes with it expires half a minute after the connection. Neither is written down or logged, and neither is kept beyond the connection it opened.
A console that fails (a guest that gives a picture and ends, a console that lets qKVM in and answers nothing, a moment of Proxmox's own such as an answer of HTTP 500) is not opened again at every picture, key or move of the pointer: a live viewer waits out the same pause as the tile, and after three failures in a row the live line ends and the tile says why there is no screen. A console Proxmox will not open (403), or that turns qKVM away, is left alone as a refusal, and a live line ends at once. A console that served for a while and ended (Proxmox ended it) is opened again at once; the next one that ends before it has served four minutes is one more failure, on the same ladder (a proxy in front that cuts every connection after a minute costs a console every half hour, not every minute). A console that serves a while and then hangs, or sends what qKVM does not take, climbs the same ladder, and so does one that lets qKVM in and sends that at once. A console that ended because Proxmox started the guest again (its uptime began again just after) is no failure, once a minute at most, and an hour after the last failure what failed before is forgotten. A guest a Proxmox reports stopped, and then running, by turns has a console opened for it at most once every five minutes beside its own ladder, where a guest truly stopped and started again has one opened at once: a Proxmox that lies about it that way costs its own task log a console every five minutes, no more. A still screen is asked for one dot every 25 seconds, so that a proxy in front of Proxmox does not take its quiet console for a dead one. How it was paced outlives the wall locking itself and being opened again; saving the tile again, or typing its token again, starts afresh.
The token goes in the Authorization header of every request and of the console's upgrade, to the Proxmox it was saved for and nowhere else; never into an address, never into the log. Where Proxmox, or a proxy before it, says it back in an error, it is cut out of those words before they go to the log or the tile; said back in another spelling (split, without its dashes, encoded), none of those words are kept, and the tile says that Proxmox's words held the token.

A few things are worth knowing:

The token decides what works. Without VM.Console there is no screen, and the tile says so in Proxmox's words; without VM.PowerMgmt the power buttons answer what Proxmox says. A token without Pool.Audit cannot list pools, and need not: the guests it may see are listed all the same.
A wrong token is left alone, as every password is (a minute, five, a quarter of an hour, then hourly), and for every guest of that Proxmox together. Proxmox holds back each answer to a wrong one for three seconds.
A guest moved to another node of its cluster is followed, without anything to do, once the virtual machine with its number there is found to be the guest itself (below).
Its certificate is remembered on first contact, as for every device: the node's own. Every guest of one Proxmox shows the same, so a guest is known by the number it gives for itself (its SMBIOS UUID, which a clone is given anew): one guest added under two addresses of its Proxmox is noticed, two guests are two.
The guest it was added for, and no other. Proxmox gives a new virtual machine the lowest number that is free, so a guest that is deleted, and another made after it (on its node or on another), leaves its number to the new one. qKVM remembers the SMBIOS UUID the guest gives when it is added, and keeps it in an export file. It asks for it again before every power button, before each console it opens (the screen, and the keys and text that go through it), and before it follows the guest to another node; a look asks once a minute, and at once where it finds the guest stopped where it ran, running where it was stopped, or started again. Where another virtual machine has the number, or one that gives no UUID, nothing is done to it (no power button, no key, no console), and the tile says so from the moment that is seen until the guest has its number again. If it is the guest the tile is for now, edit the tile and type its token's secret. A tile with no UUID yet (taken from a file without one, or saved while its Proxmox could not be reached) takes the first one it sees, as a certificate is remembered on first contact. A guest whose settings carry no SMBIOS UUID (Proxmox gives every new one a UUID; it can be taken out by hand) is not told apart this way, and works as before.
The tile and the live line share one console, and so does somebody at Proxmox's own console page: the wall shares the guest's VNC server, and pushes nobody out of it.
Containers (LXC) are not shown: their console is a terminal of Proxmox's own. The list says how many it left out.

libvirt, QEMU and Unraid guests are plain VNC servers: add them as VNC servers. Their port and password are in the guest's definition: for libvirt, virsh vncdisplay <guest> says the display (:0 is port 5900, :1 is 5901), and the <graphics type='vnc' ...> line of virsh dumpxml <guest> has its port, where it listens (listen, 127.0.0.1 as it comes: let it listen where the wall can reach it, or tunnel) and its password (passwd, which virsh dumpxml --security-info shows). Give the guest a fixed port (autoport='no'): one given out in turn may be another guest's after a restart. Unraid's virtual machines are libvirt guests: the XML view of a VM's settings has the same line, and its VNC Password is that passwd.

XCP-ng (and Citrix Hypervisor) is not on the wall: its consoles speak VNC's protocol behind an HTTP request of their own, with a session; that door is not built.