[pve-devel] [PATCH manager v4] fix #1926 ui: vm console: autodetect novnc or xtermjs

[Thomas Lamprecht]

Am 25.03.25 um 10:18 schrieb Aaron Lauterer:
> Some users configure their VMs to use serial as their display. The big
> benefit is that in combination with the xtermjs remote console, copy &
> paste works a lot better than via novnc.
> 
> While the console button in the top right allows to manually choose the
> console type, the Console in the main submenu of a VM does not.
> 
> This patch changes the behavior for VMs and will first fetch the VM
> config and if the display is set to "serialX", will set the console to
> xtermjs. Otherwise it will fall back to regular noVNC.
> 
> Since getting the VM config is an async API call, the code had to be
> restructured so we can do the actual loading of the console after the
> config has been fetched.

> Therefore we now have the 'loadConsole()' function which will be called
> when the UI item is activated and in the KVM case, after loading and
> handling the VM config. It is guarded by the 'activated' and
> 'configLoaded' variables.

A bit late in, so sorry for that, but FWIW, one can also use our async API
request wrapper for that, i.e. mark the function this is in as async and
then use something like:

let config = await Proxmox.Async.api2({
    url: `/api2/extjs/nodes/${me.nodename}/qemu/${me.vmid}/config?current=1`
});

That would probably reduce the amount of changes required and also
keep the code a bit more linear.

Btw. don't we have the config available in some call-sites? I.e., would
it make sense to allow overriding it already now? Because if we can
reduce the need for an extra API call due to information being already
available then I'd always favor that, having experienced working over
some high latency links and/or spotty & congested (wifi) connections.

We can improve this later on, but would be good to evaluate the status
quo already; FWIW I'd be open to look into querying the respective
properties in the cluster resource API endpoint, which would then be
available in the in-memory resource store and really cheap to query
from the frontend. As we already get some properties the backend side
would not really get more expensive either. Again, that does not has
to be a prerequisite for applying something like this, but IMO worth
to evaluate at some (soonish) point.