consoleproxy.cmd.port configuration is unused (legacy/no-op) #11615

problem

The global configuration parameter consoleproxy.cmd.port is defined in CloudStack but is never actually used by Console Proxy VMs.

During testing was observed:

Setting consoleproxy.cmd.port at global or zone scope updates the DB and appears in list configurations.

Management server logs record the value change (e.g., “consoleproxy.cmd.port value is updated from: 8001 to 8015”).

However, the value is not consumed anywhere:

No listener is created on the management server at that port.

No connection attempt from CPVM to the MS on that port.

CPVM startup args reference only agent channel (8250) and noVNC/websocket (8080/8443).

Console functionality is unaffected by changing the setting.

This makes the parameter misleading. It should either be wired into CPVM/MS communication (if intended) or deprecated/removed.

versions

ACS 4.21
KVM

The steps to reproduce the bug

1. Check global value:

cmk list configurations name=consoleproxy.cmd.port

→ shows default 8001.

2. Override to 8015:

cmk update configuration name=consoleproxy.cmd.port value=8015 
systemctl restart cloudstack-management
cmk list configurations name=consoleproxy.cmd.port

→ value = 8015.

3. Recreate CPVM in Zone2.

Inspect CPVM and MS:

In CPVM:

ss -tlnp | egrep '8015|8080|8443|8250'
ps aux | grep consoleproxy

→ CPVM connects back to MS on 8250, listens on 8080/8443, no mention of 8015.

On MS:

ss -tlnp | grep 8015
→ no process bound to 8015.

Actual Result

Parameter is settable and visible in config.

CPVM/MS do not bind, listen, or connect on the configured port.

Console access continues to work normally (via 8080/8443 and 8250).

What to do about it?

One of the following should happen:

• If still relevant: CPVM/MS should honor the configured consoleproxy.cmd.port.

• If obsolete: The parameter should be deprecated/removed to avoid confusion.