© Krzysztof Slusarczyk, 123RF.com

Mit Spice, dem Simple Protocol for Independent Computing Environments, will Red Hat die Performance von Multimedia-Anwendungen auf Remote Desktops verbessern. Das Paket aus Terminalserver, Client und Protokoll ist zwar eigens für KVM entstanden, aber nicht mehr darauf beschränkt.

Virtuelle Desktop-Infrastrukturen haben ihre Tücken. Zwar gibt es gerade unter Linux zahlreiche Protokolle und Implementierungen, die es erlauben, auf die grafischen Oberflächen von entfernten Rechnern zuzugreifen [1]. Aber wo es früher bereits reichte, das GUI erfolgreich übers Netzwerk zu übertragen, sind Anwender und Admins heute deutlich anspruchsvoller und verlangen Features, die sie von lokaler Hardware gewohnt sind – und einiges mehr.

Gewachsene Ansprüche

Niedrige Bandbreiten sollten kein Problem sein, jeder Datenaustausch zwischen Server und Client muss abhörsicher sein – er könnte ja übers ungeschützte Internet stattfinden. Die zunehmend mobilen Anwender wollen Sitzungen unterbrechen und später von einem anderen Rechner aus wieder aufnehmen.

Doch auch das meistern Protokolle und Software wie Microsofts Remote Desktop Protokoll (RDP) oder Nomachines NX ohne Probleme. Selbst die Netzwerkfähigkeit von X-Window reicht, um aus jedem Linux- oder Unix-Rechner einen potenziellen Terminalserver zu machen – zumindest im schnellen LAN. Glücklich kann sich aber schätzen, wer lokale Soundkarten, Drucker oder USB-Sticks auch übers Netzwerk zur Verfügung hat. X2go schafft das noch durch eine intelligente Kombination von Fuse, SSH-FS und Pulse Audio.

Aber bei der Darstellung von 3-D-Effekten, schicken Transparenzeffekten, wie sie moderne Desktops bieten, oder beim ruckelfreien Abspielen von HD-Videos versagen alle klassischen Terminalserver-Tools. Erfolg versprechen hierbei nur noch zwei Verfahren: Citrix setzt auf sein kostenpflichtiges Produkt HDX (High-Definition User Experience, [2]), Red Hat auf das Spice-Protokoll sowie den passenden Server und Client [3] – und hat diese 2010 in weiten Teilen als freie Software verfügbar gemacht.

Das Simple Protocol for Independent Computing Environments verspricht dem Nutzer einer Cloud direkten Zugriff auf im Server verbaute Hardwarekomponenten und transparentes, performantes Durchreichen auf den Client.

Gewürze aus Israel

Spice ist eine Erfindung der Firma Qumranet und war zunächst wie so vieles aus der israelischen Softwareschmiede (siehe Red Hats Enterprise-Virtualisierung, [4]) kein Open-Source-Produkt, auch wenn Qumranet im Linux-Umfeld bereits mit seiner Implementierung von KVM (der Kernel-based Virtual Machine) für Aufsehen gesorgt hatte.

Die Spezialisierung auf virtuelle Desktoplösungen konfrontierte die Firma früh mit Problemen des performanten Videostreamings oder der USB-Weiterleitung. Schon 2007 veröffentlichte sie die erste Spice-Version. Ein Jahr später übernahm Red Hat Qumranet und verordnete die bis heute geltende Open-Source-Strategie. Das Spice-Protokoll untersteht einer BSD-artigen Lizenz, die meisten Teile der Implementierung unterliegen der GPL. Seit 2010 ist das Spice-Projekt auch Mitglied von Freedesktop.org [5].

Bis vor wenigen Jahren konnten Anwender das Protokoll nur für den Zugriff auf virtuelle KVM-Gäste nutzen, doch seit 2010 existiert auch eine Implementierung für den X-Server (Xspice, [6]). Hinter dem Sammelsurium Spice steckt eine ganze Reihe von Komponenten, die sich in vier Kategorien aufteilen:

• Protokoll
• Server
• Client
• Vermittelnde Komponenten

Je nach Aufgabe kommen unterschiedliche Vermittler zum Einsatz, beispielsweise virtuelle QXL-Grafikkarten [7] und/oder VDI-Agenten (Virtual Desktop/Device Interface, [8]).

Das Zusammenspiel der Komponenten mit den virtuellen Gästen zeigt Abbildung 1: Die Anwendung spricht zunächst mit der lokalen Grafikmaschine, beispielsweise dem X-Server. Dieser sendet die Anforderung mit Hilfe des entsprechenden Treibers zum QXL-Gerät. Von dort nimmt sie der Spice-Server auf, verarbeitet sie und schickt sie an den Spice-Client.

Sind die so genannten Spice-Agenten im Spiel, kommuniziert das Gast-Betriebssystem über VDI-Port-Geräte beziehungsweise -Treiber mit dem Spice-Server. Die Kommunikation zwischen Spice-Server und -Client ist in so genannte Kanäle aufgeteilt, die parallel arbeiten und von denen jeder für eine bestimmte Klasse von Daten zuständig ist. Der Hauptkanal ist dabei eine Art Verwaltungsinstanz, die andere Kanäle anlegt, konfiguriert, kontrolliert und wieder schließt. Tabelle  1 zeigt die Spice-Kanäle sowie ihren Verwendungszweck und welche Gast-OS-Komponenten bei ihnen eine Rolle spielen.

Das Spice-Protokoll regelt die Kommunikation zwischen Server und Client. Es definiert Nachrichtentypen für den Zugriff, die Steuerung und den Empfang von Eingaben nicht lokaler Geräten. Dabei spielt es keine Rolle, ob das Gerät lokal im Spice-Server oder im Spice-Client angeschlossen ist.

Nachrichtenkanäle

Die genannten Kanäle sind Teil der Spice-Protokollspezifikation. Dazu gehört auch ein Autorisierungsmechanismus auf Basis von Tickets im X.509-Format mit einem 1024-Bit-RSA-Schlüssel. Seit Kurzem unterstützen aktuelle Spice-Implementierungen auch Sasl, den Simple Authentication and Security Layer für geschützte Zugriffe.

Die vom Protokoll definierten Nachrichten sind entweder von allgemeiner Natur, Server- beziehungsweise Client-spezifisch oder für einen bestimmten Kanal gültig. Weitere Details nennt die Protokollspezifikation auf der Projektseite [3]. Zur Datenverschlüsselung nutzt Spice TLS (Transport Layer Security, RFC 2246), der Server braucht dementsprechend ein eigenes Zertifikat. Jedes X.509-Zertifikat (RFC 5280) muss von einer Root-CA signiert sein. Damit der Spice-Server diese Signatur verifizieren kann, gibt der Anwender ihren Pfad beim Starten an, ebenso auf dem Client.

Wer Spice implementieren will, beginnt am besten mit dem im Virtualisierungsmanager, genauer in dessen »virt-viewer« , integrierten GTK-Client [9]. Den haben die Entwickler in Form von Bibliotheken implementiert, gegen die »virt-viewer« gelinkt ist. Weil »virt-manager« in Python programmiert ist, dient ein entsprechendes Modul zum Ansteuern des Spice-GTK-Clients.

Der Anwender stellt einfach den Anzeigetyp im Einstellungsdialog des Virt-Managers von »VNC« auf »SPICE« um (Abbildung  2). Die folgende Frage nach eventuellen weiteren Kanälen gibt fortgeschrittenen Anwendern Gelegenheit, auf individuelle Konfigurationen Rücksicht zu nehmen, Einsteiger können sie getrost ignorieren.

Abbildung 1: Die verschiedenen Komponenten von Spice im Zusammenspiel.

Abbildung 2: Ein Python-Modul integriert den Spice-GTK-Client in den Virt-Manager, der dann automatisch den Virt-Viewer startet.

Auch der Spice-Server ist als Bibliothek implementiert. Seit 2010 ist Qemu-KVM gegen »libspice-server.so« gelinkt und stellt so die Spice-Funktionalität bereit. Zwar ist für den Zugriff auf die grafische Oberfläche des Gastes immer noch VNC der Standard, das Umschalten auf Spice ist aber recht einfach. Wer dessen Funktionen richtig nutzen will, muss allerdings auch eine andere virtuelle Grafikkarte verwenden und auf die QXL-Treiber umsteigen. Anhänger der Kommandozeile erledigen dies über die KVM-Option »-vga qxl« . Die entsprechende Einstellung im »virt-manager« ist jedoch auch nur wenige Mausklicks entfernt, sie findet sich im Hardwaremenü.

Standalone-Clients

Echte Standalone-Clients sind »spicy« und »spicec« (siehe Abbildung 3). Ähnlich wie bei gängigen VNC-Clients definiert der Anwender beim Start die Verbindungsdetails zum Server. Der Spice-HTML-5-Client [10] ist dagegen noch recht neu. Neben HTML 5 verlangt er auch Javascript und einen Websockets-Proxy [11], verspricht dann aber, irgendwann performante Remote Desktops in jeden Browser zu bringen.

Abbildung 3: Die Clientprogramme »spicy« (links) und »spicec« (rechts) funktionieren wie gängige VNC-Clients. Der Benutzer braucht nur die Adresse des Servers, einen Benutzernamen und das Passwort.

Der Spice-Treiber für den X-Server kommt mit einem in Python geschriebenen Wrapperskript namens Xspice. Allerdings ließ er sich bei Redaktionsschluss höchstens als experimentell bezeichnen: Die Netzwerkperformance war im Test schlechter als die von VNC, und Fehler bei der Synchronisation der Cursorposition waren an der Tagesordnung. Die Spice-Server-Implementierung in Qemu-KVM ist deutlich weiter fortgeschritten und derzeit am brauchbarsten. Sie dient als Grundlage für die weiteren Beschreibungen und Tests.

Displayumleitung und Absicherung durch SSL-TLS wären nicht wirklich herausstechende Merkmale, das konnten schon Remote-Desktop-Urahnen wie X oder VNC. Richtig interessant machen Spice Features wie die funktionierende Audio-Unterstützung. Zwar enthielt schon Qemu im Zusammenspiel mit VNC eine Erweiterung, die Sound übers Netzwerk übertrug. Dumm nur, dass es kaum VNC-Clients gab, die das beherrschten. Spice hingegen ist von vornherein auf diese Aufgabe vorbereitet und beinhaltet funktionierende Implementierungen für Server und Client.

Mit etwas Vorbereitung kann der Anwender eine Audiodatei auch im KVM-Gast abspielen und sie auf dem Spice-Client anhören. Dafür muss er zunächst auf dem Server die entsprechenden Funktionen in Qemu-KVM einschalten. Das Kommando »qemu -audio-help« zeigt eine Vielzahl an Konfigurationsmöglichkeiten, im einfachsten Fall genügt aber schon das Setzen der Variablen »QEMU_AUDIO_DRV« auf das gewünschte Audio-Backend (siehe Tabelle 2).

Das reicht aber nicht ganz, denn auch der Client muss über eine virtuelle Soundkarte verfügen. Hier haben sich die Modelle »AC97« und »ICH6« bewährt, im Test funktionierten auch emulierte »Creative Soundblaster16« und »ENSONIQ AudioPCI ES1370« . Auf Seiten des Spice-Clients ist es egal, ob »virt-viewer« , »virt-manager« oder »spicec« beziehungsweise »spicy« zum Einsatz kommen – alle spielten bei der Soundausgabe ohne Probleme mit.

USB-Geräte durchreichen

Ein weiteres würziges Schmankerl ist die USB-Weiterleitung (USB redirection) in Spice, die es einem Anwender erlaubt, ein lokales USB-Gerät im virtuellen Gast auf dem Server zu benutzen. Wie schon beim Audiokanal müssen sowohl Server als auch Client die notwendige Unterstützung mitbringen. Im Test war das lediglich bei »spicy« der Fall. Qemu-KVM unterstützt USB 2.0 über einen virtuellen EHCI-Kontroller (Enhanced Host Controller Interface). Damit das funktioniert, muss der Benutzer Qemu eine spezielle Konfigurationsdatei unterschieben (siehe Listing 1) und diese beim Start der virtuellen Instanz auslesen lassen (Listing  2).

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

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

Mit dem Argument »-readconfig /etc/qemu/ich9-ehci-uhci.cfg« schaltet der Admin die Unterstützung von USB 2.0 ein. Die zugehörigen USB-Ports erhält er durch die Qemu-Optionspaare »-chardev« und »-device« . Damit ist die Vorarbeit für den Spice-Server abgeschlossen, der Anwender kann jetzt den virtuellen Gast starten.

Der Spice-Client »spicy« bietet ein Menü zur Auswahl der weiterzuleitenden Geräte an (Abbildung 4). Anschließend ist das Gerät im Gast benutzbar, als wäre es lokale Hardware. Gibt es im Netzwerk einen USB-over-IP-Server [12], kann der Anwender auch auf diesen zugreifen. Dann gelangt das USB-Gerät aber nicht via Spice, sondern durch USB-Kapselung in TCP zum Server. Am besten landen die bisweilen zahlreichen Qemu-Parameter einfach in einer XML-Konfigurations-Datei des Gastes – mit der Anweisung »qemu:commandline« .

Abbildung 4: Der »spicy«-Client erlaubt dem Anwender die Auswahl des weiterzuleitenden USB-Geräts, hier taucht in einer Liste die lokale Webcam auf.

Eine echte Herausforderung ist es, moderne grafische Oberflächen mit all ihrem Eye Candy oder umfangreiche Videostreams auch über schmale Bandbreiten performant zu übertragen. Wie NX setzt Spice auf einen lokalen Cache und trachtet danach, jeden unnötigen Traffic zu vermeiden. Im Cache speichert es Bilder, Farbpaletten und Cursordaten.

Wenn es doch mal ein Bild übertragen muss, dann bedient sich Spice verschiedener Kompressionsverfahren: QUIC (basiert auf SFALIC, der Simple Fast and Adaptive Lossless Image Compression, [13] ), LZ (Lempel-Ziv) oder GLZ (generalisiertes Lempel-Ziv) [14]. Für Videoströme kommt M-Jpeg (Motion Jpeg) zum Einsatz. Sowohl Kompressionsalgorithmus als auch die Videostream-Erkennung lassen sich über Qemu-Optionen konfigurieren oder ganz abschalten.

Zukunftsmusik

Auch wenn noch nicht alles funktioniert, scheint Spice eine interessante Zukunft vor sich zu haben. Zum einen entstehen weitere Clients, neben Windows [15] und Linux zum Beispiel auch für Mac OS X [16], Android [17] oder auch Nokias Smartphone-Urahn N 900.

Aber auch Hardwarehersteller wie der Thin-Client-Spezialist IGEL [18] machen mit. Bei dem konnten sich Interessierte schon auf der Cebit 2012 von den Fortschritten der Spice-Entwicklung überzeugen, wobei der Performance-Unterschied zwischen dem Windows- und dem Linux-Client enorm war – leider zu Ungunsten von Linux: HD-Videos ruckelten auf dem Client mit freiem OS, nicht aber auf dem Windows-Maschinchen.

Nicht zuletzt Red Hat treibt die Spice-Verbesserung und die Integration fehlender Funktionen in existierenden Clients voran. Zu denen zählen die Unterstützung von 3-D-Grafik oder der Zugriff auf lokale Verzeichnisse des Clientrechners. Die verfügbaren Funktionen im Virtualisierungsumfeld sind jedoch schon heute recht brauchbar, insbesondere bei Linux-basierten Gästen lohnt sich der Umstieg auf Spice. Für eine echte Ablösung von VNC, RDP und NX muss Xspice allerdings noch deutlich zulegen.