Gewürzmischung

Mit der Übernahme von Qumranet hat sich Red Hat nicht nur die Virtualisierungstechnik KVM ins Haus geholt, sondern auch das Protokoll SPICE, das ähnlich wie RDP oder VNC einen entfernten Desktop auf den lokalen PC beamt.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 10 Min.
Von
  • Udo Seidel
Inhaltsverzeichnis

Den Bildschirminhalt an einen anderen Rechner zu übertragen und dort anzuzeigen ist heutzutage kein Hexenwerk mehr. Jedes moderne Betriebssystem stellt eine Funktion dafür bereit, die sich oft sogar plattformübergreifend nutzen lässt. Mit zunehmender Verbreitung der Desktop-Virtualisierung gesellen sich jedoch weitere Aufgaben hinzu, etwa Audio-Übertragung in beide Richtungen oder der Anschluss lokaler Geräte wie USB-Sticks und optische Laufwerke. Obendrein soll die Umleitung in langsameren Netzen noch zufriedenstellend funktionieren, etwa im WLAN oder über DSL. SPICE (Simple Protocol for Independent Computing Environments) soll genau das leisten.

Seinen Ursprung hat das Protokoll bei der israelischen Firma Qumranet, die auch die Linux-Virtualisierungstechnik KVM (Kernel-based Virtual Machine) entwickelt hat und 2008 von Red Hat übernommen wurde. Das Unternehmen wollte ein Produkt für Desktop-Virtualisierung anbieten, fand jedoch kein Protokoll, das neben der Bild- auch die Tonübertragung gestattet. Letzteres ist notwendig, damit der Nutzer etwa ein Video abspielen kann. Folglich begannen die Entwickler, an einem eigenen Protokoll zu arbeiten – zunächst hinter verschlossenen Türen. Nach der Übernahme veröffentlichte Red Hat das Protokoll und den dazugehörigen Quellcode unter der GPL. Seit 2010 ist SPICE Teil des freedesktop.org-Projekts.

Auch wenn es die ausgeschriebene Form des Akronyms anders impliziert, ist SPICE mehr als nur ein Protokoll. Außer der Definition der auszutauschenden Nachrichten gehören Server, Client und vermittelnde Komponenten zu SPICE (siehe Abbildung 1). Server und Client kommunizieren über mehrere sogenannte Kanäle (Channels), die als separate TCP-Verbindungen realisiert sind. Jeder Kanal ist auf eine bestimmte Art von Daten spezialisiert – etwa Bild- und Audiodaten oder Nutzereingaben.

SPICE verwendet separate Übertragungskanäle für unterschiedliche Datentypen. Vermittler bereiten Anfragen der Anwendungen für den SPICE-Server auf (Abb. 1).

An beiden Enden der SPICE-Kommunikationskette befindet sich jeweils ein Betriebssystem. Der SPICE-Client sorgt auf der einen Seite für die Interaktion mit dem Benutzer beziehungsweise seinem Rechner. Am anderen Ende ist die Angelegenheit etwas komplizierter. Anwendungen interagieren meist mit den sogenannten vermittelnden SPICE-Komponenten. Letztere bereiten die Anfragen für den SPICE-Server auf (siehe Kasten „Vermittlung, bitte“). Die auszutauschenden Nachrichten landen in einer Warteschlange, wo sie der jeweilige Adressat abholt. Jedem Channel ist ein eigener Vermittler zugeordnet.

Vermittler in SPICE können hardware- oder softwarebasiert sein. Da SPICE hauptsächlich in der Virtualisierung zum Einsatz kommt, ist die Unterscheidung zwischen Software und Hardware jedoch nahezu gegenstandslos. Das Betriebssystem auf der Server-Seite nutzt beispielsweise eine virtuelle Grafikkarte QXL, die es nur als QEMU-Gerät gibt. Tabelle 1 führt die wichtigsten Kanäle und die zugehörigen Vermittler auf.

Die wichtigsten SPICE-Kanäle und -Vermittler

Welche Nachrichten Server und Client austauschen, legt das eigentliche Protokoll hinter SPICE fest. Es definiert unterschiedliche Nachrichtentypen für den Zugriff, die Steuerung und die Datenübertragung von und zu den Geräten. Ob ein Gerät am Server(-Rechner) oder am Client angeschlossen ist, spielt dabei keine Rolle. Zum Redaktionsschluss lag Version 2.2 der Protokolldefinition vor. Laut den Entwicklern können Client und Server zusammenarbeiten, wenn sie dieselbe Hauptversion verstehen.

Zu Beginn einer Sitzung teilt der Client über den Hauptkanal dem Server mit, welche Protokollversion er beherrscht und welche weiteren Kanäle er öffnen möchte. Der Server prüft die Anfrage und sendet eine Antwort zurück. Sind alle Parameter für den Server akzeptabel, ist damit die Verbindung hergestellt.

SPICE nutzt mehrere Sicherheitsmechanismen. Zum einen kann der Administrator ein Passwort vergeben. War der Erstkontakt erfolgreich, verschlüsselt der Client das vom Nutzer eingegebene Passwort und sendet es an den Server. Ist das Passwort falsch, gibt der Server eine Fehlermeldung zurück und beendet die Verbindung. Dabei kommt das asymmetrische RSA-Verschlüsselungsverfahren zum Einsatz. Den 1024 Bit langen öffentlichen Schlüssel schickt der Server in seiner ersten Antwort mit, den privaten – den Angreifer zum Entschlüsseln des Passworts benötigen würden – behält er für sich.

Neuere SPICE-Versionen können alternativ SASL (Simple Authentication and Security Layer) zum Authentifizieren des Nutzers verwenden. Die weitere Kommunikation zwischen Server und Client lässt sich kanalweise mit SSL (Secure Socket Layer) vor eventuellen Lauschern im Netz verbergen. In der Standardeinstellung lässt der Server dem Client die Wahl, ob er eine verschlüsselte Verbindung aufbaut und welche Kanäle er verschlüsselt.

Im Virtualisierungsumfeld gehört das Migrieren von VMs von einem Host zum anderen zu den Standardaufgaben. Damit dabei die SPICE-Verbindung nicht abreißt, sieht das Protokoll einen Satz von Nachrichten fürs Migrieren der Kanäle vor. Der Server initiiert den Prozess, indem er über den Hauptkanal eine Anweisung an den Client schickt, auf einen anderen Server zu wechseln – entweder sofort oder nach Erhalt einer letzten Nachricht auf dem ursprünglichen Kanal. Letzteres kommt zur Anwendung, wenn der alte SPICE-Server an den neuen Daten übertragen will – der Client darf quasi den Postboten spielen.

Zeigereingabegeräte – Mäuse, Touchpads oder Grafiktabletts – kann SPICE in zwei Betriebsarten betreiben. Im Client-Modus ist die lokale Maus das effektive Gerät: Bewegungen resultieren in einer absoluten Positionsänderung, die der Client an den Server überträgt. Je nach Konfiguration berechnet entweder der SPICE-Server oder eine vermittelnde Komponente die neue Position auf dem Server-Desktop. Im Server-Modus hingegen überträgt SPICE nur Delta-Informationen zum Server. Das erfordert eine ständige Synchronisierung der Mauspositionen zwischen Server und Client, die bei langsamen Netzen als sichtbare Verzögerung der Cursor-Bewegung unangenehm auffällt.

Bilder und Mausbewegungen übers Netz zu übertragen ist nichts Neues – das beherrschen X11, ICA (Citrix), NX oder VNC ebenfalls. Client-Authentifizierung und verschlüsselte Verbindungen sind ebenfalls kein Alleinstellungsmerkmal. Kommt aber Ton ins Spiel, trennt sich die Spreu schnell vom Weizen. SPICE verwendet zwei Kanäle: Beim Playback sendet der Server Audiodaten an den Client, der die Töne über die lokale Hardware hörbar macht. Im Aufnahmekanal (Record) fließen die Audiodaten vom Client zum Server. Ein typisches Szenario ist die Aufnahme über ein am Client angeschlossenes Mikrofon, wobei die Aufnahmesoftware auf dem Server läuft.

Für beide Kanäle definiert das Protokoll die Nachrichten START und STOP, die Beginn und Ende der Übertragung kennzeichnen. Mit MODE teilt der Sender mit, in welchem Format die Audiodaten in einer DATA-Nachricht vorliegen: als unkomprimiertes PCM (Puls-Code-Modulation) oder CELT-komprimiert (Constrained-Energy Lapped Transform). Letzteres haben die Entwickler vermutlich gewählt, weil der CELT-Codec einerseits nicht mit Patenten belastet ist und andererseits eine niedrige Latenz verspricht.

SPICE-taugliche QEMU-Audio-Backends

Vermittler für Audiodaten ist die Soundkarte beziehungsweise dort angeschlossene Geräte. Mit der Virtualisierung verschwimmen hier wieder die Grenzen zwischen Hard- und Software. Im PC-Emulator QEMU, der auch die Grundlage für KVM bildet, haben sich die in Tabelle 2 aufgeführten Backends bewährt, die sich durch Setzen der Environment-Variablen QEMU_AUDIO_DRV auswählen lassen. Als zugehörige virtuelle Soundkarte nimmt man am besten AC97 oder ICH6; der Autor konnte jedoch auch emulierte Creative Soundblaster16 und ENSONIQ AudioPCI ES1370 zur Mitarbeit bewegen.

Mehr Infos

Vermittlung, bitte

Das Gast-Betriebssystem interagiert nicht direkt mit dem SPICE-Server: Die Kommunikation läuft über sogenannte Vermittler. Vereinfacht kann man sich diese als virtuelle Hardwarekomponenten vorstellen, zum Beispiel eine Soundkarte oder Maus. Das Gast-OS verwaltet dieses Komponenten mithilfe der Betriebssystem-Treiber. Eine Sonderrolle spielt die Grafik – hier liefert SPICE eine spezielle „Hardware“, die QXL-Karte, und die zugehörigen Treiber aus. Der QXL-Treiber wandelt die X11-Kommandos in QXL-Anweisungen um und legt sie im Speicher der virtuellen Grafikkarte ab. Dort holt sie der SPICE-Server für die weitere Verarbeitung ab. Anweisungen vom SPICE-Server zum Gast-OS laufen den Weg in der umgekehrten Richtung.

Für bestimmte Aktionen wie die automatische Monitor-Konfiguration für die Vollbild-Darstellung benötigt SPICE Schützenhilfe vom Gastbetriebssystem. Hier kommen die sogenannten SPICE-Agenten zum Einsatz. Diese Softwaremodule laufen im Gast und führen Aktionen für den SPICE-Server aus. Manchmal kommuniziert sogar der SPICE-Client mit den Agenten, etwa beim Abgleich der Zwischenablagen von Gast- und Client-OS.

Ein Schmankerl ist die Fähigkeit von SPICE, USB-Geräte nicht-lokal zugänglich zu machen. Dazu erweiterten die Entwickler das ursprüngliche Protokoll – SPICE 1.x – um drei neue Kanäle: tunnel fürs Umleiten von Netzverbindungen, smartcard zum Anschließen von Smartcard-Lesern sowie usbredir für den Zugriff auf USB-Geräte am Client-Rechner. Genau genommen war Letzteres nicht unbedingt notwendig, da die Software zum Umleiten von USB übers Netz auch separat zu haben ist. Fedora etwa enthält die entsprechenden Pakete usbredir und usbredir-server.

Zu den Ansprüchen der Entwickler gehört eine performante Übertragung auch über Netze mit geringem Durchsatz. SPICE greift hier auf dieselben Methoden wie andere Software-Implementierungen zurück. So verwaltet der Client einen lokalen Cache für Bilder, Farbpaletten und Cursor-Images, was unnötige Übertragungen vermeidet. Fürs Senden von Bildern greift SPICE obendrein auf verschiedene Kompressionsverfahren zurück: das auf dem SFALIC-Algorithmus (Simple Fast and Adaptive Lossless Image Compression) basierende quic, Lempel-Ziv (lz) und generalisiertes Lempel-Ziv (glz). Bei Video-Datenströmen kommt Motion JPEG zum Einsatz.

Wer SPICE selbst ausprobieren möchte, dem bieten sich mehrere Möglichkeiten. Auf der Serverseite ist die Integration in QEMU/KVM am weitesten fortgeschritten. Der Hypervisor erhält – sofern das Programm entsprechend übersetzt ist – seine SPICE-Fähigkeit über die Bibliothek libspice-server. Per Kommandozeile oder sogar per Mausklick kann der Nutzer die SPICE-fähigen Geräte für Gäste aktivieren. Es empfiehlt sich allerdings, auf moderne Community-Distributionen wie Fedora zurückzugreifen, die neue Funktionen recht schnell einbauen.

Seit einiger Zeit gibt es außerdem den X11-Server Xspice, der mithilfe des Treibers spiceqxl_drv gleichzeitig als SPICE-Server agiert und den Zugriff auf den gewöhnlichen (sprich: nicht virtualisierten) Unix/Linux-Desktop erlaubt. Die Tests im iX-Labor zeigen allerdings, dass er im Gegensatz zu QEMU/KVM noch etwas Reifezeit benötigt.

Auf der Client-Seite kann der Unix/Linux-Anwender zwischen mehreren Umsetzungen wählen. Der spice-gtk-Client beruht auf zwei Bibliotheken. Das eigentliche Protokoll ist in die Bibliothek libspice-client-glib geflossen, den Widget-Anteil liefert libspice-client-gtk. Sie kommen zum Beispiel im Virtual Machine Viewer virt-viewer zum Einsatz. Darüber hinaus gibt es die Stand-alone-Clients spicy und spicec.

Mehr Infos

iX-TRACT

  • SPICE (Simple Protocol for Independent Computing Environments) entstand als Alternative zu RDP, VNC und ähnlichen Techniken.
  • Das Protokoll überträgt nicht nur Nutzereingaben und den Bildschirminhalt, sondern auch Audiodaten. Außerdem gestattet SPICE den Anschluss von USB-Geräten an entfernte Rechner.
  • Zum Einsatz kommt SPICE vor allem in der Desktop-Virtualisierung, namentlich in KVM/QEMU.

Ein anderer Ansatz ist der SPICE-HTML5-Client. Er nutzt JavaScript und läuft im Browser, kann jedoch keine direkte Verbindung zu einem SPICE-Server aufbauen – dafür ist ein zusätzlicher WebSocket-Proxy notwendig. Andererseits ist ein solcher plattformabhängiger Client zurzeit die einzige Option etwa für Tablet-Nutzer, denn die Entwicklung von Clients für iOS oder Android scheint nicht vorwärtszukommen.

Design und vorhandene Implementierungen von SPICE sind vielversprechend. Insbesondere die Weiterleitung von USB ist ein Plus. Der modulare Aufbau erlaubt nachträgliche Erweiterungen, was die Entwickler bereits unter Beweis gestellt haben. Verlässt man jedoch das Virtualisierungsumfeld, sieht es leider nicht mehr so rosig aus – hier kann und muss Xspice die Lücke schließen. Fehlende Clients für die wichtigen Desktop-Betriebssysteme und die mobilen Plattformen sind dem Erfolg ebenfalls nicht zuträglich.

leitet eine Unix/Linux-Sysadmin-Gruppe bei der Amadeus Data Processing GmbH in Erding.

Alle Links: www.ix.de/ix1212126 (mr)