VNC support is disabled

As of today, (LXD snap auto-updated yesterday to 4.4/stable) I can no longer start an lxd VM with vnc access using the method described here: Running virtual machines with LXD 4.0

qemu-system-x86_64: -vnc :1: VNC support is disabled: exit status 1

Is there a switch I need to flip?

VNC support was dropped from the snap this week in favor of SPICE which we’ve had supported natively by LXD for a little while now.

We’ve had both supported in parallel in the snap for a month or so but as LXD never officially supported VNC, it felt like a good idea to drop VNC from the snap, safe ourselves some build time, space and reduce the attack surface some more.

In your case, remove the custom -vnc :1 from your config and if you need to attach to the graphical console, use lxc console NAME --type=vga instead.

I see. Is there a way to have spice listen on an IP socket instead of the default UNIX socket? Otherwise, I’d need to use ssh X forwarding for virt-viewer. I’m trying to get through the Windows installer.

It’s all sent over the LXD API for you, just remotely connect to your LXD server and it will all work.

lxc console athos:win10 --type=vga is what I do here from my laptop and I get a live SPICE session from that remote server

Ahh, I didn’t realize that. Nice!

I have both remote-viewer and spicy installed, but I keep getting the below error. Do I need to configure paths to these binaries?

LXD automatically uses either spicy or remote-viewer when present.
As neither could be found, the raw SPICE socket can be found at:

Also, I’m hoping I can beat the clock to the UEFI boot menu this way.

LXD does quite a bit of magic to have this part work with the snap.

If you’ve never used your local LXD, you need to have it start so that this logic can run, lxc list should do the trick.

If you do have your local LXD running already but installed spicy/remote-viewer after it started, then you may need to reload it with sudo systemctl reload snap.lxd.daemon

Alternatively, you can directly provide the path the command line gives you to your client of choice using spice+unix://<path> as the URI.

How can I connect to remote machines with SPICE? (From my Windows PC to the LXD node/public ip vps)

LXD automatically uses either spicy or remote-viewer when present.
As neither could be found, the raw SPICE socket can be found at:

remote-viewer exists on Windows at

I’ve not yet tested whether LXD will detect it and be able to run it, will give that a try now.

Cool, it doesn’t work here.

– update –
Tested with different SSH tools. I prefer Putty with the Remote Viewer, but it doesnt work (yet).

I got it working with remote-viewer with some changes to the LXD client.

With that in place, I can just:

  • choco install lxc
  • choco install virt-viewer
  • lxc console athos:win10 --type=vga

That should all work with LXD 4.5 when we release it but you should be able to grab a .exe build of LXD once my branch gets merged.

1 Like

Thank you @stgraber. I’ll wait for the next release. :+1: has Windows builds for the latest code we merged.

Hi all. Trying to get it working on macOS Mojave because previously I relied on VNC to remotely setup windows virtual machines on LXD.

I installed the LXD client on MacOS with Homebrew, and I can connect to the remote daemon and manage the virtual machines (I had to open port 8443 for LXD daemon). lxc list works.

When opening a graphical console on macOS, I get a warning that spicy or remote-viewer are not present and gives me the local socket URL.

$ lxc console wintest --type=vga
LXD automatically uses either spicy or remote-viewer when present.
As neither could be found, the raw SPICE socket can be found at:

Using that URL on the bundle of RemoteViewer displays an error of “Unable to connect to the graphic server spice+unix://…”

Is this error about not being able to connect to the remote LXD daemon? Is it because it cannot access the socket file? Or is it because it cannot find any kind of local graphic server on the macOS?


I unfortunately don’t have macOS around to test that behavior.
How did you get remote-viewer installed? Did you also use homebrew for it?

An that Unable to connection to the graphic server ... is coming from running remote-viewer?

If so, try: nc -U /Users/j/.config/lxc/sockets/171832498.spice (update path) to see if you can connect to the socket (to rule out a LXD issue).

Hi Stéphane

Yes, I used the Homebrew version. I got RemoteViewer from , where it says “A bundle is now available”, downloading version 0.5.7-1 of the application, which is called Virtual Machine Viewer.

Looking at the download directory it seems that it has not been updated since 2013 ( ).

I tried connecting with nc -U to the local socket file, and it seems it can connect OK, because when I canceled the nc command with CTRL+C or typed whatever text on the nc console and exitted, the “lxc console” command exitted and removed the socket.

So, I guess it can be a problem with the graphical client. What options do I have to connect from MacOS? I’ll try to contact the spice space developers as well.

Thanks!! seems to have some more recent instructions for homebrew which may get you one of the latest releases of remote-viewer.


Ok, so I can confirm the following setup works on MacOS Mojave to try to connect to a remote LXD on Ubuntu Focal Fossa (20.04). I’m just showing the commands from the MacOS.

  • LXC installed via Homebrew on MacOS
    $ brew install lxc
  • Opened port 8443 on LXD server
  • Configured remote access to the LXD server ( )
  • Checked that remote access works
    $ lxc remote add ...
    $ lxc list
  • Installed virt-viewer via Homebrew from the jeffreywildman repo ( )
    $ brew tap jeffreywildman/homebrew-virt-manager
    $ brew install virt-viewer

Now, although a previous lxc console command said “LXD automatically uses either spicy or remote-viewer when present.”, it works with the installed virt-viewer.

$ lxc console wintest --type=vga

Just make sure you remove any VNC or Spice parameters on the raw.qemu config from the virtual machine before launching the VM.


Excellent, great to know!

I’m hoping someone can move that package over to the main homebrew repository so you don’t need to jump through that hoop.