Ways to solve SPICE “Unable connect to graphics server” Error

Introduction

When utilizing SPICE on a Proxmox VE machine, it may occur that SPICE isn’t too fond of connecting to the VM. For these cases this article may assist you in finding possible solution vectors.

Solution 1: Check Firewalls and Connectivity

One of course should try to find easy solutions first, before tying to identify more complex scenarios. So check basic connectivity through your firewall by listing the status via ufw status. Please adjust your firewall rules to allow SPICE traffic on port TCP/3128. Also, you could check the connectivity itself by establishing a direct Telnet session with your Proxmox SPICE Proxy via telnet <YOUR-SERVER-HOSTNAME/IP> 3128.

A successfully established Telnet session would result in such output:

debian@debian:~$ telnet <YOUR-SERVER-HOSTNAME/IP> 3128
Trying <YOUR-SERVER-HOSTNAME/IP>...
Connected to <YOUR-SERVER-HOSTNAME/IP>.
Escape character is '^]'.
Connection closed by foreign host.
debian@debian:~$

Restart your system and check if Proxmox is now able to establish valid SPICE sessions.

Solution 2: Check RTC Time and NTP on Host

If the connection itself is establishable, one has to look now at more advanced solutions. One of which might be to adjust the RTC time on the Proxmox host machine and to check if a NTP server is in use.

As the SPICE session issued trough Proxmox is only valid for a certain time, please make sure that the requesting client and the Proxmox host RTC times are not too much out of sync, to allow the session timeframe to match up.

It may occur that the Proxmox host doesn’t even have a NTP server to get the time from altogether. Please issue the timedatectl command to see from where your system gets its time from and what it thinks the time actually is. A “healthy” output would look like this:

               Local time: Sat 2022-08-13 11:50:50 CEST
           Universal time: Sat 2022-08-13 09:50:50 UTC
                 RTC time: Sat 2022-08-13 09:50:50
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

If your time doesn’t match up with reality and/or if the NTP service is not in use, you can rectify this situation as follows:

apt-get install systemd-timesyncd
nano /etc/systemd/timesyncd.conf

Edit the NTP config file and specify which NTP servers you’d like to use:

[Time]
NTP=ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

Finally apply your changes:

systemctl restart systemd-timesyncd
timedatectl set-local-rtc 0
timedatectl set-ntp yes

Restart your system and check if Proxmox is now able to establish valid SPICE sessions.

Solution 3: Check Certificates on Proxmox Host

If SPICE still is not working properly, do you remember if you changed the FQDN or hostname of your Proxmox server once? If yes, a further reason may be that Proxmox’ default certificates are still issued to the old hostname and the resulting name mismatch is preventing SPICE to work properly now. In the following, files where the old hostname still may hide are going to be updated.

Check (and adjust if necessary) if /etc/aliases and /etc/aliases.db carry the right hostname:

ls -al /etc/aliases*
cd /etc

cat aliases

mv aliases.db aliases_BACKUP.db
echo '' > aliases.db

service postfix restart
shutdown -r now

Check (and adjust if necessary) if /etc/postfix/main.cf carries the right hostname via nano /etc/postfix/main.cf.

Also please check if /etc/hostname and /etc/hosts have the latest hostname in them.

Check /etc/resolv.conf for correct values also.

Finally delete the old Proxmox’ certificates and recreate updated ones via pvecm updatecerts -f and restart your system afterwards:

rm -rf /etc/pve/pve-root-ca.pem
rm -rf /etc/pve/priv/pve-root-ca.key
rm -rf /etc/pve/nodes/<YOUR-PROXMOX-NODE-NAME>/pve-ssl.pem
rm -rf /etc/pve/nodes/<YOUR-PROXMOX-NODE-NAME>/pve-ssl.key

pvecm updatecerts -f
systemctl restart pveproxy

Restart your system and check if Proxmox is now able to establish valid SPICE sessions.

Solution 4: Check possible Reverse Proxies (nginx and pveproxy)

If you established a custom reverse proxy on the Proxmox host by yourself or by following along my tutorial, you have to take care of the SPICE forwarding on the Proxy also, as pveproxy now only accepts connections from localhost (meaning from the internal reverse proxy).

For this to work, please make sure that the libnginx-mod-stream module is installed on the Proxmox server, via the apt list --installed libnginx-mod-stream command. If libnginx-mod-stream is missing, install it via apt install libnginx-mod-stream.

Make sure that the module is indeed present by issuing ls /usr/lib/nginx/modules/ngx_stream_module.so and by checking if the module is also activated via cat /etc/nginx/modules-enabled/50-mod-stream.conf.

load_module modules/ngx_stream_module.so;

Continue to edit the /etc/nginx/nginx.conf config file as a redirection for the internal SPICE port 3128 has to be set up. Please insert the stream block in between the events and http block. In the following, the internal port 3128 is passed onto the external port 3200:

events {
    [...]
}
stream {
    server {
        listen 3200;
        proxy_pass 127.0.0.1:3128;
    }
}
http {
    [...]
}

Restart your system and check if Proxmox is now able to establish valid SPICE sessions. Bear in mind, that the .vv files coming from the Proxmox GUI have to be adjusted to reflect the new SPICE port of TCP/3200.