In the past I have used VNC, FreeNX and X2Go to provide a remote desktop into Ubuntu. With the introduction of Ubuntu 12.10 (Quantal Quetzal) things became complicated. The 2d version of Unity was discontinued. Because none of the technologies I had been using provided 3d rendering capabilities, I would have been forced to abandon Unity and fall back to a simpler renderer (e.g. Gnome 2).

I started experimenting with the Spice protocol as a way of accessing the virtual “monitor” of a KVM virtual machine. While this showed great promise and provided to the VM all that was required to render a full Unity 3d desktop it had some drawbacks:

  • It was laggy. I was (and still am) having issues with IO performance of the VM's host server which, if resolved, may solve this.
  • Mouse integration was a bit off.
    • It seemed that the position of the cursor would randomly move all the way to the left side of the screen. When this happens a few times within a few minutes while doing something mouse intensive like browsing the internet, it gets very frustrating very fast.
    • I couldn't get the scroll wheel to work. Again, browsing the internet and being very used to having the scroll wheel, not having it is frustrating.
  • My underlying goal of having a full featured Ubuntu “Terminal Server” analogue was dying.
    • Needing a full KVM VM for each connected user was going to use far too many resources to be practical.

The next step was installing an Xspice enabled X server into the KVM VM and seeing how it operated. This would allow the VM to spawn an X server instance for each user, allowing one VM to serve multiple users. This worked very well, solving several of the drwabacks mentioned above.

Can we do better though?

Now we come to the purpose of this article, running an Xspice X server in an LXC container. An LXC container is even less resource hungry then a KVM VM.


Xspice is a feature that has been added to the qxl video driver for X. Usually, the qxl driver is facilitating the X server running inside a KVM/Qemu VM rendering it's output onto the “monitor” of the VM. Then the KVM/Qemu process on the VM's host manages the connection between the qxl driver inside the VM with the client's Spice client. Xspice takes the KVM/Qemu step out of the equation by having the client connect to a Spice server that is directly connected to the qxl driver.

That explination sucks, I know.

Our first stumbling block is getting an Xspice enabled qxl driver. Long story short:

  • The Ubuntu provided qxl driver does not have Xspice enabled.
  • The Ubuntu provided qxl driver is either newer than or a modified version of the upstream (either Debian or Spice project) version.

After a lot of dead ends, I ended up taking the source of the Ubuntu provided qxl driver and modifying it's packaging:

  • Merge in parts of the Debian package (control file, etc) that generated an xserver-xspice package
  • Change the configure command to compile with Xspice support

Then I uploaded this new package to LaunchPad.

Spice Client

One of the problems I an still unable to overcome with this setup is that in some cases, a sudden disconnection of the Spice client causes the Xspice/X instance to crash. This happens every time you click the close button on the spicec window for example.

I haven't had the same issue with the spicy client however though I haven't done extensive testing yet. In an ideal world though, the client, regardless of how broken, shouldn't be able to crash the server.


Container provisioning

Obviously, we're going to need an LXC container. Provision one as described in: Linux Containers

Xspice installation

The Xspice installation is as simple as adding the PPA that contains the Xspice enabled qxl driver and then installing the xserver-xspice package.

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:9v-shaun-42/desktop
sudo apt-get install xserver-xspice xinput

I changed allowed_users=console to allowed_users=anybody before I realised I was doing something wrong. I'm not sure if this step is necessary.

Xspice test

Now we run a simple test to make sure Xspice is working:

export DISPLAY=:10
cd ~
cp /usr/share/doc/xserver-xspice/spiceqxl.xorg.conf.example .
sudo mv spiceqxl.xorg.conf.example spiceqxl.xorg.conf
sudo Xspice --port 5910 --disable-ticketing --tls-port 0 -noreset $DISPLAY

This grabs the example configuration file and than starts an Xspice X server on display 10 listening for Spice protocol connections on port 5910. We don't have a firewall installed yet so you should be able to point your Spice client at the container's IP using port 5910

spicy --host <container ip> -p 5910

You should end up with a Spice client window filled with black. That's good. We don't have a desktop environment installed to fill that black void yet.

Desktop environment installation

For my initial experiment, my goal is to get the standard Ubuntu Unity desktop enviroment installed and presented to clients. I might want to experiment with other desktop environments though so at this point I took a copy of my LXC container.

To install the familiar Ubuntu desktop environment with Unity, run:

sudo apt-get install ubuntu-desktop

This may take a while if it's going to fetch everything from the internet.

Disable NetworkManager

The ubuntu-desktop meta-package installed NetworkManager but it's going to get in our way and will serve no useful purpose in our environment so we will disable it:

echo "manual" | sudo tee /etc/init/network-manager.override
sudo stop network-manager
sudo /etc/init.d/networking restart

Session Startup Script

This part is still a work in progress.

I have put together a script that will find the next available DISPLAY number, start an Xspice X Server on it and then start Unity, etc. This script still has some flaws:

  • I don't use the normal X startup mechanism to start the window manager, honestly, I couldn't work out how. Instead I start a few key processes (unity, gnome-session and dbus-launch). I'm sure this could be done better.
    • I would also like to allow different users to have different desktop environments (e.g. Gnome 3 or KDE).
  • I have a sleep command that waits for 10 seconds. This should be replaced with something that detects when the process is done and continues whether it is 2 seconds or 30 seconds.
  • I don't detect failures of the Xspice startup or the other processes yet.
  • I start at DISPLAY 10 and TCP Port 5910 and make no effort to ensure the TCP Port isn't in use.
  • I would like to have a user reconnect to an existing session, if one exists, rather than start a new one.
  • I would also like to start x11vnc on the started X server to allow low bandwidth connections.

Here's the script:

Drop it in /usr/local/bin, make it executable and, for neatness, create a link with a nice name:

cd /usr/local/bin
chmod +x
sudo ln -s start-xspice-session

Init Script

I haven't yet written an init script but it should do something like:

  • Start
    • Create the /var/run/xspice directory and set permissions
    • Delete everything from the /var/run/xspice directory if it already existed
    • Start sessions for some/all users?
      • All members of a certain group?
  • Stop
    • Gracefully logout of all running sessions?
    • Forcefully kill any remaining sessions (without relying on what is in /var/run/xspice just incase it's incomplete)
    • Delete everything from the /var/run/xspice directory

Client Script

The Session Startup script, when passed an -o argument, returns the TCP port that the client should connect on. This isn't always going to be the same. I would like to create a wrapper script that connects to the server with SSH, runs the script to start the session and then feeds the returned port number to a spicy command line. This script could be expanded to also set the initial screen/window size.

Client Security

The Xspice sessions are not secured. Once started as a user, any Spice client can connect to that TCP port and connect to that user's session. We could integrate using SSH to provide the security (Login, start session, tunnel TCP traffic). Otherwise, we need to work out how to use the “ticketing” mechanism.

The Xspice TCP channel itself can be secured with TLS but I haven't implemented this yet.

brian mullan, 2017/08/21 15:34


I am not commenting on this blog post but on “Running Linux GUI (X) Apps in LXC/LXD containers” … however I could not see how to leave a comment on that writeup.

In the section: Changes to host's pulseaudio service

You point the reader to: /etc/pulse/default.conf

and tell them to…

Fine the commented out line:

; enable-shm = yes

The file that they need to edit is actually /etc/pulse/client.conf not /etc/pulse/default.conf

Also, since you have some other sections of that writeup still marked as TODO… you might get some idea's from Simos's writeup at:

I'd like to see your blog post whenever you find time to complete the missing sections.



herbal, 2018/08/08 08:24

juliana168fdg, 2019/01/08 16:12

<a href=“”>Togel Toto Macau</a> <a href=“”>daftar game casino rollete</a> <a href=“”>Togel Toto Macau</a> <a href=“”>Togel Toto Macau</a> <a href=“”>Togel Toto Macau</a>

<a href=“”>deposit dadu poker</a> <a href=“”>dadu poker</a> <a href=“”>agen dadu poker</a> <a href=“”>login dadu poker</a> <a href=“”>cara menang main poker dadu online</a>

<a href=“”></a> <a href=“”></a> <a href=“”></a>

rukiya, 2019/01/11 15:39

Enter your comment. Wiki syntax is allowed: