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".
List of reasons to use a cloud 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.
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.
Before I'd actually want to use this, we'd need to solve the following problems:
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: