[SOLVED] SPICE doesn't work

[merlin-vrn]

A guest is Gentoo, which shows no apparent problems. The `spice-vdagent` is running (`qemu-agent` is running too and the host displays guest IP in the web interface)

The host is Proxmox VE 8.1 (pve-manager/8.1.10/4b06efb5db453f29)

According to the wiki page https://pve.proxmox.com/wiki/SPICE I tried to troubleshoot using a script. The script prints "AUTH OK" (which corresponds to the first call to the curl) and then fails with an error where the second call to curl is made:

curl -f -s -S -k -b "PVEAuthCookie=..." -H "CSRFPreventionToken:..." "https://node-ip:8006/api2/spiceconfig/nodes/192/qemu/105/spiceproxy" -d "proxy=node-ip" > spiceproxy

curl: (22) The requested URL returned error: 595 Connection timed out

Nothing appears in the guest logs when this happens. I verified that I have access to node-ip:3128 (telnet connection succeeded, and there is some kind of a HTTP server apparently). There is no firewall enabled.

How do I debug this issue?

 

[merlin-vrn]

Solved. That was not obvious. This forum thread has the answer: https://forum.proxmox.com/threads/scripted-spice-access-gives-595-invalid-argument.37078/

I need to specify *node name*, IP address isn't going to work. That needs to be worded better.

 

[gfngfn256]

I verified that I have access to node-ip:3128

If your trying to connect by SPICE to your VM guest the node-ip your refer to here, should actually be the guestVM-ip.

Can you ping the guestVM-ip from your client.

 

[merlin-vrn]

No, you're actually wrong. I needed to specify the node name, not the node IP. If I don't have it in DNS or hosts, I need to run it like this:

./spice.sh -u USERNAME -p PASSWORD VM_ID NODE_NAME NODE_IP

This is solved, but it still doesn't work from the web interface. So I still expect suggestions. The OS on my (client) desktop is Debian Bullseye (11), browser is Firefox.

 

[gfngfn256]

No, you're actually wrong. I needed to specify the node name, not the node IP

I'm sorry for the misunderstanding, I understood the context of your check to see port availability for SPICE connection directly to the VM, & in that case you want to check the actual VM IP.
This will also help in diagnosing your main problem of connecting to the VM by spice directly, which is what the GUI does. Your script is using the actual host via API to connect.
So back to my suggestion, can you ping the guestVM-ip from your client machine. What ports are available from guestVM-ip:xxxx to your client machine.

 

[merlin-vrn]

Requiring the ability to connect directly to a client defeats the purpose of having a hypervisor console, doesn't it? What if OS on the client isn't booting, or networking is failed and the purpose of the console is to fix that?

The network is set up in such a way I can't ping a client directly. It is impossible to do, since the client has private IP, and I connect to PVE over WAN using public IP. The client can be conveniently accessed via SSH, but for that there is a gateway, and I have a special ProxyJump setting in my local .ssh/config for the client.

And, more importantly when I run SPICE console through the script with the "correct" command line it works; I successfully tested clipboard sharing and USB passthrough. From that I deduce that there is no need to have a direct connection to a client for even advanced features to work.

 

[gfngfn256]

Requiring the ability to connect directly to a client defeats the purpose of having a hypervisor console, doesn't it? What if OS on the client isn't booting, or networking is failed and the purpose of the console is to fix that?

The network is set up in such a way I can't ping a client directly. It is impossible to do, since the client has private IP, and I connect to PVE over WAN using public IP. The client can be conveniently accessed via SSH, but for that there is a gateway, and I have a special ProxyJump setting in my local .ssh/config for the client.

And, more importantly when I run SPICE console through the script with the "correct" command line it works; I successfully tested clipboard sharing and USB passthrough. From that I deduce that there is no need to have a direct connection to a client for even advanced features to work.

AFAIK (from my experience) you can still access the Console in the PVE GUI (VMleft-pane, then Console next-pane) even with a SPICE enabled VM. You just won't have the SPICE experience. Again this is the Console connecting through the PVE itself - similar to your script through API - although your script appears to manage SPICE features.

When you try to connect to the VM directly with SPICE (example: pressing the Console dropdown in the GUI right-hand top) - you will need to have the ability to directly access your guest VM from the client you are using.

I believe my comment correctly negates any of your arguments.

 

[merlin-vrn]

Sure, you may stay on your opinion. The end fact is: SPICE fully works through script and without direct access to the VM, and it doesn't work in the GUI. How to solve that?

 

[gfngfn256]

So if I understand your situation correctly:

1. You do have access to the guest VM via the console within the GUI VM shell/console. (Non spice).
2. You can connect via the script to the guest VM from the client. (Spice).
3. You wish to connect via GUI to the guest VM without the script. (Spice).

Since you have isolated/firewalled the client from the guest VM this is not possible. Similar to your SSH situation, which without the gateway & ProxyJump, you cannot make a connection. Your "problem" is not limited to spice, but would apply equally if you were using another viewer such as VNC. There maybe a way of setting up a proxy for this to enable spice in this manner. See here. Also found this on Remmina. I have never done this, but the operation I believe would be similar to what the script you have used is doing via API through PVE, which is basically acting like a proxy.

I don't know if any of this, will work "from within the GUI", but I'm not sure why you're so adamant on only having this from within the GUI. Many users request / search the opposite of your wishes; they want a way to use spice without having to manually log in to the GUI.

 

[merlin-vrn]

Yes, I actually love the possibility to run it without GUI. I am glad there is such a script. Nevertheless, at the same time, I need to understand what's happening there. When some part doesn't work it means something is not right? Did I misconfigure something? How could it be possible with a script and not possible with a GUI, which is supposed to download the same "connection profile" as the script does, and that profile is supposed to be opened by the same client program on the same computer? Why curl within the script is able to download the "connection profile" for remote-viewer, and the web interface isn't?

And, notice that there is a dedicated proxy for SPICE, which runs on the PVE node on the port 3128 (which is directly accessible), and it's called, who would think, "spiceproxy". I mean, this is what is it for, am I right? Indeed, when I do anything through SPICE, a traffic spike appears to/from node port 3128 (confirmed with tcpdump). When I am using VNC (via noVNC) the traffic spikes appear on the port 8006 and it is distributed by "pveproxy". (I actually set up noVNC before behind a reverse proxy, in a project not related to PVE, and know well how it works). So yes, there are proxies for all, they already present, I shouldn't have the need to setup anything else.

 

[gfngfn256]

When you, press the Console button/dropdown to connect to Spice, you get a download of a .vv file, which your local client-viewer then directly uses to connect. There are ways to manipulate that file, but this would have to be within the PVE system. Note: that the .vv file has a short expiry time.

 

[merlin-vrn]

Yes, and that must be the same (or, very similar) file that the curl in the script downloads into "spiceproxy" file (see the opening post of this thread). (That file contains whatever I called a "connection profile" in previous reply.) I run the browser developer tools on the PVE GUI to see that the URL for that file is the same as used by the script. I can't verify that file contents, since it has such a short lifetime.

 

[merlin-vrn]

It started working all of a sudden. There was a both a node reboot and a client reboot; maybe, MIME-data of the virt-client was updated during login or browser restart, so these "connection profile" files were finally associated with it, or something like this.