From: Friedrich Weber <f.weber@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Aaron Lauterer <a.lauterer@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager v3] ui: vm console: autodetect novnc or xtermjs
Date: Mon, 24 Mar 2025 17:57:54 +0100 [thread overview]
Message-ID: <c08a86ff-f1a8-4a27-bfa0-e6a940eb0cae@proxmox.com> (raw)
In-Reply-To: <20250225154706.1108094-1-a.lauterer@proxmox.com>
On 25/02/2025 16:47, Aaron Lauterer wrote:
> 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.
I agree that defaulting to xterm.js in the serial terminal case makes
for a better user experience.
Tested this with a VM with a serial port booting from the PVE ISO,
didn't notice any big issues. See below for some minor comments.
> 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.
>
> Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
> ---
> Another thing that I noticed is that the property we use to decide if we
> enable xtermjs for VMs in the top right console button only checks if
> the VM has a serial device configured.
> PVE::QemuServer::vmstatus() calls `conf_has_serial()`.
>
> A better approach would be to have a vmstatus property that actually
> tells us if the VM has serial set as display option. As the display
> could be set to something else, even if a serial device exists. There
> are other use-cases for a serial device in the VM, like passing through
> an actual serial port.
> But I did not want to introduce another new property for vmstatus() and
> changing the meaning of the current serial property would be a breaking
> change.
> Therefore, this current UI only implementation.
>
> changes since:
> v2:
> * change approach and do it in the UI alone by fetching the VM
> config before deciding which console to use
>
> v1:
> * set 'autodetect' to always true in 'VNCConsole.js'
> * add additional checks in pveproxy
> * only if autodetect is enabled and console is set to 'kvm'
> * username exists and has VM.Console permissions for the guest
>
> www/manager6/VNCConsole.js | 61 +++++++++++++++++++++++++++-----------
> 1 file changed, 44 insertions(+), 17 deletions(-)
>
> diff --git a/www/manager6/VNCConsole.js b/www/manager6/VNCConsole.js
> index 9057e447..69ced0f8 100644
> --- a/www/manager6/VNCConsole.js
> +++ b/www/manager6/VNCConsole.js
> @@ -27,31 +27,58 @@ Ext.define('PVE.noVncConsole', {
> throw "no VM ID specified";
> }
>
> + let activated = false;
> + let configLoaded = false;
> // always use same iframe, to avoid running several noVnc clients
> // at same time (to avoid performance problems)
> var box = Ext.create('Ext.ux.IFrame', { itemid: "vncconsole" });
>
> - var type = me.xtermjs ? 'xtermjs' : 'novnc';
> + let loadConsole = function() {
> + if (!activated || !configLoaded) {
> + return;
> + }
I was wondering whether there might a race condition possible here
(i.e., the success callback of API2Request and the `activate` listener
called with unfortunate timing that would prevent the console from
appearing), but thinking about it more, it looks okay -- there is no
threading and both the callback and the listener should normally be
called eventually (in whatever order). We won't get a console if the
/config API request fails, but I guess in that case something is
currently wrong with the setup anyway.
> + let type = me.xtermjs ? 'xtermjs' : 'novnc';
> + let sp = Ext.state.Manager.getProvider();
> + if (Ext.isFunction(me.beforeLoad)) {
> + me.beforeLoad();
> + }
> + let queryDict = {
> + console: me.consoleType, // kvm, lxc, upgrade or shell
> + vmid: me.vmid,
> + node: me.nodename,
> + cmd: me.cmd,
> + 'cmd-opts': me.cmdOpts,
> + resize: sp.get('novnc-scaling', 'scale'),
> + };
> + queryDict[type] = 1;
> + PVE.Utils.cleanEmptyObjectKeys(queryDict);
> + var url = '/?' + Ext.Object.toQueryString(queryDict);
> + box.load(url);
> + };
> +
> + if (me.consoleType ==="kvm") {
nit: missing space after the ===
> + Proxmox.Utils.API2Request({
> + url: `/api2/extjs/nodes/${me.nodename}/qemu/${me.vmid}/config`,
Stumbled upon this by accident: I guess this could should pass
`current=1` to get the currently running config instead of the config
with pending changes applied (because the running config one is the
relevant one for deciding whether to use noVNC or xterm.js).
> + method: 'GET',
> + failure: response => Ext.Msg.alert('Error', response.htmlStatus),
> + success: function({ result }, options) {
> + if (result.data.vga?.startsWith("serial")) {
> + me.xtermjs = true;
> + }
> + configLoaded = true;
> + loadConsole();
> + },
> + });
> + } else { // don't need to load anything else
> + configLoaded = true;
> + }
> +
> Ext.apply(me, {
> items: box,
> listeners: {
> activate: function() {
> - let sp = Ext.state.Manager.getProvider();
> - if (Ext.isFunction(me.beforeLoad)) {
> - me.beforeLoad();
> - }
> - let queryDict = {
> - console: me.consoleType, // kvm, lxc, upgrade or shell
> - vmid: me.vmid,
> - node: me.nodename,
> - cmd: me.cmd,
> - 'cmd-opts': me.cmdOpts,
> - resize: sp.get('novnc-scaling', 'scale'),
> - };
> - queryDict[type] = 1;
> - PVE.Utils.cleanEmptyObjectKeys(queryDict);
> - var url = '/?' + Ext.Object.toQueryString(queryDict);
> - box.load(url);
> + activated = true;
> + loadConsole();
> },
> },
> });
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-03-24 16:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-25 15:47 Aaron Lauterer
2025-03-24 16:57 ` Friedrich Weber [this message]
2025-03-24 17:25 ` Aaron Lauterer
2025-03-25 8:10 ` Hannes Duerr
2025-03-25 9:20 ` Aaron Lauterer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c08a86ff-f1a8-4a27-bfa0-e6a940eb0cae@proxmox.com \
--to=f.weber@proxmox.com \
--cc=a.lauterer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal