Linux provides many protocols and implementations that allow remote access to the graphical interfaces of other computers. The networking capability of X Window, for example, is legendary and makes every Linux or Unix machine into a potential terminal server. It used to be enough for a remote desktop solution to transfer the GUI over the network, but users and admins today have much more sophisticated needs. Modern scenarios demand access to the hardware, and all data transfers between server and client must be secure. Increasingly, mobile users want to interrupt sessions and later resume them on a different computer.

Protocols and software, such as Microsoft’s Remote Desktop Protocol (RDP) or NoMachine’s NX master all these challenges without problems; however, when it comes to multimedia, they lag far behind the performance of a locally installed desktop.

Touchy Hardware

Happy is he whose local sound cards, printer, or USB flash drive work correctly over the network. However, when it comes to 3D, catchy transparent effects, or jerk-free playback of HD videos, the wheat is separated from the chaff.

Only two products promise success: Citrix is betting on their commercial product HDX (High-Definition User Experience), and Red Hat backs the SPICE protocol, server, and client. The Simple Protocol For Independent Computing Environments promises the cloud user direct access to the hardware components installed in the server, as well as transparent, performant “pass-through” to the client.

Once Upon a Time

According to the project website, SPICE “… aims to provide a complete open source solution for interaction with virtualized desktop devices.” SPICE was developed by Qumranet and, like so much from the Israeli software developer, it was not initially an open source product. Qumranet caused a stir in the Linux community with the development of KVM. Earlier work with KVM virtualization forced the company to confront problems such as performant video streaming and USB forwarding, and in 2007, they published the first version of SPICE.

Red Hat took over Qumranet in 2008 and prescribed the open source strategy that continues today. Meanwhile, the SPICE protocol is distributed under a BSD-style license, and most parts of the implementation fall under the GPL. Since 2010, the SPICE project has been a member of the Freedesktop.org project. Until a few years ago, users could only use the protocol for access to virtual guests, but an implementation for X server (Xspice) became available in 2010.

Brick by Brick

SPICE includes a potpourri of components that fall into four categories:

• protocol
• server
• client
• mediating components

Depending on the task, various intermediaries come into use – for example, virtual QXL graphic cards and VDI interfaces (Virtual Desktop/Device Interface). The interaction of the various components, with a focus on the virtual guests, is shown in Figure 1.

Figure 1: Interaction of the various SPICE components.

The application first communicates with the local graphic machine – for example, the X server. This sends the request to the QXL device with the help of the driver. From there, the SPICE server picks up the request, processes it, and sends it to the SPICE client . If the SPICE agents are involved, the guest operating system communicates via VDI port devices or drivers with the SPICE server.

Communication between the SPICE server and client is divided into channels that work in parallel, each responsible for a specific class of data. The main channel is a kind of management instance that creates, configures, controls, and closes the other channels. Table 1 shows the SPICE channels, their intended use, and which guest OS components are involved.

The SPICE protocol regulates communication between the server and the client. It defines types of messages for accessing, controlling, and receiving input from remote devices. It does not matter whether the device resides locally in the SPICE server or in the SPICE client. The channels shown in Table 1 are part of the SPICE protocol specifications.

The SPICE environment includes an authentication mechanism on the basis of tickets in the X.509 format with a 1024-bit RSA key. Current SPICE implementations also support SASL, the Simple Authentication and Security Layer, for secure access. The messages defined by the protocol are either of a general nature, specific to the server or client, or valid for a particular channel. Further details are found in the protocol specifications on the project website.

SPICE uses TLS (Transport Layer Security, RFC 2246) for data encryption; accordingly, the server needs its own certificate. Each X.509 certificate (RFC5280) must be signed by a root CA. For the SPICE server to be able to verify this signature, users must specify its path at startup – on the server as well as on the client.

In Practice

To implement SPICE, it is best to begin with the client. A spice-gtk client is already integrated in virt-viewer. The user only needs to change the display type in the preference dialog of virt-manager from VNC to SPICE. The developers have implemented the spice-gtk client as libraries to which the virt-viewer is linked. Because virt-manager is programmed in Python, it uses a corresponding module to control the spice-gtk client.

spicy and spicec (see Figure 2) are true standalone clients. As with a VNC client, the user specifies the details of the connection to the SPICE server at startup.

Figure 2: The client programs spicy (left) and spicec (right) are similar to common VNC clients.

The SPICE HTML5 client, however, is still quite new. In addition to HTML5, it also requires JavaScript and a WebSockets proxy; the developers promise to make remote desktops available in any browser sometime in the future.

The SPICE server is also implemented as a library. Since 2010, QEMU/KVM is linked to libspice-server.so and can therefore provide SPICE functionality. Although VNC is still the standard for accessing the graphical interface of a guest, switching to SPICE is quite simple. If you want to make the most of its functions, however, you will need to use a different virtual graphic card and switch to the QXL drivers. For command-line aficionados, this can be done with the KVM option -vga qxl. The corresponding setting in the virt-manager is, however, just a few clicks away in the hardware menu.

Seasoning for X11

The SPICE driver for the X server comes with a wrapper script called Xspice, written in Python. However, at the time of writing, the script could only be considered experimental at best: Network performance is worse than with VNC, and the synchronization of the cursor position has errors. The implementation of the SPICE server in QEMU/KVM is much more advanced and currently the most usable. It forms the basis for the ensuing descriptions and tests.

Display forwarding and security via SSL/TLS are not really outstanding features because ancestors of Remote Desktop, such as X and VNC, could already do that. Other features, however, make SPICE really interesting. The first would be its audio support. Although QEMU (in conjunction with VNC) already had an add-on that allowed sound transfer, unfortunately, hardly any VNC clients supported it. SPICE, on the other hand, is already well prepared for this task and includes a functioning implementation for server and client.

With a little preparation, the user can play an audio file in the KVM guest and listen to it on the SPICE client. For this to happen, the corresponding functions must first be turned on in QEMU/KVM on the server. The qemu -audio-help command reveals a wide range of configuration options, but in the simplest case, it is enough to set the QEMU_AUDIO_DRV variable to the desired audio back end (see Table 2).

This is not quite enough, however, because the client must also have a virtual sound card. The models AC97 and ICH6 have proven useful, but in the test for this article, an emulated Creative Soundblaster16 and ENSONIQ AudioPCI ES1370 also worked. On the SPICE client side, it does not matter whether you use virt-viewer, virt-manager, spicec, or spicy – in tests, all provided problem-free sound output.

USB Device Passthrough

Another zesty treat in SPICE is USB redirection, which allows the user to access a local USB device on the virtual guest (on the server). As with the audio channel, both the server and the client provide the necessary support. In the test for this article, this was only true in the case of spicy. QEMU/KVM supports USB 2.0 via a virtual EHCI controller (Enhanced Host Controller Interface).

For this to work, the user must first provide QEMU with a special configuration (see Listing 1) and prompt for it to be applied when starting the virtual instance (Listing 2).

Listing 1: ich9-ehci-uhci.cfg

01 # cat /etc/qemu/ich9-ehci-uhci.cfg
02 [device "ehci"]
03 driver = "ich9-usb-ehci1"
04 addr = "1d.7"
05 multifunction = "on"
06 
07 [device "uhci-1"]
08 driver = "ich9-usb-uhci1"
09 addr = "1d.0"
10 multifunction = "on"
11 masterbus = "ehci.0"
12 firstport = "0"
13 
14 [device "uhci-2"]
15 driver = "ich9-usb-uhci2"
16 addr = "1d.1"
17 multifunction = "on"
18 masterbus = "ehci.0"
19 firstport = "2"
20 
21 [device "uhci-3"]
22 driver = "ich9-usb-uhci3"
23 addr = "1d.2"
24 multifunction = "on"
25 masterbus = "ehci.0"
26 firstport = "4"
27 #
28 #

Listing 2: Qemu/KVM Start

qemu -readconfig /etc/qemu/ich9-ehci-uhci.cfg \
-chardev spicevmc,name=usbredir,id=usbredirchardev1 \
-device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=0

With the -readconfig /etc/qemu/ich9-ehci-uhci.cfg argument, the admin turns on support for USB 2.0. The associated USB ports are set by the -chardev and -device QEMU options. This completes the groundwork necessary for the SPICE server, and the user can start the virtual guest. The SPICE client spicy now offers a menu for selecting the devices to be forwarded (see Figure 3).

Figure 3: spicy allows the user to choose the USB device to be forwarded.

Subsequently, the device is available in the guest as local hardware would be. If the network has a USB-over-IP server, it is also accessible for the user. In that case, the USB device is not integrated into the server via SPICE, but by USB encapsulation in TCP.

It is best to simply place all the sometimes numerous QEMU parameters in a single XML configuration file on the guest – with the qemu:commandline instruction.

Time to Save

It is a real challenge to achieve performant transmission of modern graphical interfaces with all their eye-candy and large video streams over narrow bandwidths. Like NX, SPICE relies on a local cache and seeks to avoid any unnecessary traffic. It stores images, color palettes, and cursor information in the cache. But when it can’t get around transferring an image, SPICE puts various compression methods to use: QUIC (based on SFALIC, Simple Fast and Adaptive Lossless Image Compression), LZ (Lempel-Ziv), or GLZ (generalized Lempel-Ziv). For video streaming, M-JPEG (Motion JPEG) is employed. You can configure both the compression algorithm and video stream recognition with QEMU options.

Prospects

Even if not everything works, SPICE would seem to have an interesting future. For one thing, more and more clients are being developed – not just for Windows and Linux, but also Mac OS X, Android, and N900. Even hardware manufacturers, such as the thin client specialist IGEL, are joining in. Visitors at CeBIT experienced the current state of the SPICE development, noting an enormous difference in performance between the Windows and the Linux client. HD videos were rendered jerkily on the Linux client, but not on the Windows machines.

Red Hat has integrated missing features into existing clients and is working on completely new functions. Among these new features are support of 3D graphics and access to local directories of the client machine. The functions available in the area of virtualization are already quite usable, and, particularly on Linux-based guests, it is well worth the move to SPICE. But Xspice must be significantly improved before SPICE can become a real alternative to VNC, RDP, and NX.