James Stanley

How to run a Cloud Desktop on any VPS, with SPICE

Thu 21 May 2020

SPICE is the graphical protocol used by QEMU since 2013. If you've started a VM with QEMU, including with virt-manager or Gnome Boxes, then chances are you have used SPICE. It seems to be the same concept as VNC but more efficient.

The SPICE website has the following diagram:

And you may immediately see the problem with trying to run SPICE on a VPS: The "Spice Server" component in that diagram does not run inside the VM, it runs as part of the virtualisation host, which means we don't have access to it. But we can run Xspice which is a "standalone server that is both an X server and a Spice server".

Why

List of reasons to use a cloud desktop:

  • more bandwidth than your local connection
  • more CPU and memory than your local machine
  • can't be stolen from your house/office
  • available everywhere in the world
  • totally isolated from your real desktop

Admittedly, for the kind of work I do, SSH solves all of those just as well or better, but it would still be cool to be able to spin up a powerful desktop session on-demand.

How

I basically followed this post on running Xspice in containers, but ran it on a DigitalOcean VM instead of a container.

Start your VPS (here I assume running Ubuntu) and install Xspice and the ubuntu-desktop package:

$ sudo apt install xserver-xspice ubuntu-desktop

Once that's done, start a screen session and run:

$ Xspice --password 123456 :0

and in another window of screen:

$ DISPLAY=:0 gnome-session

Then, from your local machine, run spicy (which you can get with sudo apt install spice-client-gtk on Ubuntu 20.04), connect to your VPS on port 5900, and type in the password you gave to Xspice. You should now be connected to an Ubuntu desktop running in the cloud!

If you like it and want to use it more, then you should probably follow the instructions in the Xspice in containers post about disabling the SPICE password, restrict it to localhost-only with iptables or firewalld, and connect to it with an SSH tunnel.

Why not

Before I'd actually want to use this, we'd need to solve the following problems:

  • It doesn't use the proper Ubuntu theme for some reason? It's kind of a mix between Ubuntu's Gnome and standard Gnome. I tried --session=ubuntu but it made no difference. Not sure what's missing.
  • There's no audio.
  • The screen does not automatically resize to match the viewer. You can manually resize it using the "Display Settings" panel, but only to some pre-defined sizes, so you end up with borders around the screen, or the screen stretched to fit your real screen.
  • Latency is too high for it to be a pleasant desktop experience.

I did try running FreeCAD in my VM and looking at some of the Autopatzer parts. The parts aren't that complicated, but they're about as complicated as anything I want to model in FreeCAD and it worked well, especially considering that the rendering was being done in software due to the absence of any kind of GPU. The latency was still annoying, but the frame rate was great.

It would be perfectly within the realms of feasibility to work out what Ubuntu does to make its theme look right, to stream audio over a separate channel, and to write a client that communicates the screen dimensions to the server. There is actually SPICE support to set screen size with spice-vdagent but it seems to be aimed more at virtio-based display devices, so I'm not sure whether we'd be able to use it with Xspice inside a VPS. But we could easily do it with our own protocol and xrandr.

Overall I think the latency is the unsolvable problem here. I think we just need about 1 order of magnitude improvement in network latency and then this would be perfectly usable. Given speed-of-light limits, this probably means we need data centres nearer people's homes.

If you like my blog, please consider subscribing to the RSS feed or the mailing list:

James Stanley - james@incoherency.co.uk | ricochet:it2j3z6t6ksumpzd | jesblogfnk2boep4.onion | [rss]