Hello. Did you used cockpit's functionality of adding new host?

If so, then this issue is probably the same as the #64
Can you confirm that it's the same bug?

Hello I don't use this fonctionnality to add other host...

Is this the setup you use? https://evermeet.cx/wiki/Reverse_Proxy_setup_for_Cockpit_with_Apache_(in_a_sub_directory)

Anyway as a workaround, you could try to edit console address. You can achieve that with command
virsh edit [vm name]
Then find the element and changing the address there.

Please let me know if that helps

no i have followed this one :
https://github.com/cockpit-project/cockpit/wiki/Proxying-Cockpit-over-Apache-with-LetsEncrypt

i try with virsh this afternoon.

I'm able to reproduce. I do not use any exotic Cockpit / Cockpit-machines setting, see below:

I'm not sure whether this is expected, since Libivrt/QEMU is running on the local host. If running on a Linux Distro, with desktop environment, it will happily show you 127.0.0.1. Except that will work since you can use a graphic program (e.g. Spice Space) to connect to the machines over your loopback IP.

You should be able to connect via your Servers IP on port 5901 for Spice or 5900 for VNC. Note: you need to create an allow rule in the firewall. I think this actually can be replaced with the server IP. Alternatively it could also also be changed to something like: loopback / server_IP.

Imo this would make things a bit more clear for new(er) users :).

Hello, how can i proceed to do this with the firewall?

Hello, how can i proceed to do this with the firewall?

Depends on your distro. You could use iptables/nftables entries. On Rocky, CentOS, Fedora and derivatives I often find myself using:

sudo firewall-cmd --add-port=5900/tcp --permanent
sudo firewall-cmd --add-port=5901/tcp --permanent
sudo firewall-cmd --reload

This will add the ports to your default zone, which is most of the time the "public" zone.

I'm on ubuntu server and the default firewall ufw is disabled. Anyway me I use a physical firewall so I think I must enable the default one?

The loopback address is from VM's configuration. And since VM is located on the server, then from the VM's point of view the VNC server is located on localhost. But of course, when you download a .vv file through cockpit, you are spawning it on client and VNC server is located at your server IP, not localhost. But the reason why we used VM's IP address until now is that it's configurable, and user can specify a custom IP where VNC server is running.
So maybe Cockpit should do the following:

Check VNC IP address in VM'x configuration.
If IP address is different from localhost, use that IP address.
If IP address is the same as localhost, use server's IP address.

@Ludo-code do you think that would solve your problem?

yes thanks you :)

Hmm, so here I proposed a solution to allow VNC server to listen an all interfaces, not just loop back. But that may be a security issue, if user doesn't have some verifications (e.g. tls) setup, otherwise that leaves an open port with access to VM's VNC.'
So maybe a better solution is to allow a user to set up a port-forwarding to their localhost, so then a downloaded .vv file can just open VNC by connecting to a localhost port, which is then forwarded to a remote server where VM is locatd.

@Ludo-code in your example as shown in #1078 (comment), it would be an equivalent to running this on client:

ssh -L 5900:localhost:5900 -N -l remoteuser remoteserveraddress

Then downloading a .vv file and opening it should show a VNC console.
That should also work for you as a workaround until we fix it, does that work for you?

Related, a discussion about the VNC / SPICE config in Cockpit-machines:

• Ability to add/edit/remove consoles #553

(This is more for a redesign for the UI and how it would work.)

FYI there is a work around for this: See issue #73