Administratoren kennen das Problem: Für die alltägliche Arbeit ist es manchmal unerlässlich, sich den Desktop eines entfernten Systems lokal anzeigen zu lassen. Zwar ist gerade für die Admins von Linux-Systemen SSH zur Fernwartung üblicherweise das Werkzeug der Wahl, doch manchmal kommt es vor, dass die Kommandozeile allein für anstehende Aufgaben nicht ausreicht. Das ist beispielsweise der Fall, wenn ein Programm nur mit grafischer Konfigurationsmöglichkeit daherkommt, wie es bei Drittanbietersoftware regelmäßig der Fall ist. Kein Problem mit Werkzeugen wie RDP für Windows oder Apple Remote Desktop – und auch Linux braucht sich nicht zu verstecken, denn hier buhlen in Form von VNC und SPICE gleich zwei Implementierungen um die Gunst der Nutzer.

Geht es dann ins Detail, wird die Sache allerdings schnell zur Herausforderung. VNC ist den meisten Administratoren zwar ein Begriff, doch einen entsprechenden Server unter Linux hat hingegen längst noch nicht jeder Administrator eingerichtet. Denn oft kommt X11-Forwarding mit SSH stattdessen zum Einsatz. Das ist indes nicht besonders performant und funktioniert wegen des SSH-Unterbaus gerade bei instabilen Verbindungen nicht gut. Für einen Systemverwalter im Bereitschaftsdienst kann das problematisch werden, wenn die 4G/5G-Anbindung über das eigene Smartphone, die für normales SSH problemlos ausreicht, bei X11-Forwarding womöglich bereits die Segel streicht.

Welche Wege es zum reibungslosen Fernzugriff gibt, wollen wir daher im Folgenden für Windows, macOS, vor allem für Linux untersuchen, denn dort ist die Situation am unübersichtlichsten. Das Hauptaugenmerk liegt dabei auf der Vielseitigkeit der Anwendungen, ihrem technischen Fundament und dem jeweiligen Einsatzzweck.

Tatsächlich lässt sich das Thema "Desktop aus der Ferne" für Windows am einfachsten beschreiben, denn die Fronten sind hier geklärt: Microsoft selbst verbaut in Windows mittlerweile einen Server für RDP, das Remote Desktop Protocol. Dieses stammt ursprünglich von Citrix, kommt heute aber aus der Feder Microsofts und existiert server- wie clientseitig in proprietären und freien Implementationen.

Um RDP zu nutzen, genügt es, in einem Windows-System die passenden Einstellungen zu hinterlegen und vom Endgerät aus über einen entsprechenden Client auf das Zielsystem zuzugreifen. Etwaige Firewalls im Kommunikationspfad sind freilich so zu konfigurieren, dass sie die RDP-Daten auch durchlassen. Besonders praktisch: Microsoft stellt für Windows wie für macOS einen eigenen RDP-Client zur Verfügung, der sich kostenlos installieren lässt. Und auch für RDP unter Linux stehen einige freie Werkzeuge bereit. In Sachen Fernadministration eines Desktops ist unter Windows also alles soweit in Butter.

Das gilt übrigens auch für virtuelle Instanzen von Windows – unabhängig vom verwendeten Hypervisor. Auch hier ist eine gängige Methode, das in der VM ohnehin vorhandene RDP zu nutzen, um sich mit deren virtuellem Desktop zu verbinden. Im Einzelfall hängt es jedoch von der genutzten Virtualisierung ab, ob auch über diese noch ein Weg zur Verfügung steht. VirtualBox beispielsweise bietet selbst an, für eine Instanz auch eine VNC-Schnittstelle zu öffnen. In der Praxis gibt es dafür aber nur selten einen Grund, wenn RDP zur Verfügung steht.

Schon weniger rosig sieht die Situation für macOS aus. Denn zwar stellt auch Apple mit "Apple Remote Desktop" (ARD) ein eigenes Werkzeug für die grafische Fernadministration zur Verfügung, doch gehört der dafür benötigte Server nicht zum Lieferumfang des Betriebssystems. Um ihn zu nutzen, ist zwingend eine Shopping-Tour im App-Store von Apple erforderlich, die mit rund 90 Euro zu Buche schlägt.

Jedoch steht ARD nicht gerade im Verdacht, herausragend performant zu sein. Obendrein ist für Windows-Systeme gar kein ARD-Client verfügbar. Wer einen Mac-Rechner aus der Ferne administrieren möchte, greift deshalb idealerweise auf externe Alternativen zurück. Beispiele sind NoMachine oder GoToMyPC, das nicht wenige für die beste aktuell am Markt verfügbare Fernverwaltung für macOS halten. Auch hier zückt der Administrator seine Kreditkarte, wobei er mit 31 Euro pro Lizenz im Vergleich mit Apple noch eher günstig davonkommt.

Für virtuelle Instanzen mit macOS sieht die Sache ähnlich aus wie bei Windows – hier fällt allerdings wie beschrieben die Option weg, den im Betriebssystem genutzten Weg zu verwenden. VMs mit mac­OS sind insgesamt eher selten, zumal Apple dafür auch gar keine offizielle Unterstützung anbietet. In Form von VMware, Parallels oder VirtualBox stehen aber genügend Methoden zur Verfügung, um andere Betriebssysteme auf Basis von macOS zu virtualisieren. Hier hängt es wieder vom genutzten Hypervisor ab, welche Fernsteuerung möglich ist. VirtualBox erlaubt auch in macOS die Nutzung von VNC, dasselbe gilt für VMware Fusion und Parallels.

Über die eben beschriebenen Herausforderungen von macOS-Administratoren können ihre Linux-Kollegen nur lächeln. Dort stellt sich eine ungleich komplexere Situation dar: Einerseits geht das altehrwürdige VNC an den Start, von dem die allermeisten Administratoren sicher bereits gehört haben. In der anderen Ecke des Rings steht SPICE, ein Protokoll jüngeren Datums, das VNC nach einhelliger Community-Meinung in vielen Aspekten den Rang abläuft. Außen vor bleibt an dieser Stelle, dass auch für Serversysteme etliche Implementierungen proprietärer Protokolle für die Fernsteuerung von Desktops zur Verfügung stehen; erwähnt sei etwa wieder NoMachine, das einst seine Premiere auf Linux feierte.

Blicken wir zunächst auf VNC, das für "Virtual Network Computing" steht und ein echtes Schwergewicht im Markt der Desktop-Fernsteuerung ist. Das liegt einerseits an seinem Alter und andererseits daran, dass VNC mittlerweile fast schon ein Gattungsbegriff geworden ist, der Remote-Desktop-Lösungen samt und sonders umfasst. Wenn ein Administrator also davon spricht, sich per "VNC mit ei- nem System zu verbinden", dann bedeutet das nicht zwangsläufig, dass dabei tatsächlich auch das VNC-Protokoll selbst zum Einsatz kommt.

Noch weniger bekannt ist der Umstand, dass VNC selbst eigentlich nur die Implementierung des Standards "Remote Framebuffer Standards" ist. Um dessen Intention zu verstehen, muss klar sein, was ein "Framebuffer" ist – auch dieser Begriff ist vielen Administratoren trotz regelmäßiger Nutzung jedoch nicht geläufig. Die Erklärung findet sich tief im Maschinenraum praktisch jedes aktuellen Computers.

Framebuffer ist eine Kombination aus "Frame" für "Bild" und "Buffer" für einen Zwischenspeicher, der im Computer Daten für den schnelleren Zugriff bereithält. Ein Framebuffer ist also ein Zwischenspeicher, in dem die einzelnen Bilder der Grafikkarte lagern und er ist entsprechend Teil des Arbeitsspeichers der Grafikkarte.

Um den Framebuffer auszulesen und zu bearbeiten, müssen Betriebssysteme wie Linux keinen speziellen Treiber für die Grafikkarte verwenden. Denn Framebuffer sind nach VESA standardisiert. Der Zugriff auf sie erfolgt, wie der auf den regulären Arbeitsspeicher auch, über entsprechende Operationen des Betriebssystem-Kerns. Im Framebuffer liegt jedes Bild, das die GPU in letzter Zeit angezeigt hat. Zu beziehen ist es wie beschrieben über einfache Speicheroperationen. Genau hier setzt das Remote-Framebuffer-Protokoll an: Es leitet die im VRAM liegenden Bilder quasi aus und speist sie ins Netzwerk – Frame pro Frame.

VNC ist eine Implementierung des RFP-Standards (Remote Framebuffer Protocol). Insbesondere kümmert sich VNC darum, dass Features wie die Integration einer entfernten Tastatur oder Maus reibungslos funktionieren. Streng genommen ist es nämlich nicht der Desktop selbst, der bei einer VNC-Sitzung die Bewegungen von Maus und Tastatur interpretiert, sondern der VNC-Client. Der nimmt die Eingaben entgegen und leitet sie an den Server auf dem Zielsystem weiter, der sie entsprechend umsetzt. Die grafische Repräsentation – also der Mauszeiger auf dem Desktop, der sich bewegt – ist letztlich nur das Ergebnis.

Die Krux an der Sache ist nun, dass VNC selbst bereits einige Jahre auf dem Buckel hat. Als Olivetti Labs VNC Mitte der 80er-Jahre entwickelte, war von opulenten grafischen Oberflächen mit Effekten, die schnelle Grafikkarten bisweilen vor Herausforderungen stellen, noch nicht die Rede. Dasselbe gilt für 4K-Videos, die für VNC eine echtes Problem darstellen. Denn ein 4K-Bild im Framebuffer ist selbstredend viel größer als ein Frame eines Full-HD-Desktops oder der früher gebräuchlichen 1024x768 Pixel. Wenn mehr Daten im Framebuffer liegen, muss für die reibungslose und flüssige Nutzung von VNC allerdings auch mehr Inhalt durch die Leitung. Und das führt unweigerlich zur eingangs schon angestoßenen Diskussion zurück, wonach Remote-Desktop-Anwendungen bei dünner Leitung bisweilen nur eingeschränkt oder gar nicht funktionieren.

Natürlich haben RDP und VNC seit ihrer Entstehung immer wieder Updates erhalten und auch entsprechende Erweiterungen der Standards fanden statt. So bietet VNC heute eine eingebaute Komprimierung und Verschlüsselung. Das aber bedingt, dass ein Administrator seinen VNC-Server entsprechend aufsetzt. Weder ist allerdings allen IT-Profis klar, dass ein nicht konfiguriertes VNC üblicherweise sämtliche Daten im Klartext durch die Gegend funkt, noch wissen viele Systemverwalter um die positiven Wirkungen der Komprimierung im Kontext von VNC.

Wie sich ein VNC-Server unter Linux sinnvoll betreiben lässt, würde den Rahmen dieses Artikels sprengen. Wie üblich gilt, dass mehr als ein Weg zum Ziel führt, und für Linux existieren entsprechend etliche VNC-Server mit eigener Konfigurationssyntax. Dabei ist "x11vnc" ein klassischer Weg, die großen Desktops bringen in Form von Vino (GNOME) oder Krfb (KDE) jedoch eigene Implementierungen mit. Diese sind dann auch in den Konfigurationsdialog der Umgebung integriert – unter KDE lautet der passende Eintrag beispielsweise "Arbeitsfläche freigeben". Für Standard-Linux-Systeme lässt sich VNC so mit relativ wenig Aufwand an den Start bringen.

Komplexer ist die Situation, wenn es um virtuelle Instanzen geht, die auf einem Linux-System laufen. Hier hat das Hostsystem oft gar keine grafische Oberfläche, sodass ein Zugriff über dieses ohnehin als Option wegfällt. Die gängigste Virtualisierung für Linux, das Gespann aus KVM und Qemu, hat hierfür allerdings vorgesorgt. Das gilt zumindest dann, wenn "libvirt" für die Verwaltung zum Einsatz kommt. Denn durch eine entsprechende Konfigurationsanweisung in den Metadaten einer Instanz lässt sich aus libvirt heraus für jede laufende Instanz ein VNC-Server starten und so quasi natives VNC bieten. Wenn der Firewall-Zugang von außen freigeschaltet ist, verbindet sich der Administrator direkt mit dem VNC-Server und ist am Ziel.

Problematisch kann es sein, wenn der Administrator des Hosts und jener der virtuellen Instanz nicht dieselbe Person sind, beispielsweise bei durch Cloudprovider gehosteten VMs. Hier hat der VM-Administrator in der Regel keinen Zugriff auf den Host und kann auch keine VNC-Schnittstelle einrichten. Ist diese von Seiten des Anbieters deaktiviert, fällt diese Option über den Hypervisor für den Zugriff flach. Dann bleibt als Alternative nur, in der Instanz selbst einen VNC-Server zu betreiben und diesen für den Zugriff zu verwenden. Wenn das grafische Aufschalten auf eine Instanz notwendig ist, wird in dieser ohnehin bereits X11 laufen, sodass der Mehraufwand für die Installation des VNC-Servers zu vernachlässigen sein dürfte.

Performancewunder sollten Sie vom grafischen Zugriff auf Linux-VMs oder Linux-Desktops allerdings aus den beschriebenen Gründen nicht erwarten. Das wussten offensichtlich auch die Entwickler von Qumranet, zumindest im Hinblick auf VMs. Während Qumranet an KVM arbeitete, war ein Teil der Planung der Firma nämlich die Schaffung eines eigenen Protokolls für den entfernten Zugriff auf eben jene Instanzen. Geplant war also eine Art "VNC auf Steroiden", die viele architektonische Schwächen von VNC von Anfang an vermeiden sollte. Dafür sollte die neue Lösung ab Werk performanter und sicherer sein als ihr altbackener Vorgänger.

Um diese Ziele zu erreichen, entschieden sich die Entwickler für eine komplette Neuentwicklung, anstatt VNC zu erweitern oder zu verändern. Architektonisch ist die neue Schöpfung des Unternehmens ähnlich aufgebaut wie VNC: Erst entwickelte Qumranet eine Spezifikation für ein Protokoll, dann erfolgte die technische Umsetzung. Das Protokoll hört auf den Namen "SPICE" (Simple Protocol for Independent Computing Environments). Architektonisch unterscheidet sich SPICE deutlich von seinem Vorgänger VNC. Denn anders als VNC setzt SPICE auf eine tiefe Integration in das Gastbetriebssystem einer virtuellen Instanz, um seine Aufgaben zu erledigen. Vom Remote Framebuffer und ähnlichen Einrichtungen ist bei SPICE folglich keine Rede. Stattdessen benötigt das Protokoll diverse Komponenten, um zu funktionieren.

So muss auf dem System, das die virtuellen Instanzen betreibt, zunächst ein SPICE-Server laufen, der die Kommunikation mit der Außenwelt übernimmt. Der ist für Qemu in Form einer Bibliothek implementiert und gehört seit 2010 zu dessen Standardfunktionsumfang. Damit SPICE funktioniert, müssen aber auch innerhalb der Instanz Bedingungen erfüllt sein. Zunächst braucht der dortige Kernel einen Treiber für QXL sowie einen für das Exportieren des Desktops. Der QXL-Treiber leitet die Grafikdaten zur Außenwelt und der sogenannte VDI-Agent setzt eingehende Befehle wie Tastatureingaben oder Bewegungen des Mauszeigers innerhalb der Instanz um. Die SPICE-Dienste in der Instanz kommunizieren über standardisierte Schnittstellen mit der VDI-Integration des Hypervisors und letztlich mit dem dort integrierten SPICE-Server. Die gesamte Kommunikation zwischen diesen Komponenten ist im SPICE-Protokoll beschrieben. Last but not least ist für SPICE auch ein spezieller Client nötig, der eingehende Befehle wie Mauszeigerbewegungen aufzeichnet und sie an den SPICE-Server schickt, der die Weiterleitung in die Instanz übernimmt.

Weil SPICE komplett neu war, konnten die Entwickler technisch aus dem Vollen schöpfen und die Standards der späten 2000er nutzen statt jener Mitte der 80er. Das zeigt sich in SPICE an vielen Stellen: Unter der Haube etwa gibt es für die einzelnen Gerätschaften wie Maus und Tastatur eigene, voneinander getrennte, TLS-verschlüsselte Kommunikationskanäle anstelle einer statischen Verbindung. Auch SASL (Simple Authentication and Security Layer) als Authentifizierungsmechanismus steht zur Verfügung, wo unter VNC die Systemauthentifizierung notfallmäßig zum Einsatz kommen muss – was nicht selten zu kruden Hacks in den verfügbaren VNC-Werkzeugen führt, da Authentifizierung hier nicht immer ab Werk dabei ist. Obendrein nutzt SPICE für die diversen Kanäle ab Werk Verschlüsselung mittels verschiedener Algorithmen. Das erhöht die virtuelle Bandbreite und hilft gerade bei weniger stabilen Verbindungen immens. Die Praxis spricht hier eine klare Sprache: SPICE funktioniert auch bei Verbindungen, bei denen durch SSH getunneltes X11 oder VNC längst den Betrieb eingestellt haben.

Vor diesem Hintergrund ist verwunderlich, dass SPICE in vielen KVM-Setups nicht zum Einsatz kommt, sondern viele Admins stattdessen noch immer auf das veraltete VNC setzen – zumal die Unterstützung für SPICE auf der Ebene der Gastbetriebssysteme ausgezeichnet ist. Für Linux wie für Windows stehen passende Treiber sowie der Agent bereit, die innerhalb der Instanz vorhanden sein müssen, damit SPICE funktioniert. Auf Host-Ebene arbeitet SPICE, sobald eine Standarddistribution mit KVM und Qemu gegeben ist, denn sämtliche großen Distributoren liefern ihr Qemu mittlerweile mit Unterstützung für SPICE aus. Clients für Windows wie Linux, um sich mit den virtuellen Instanzen zu verbinden, sind ebenfalls mannigfaltig verfügbar.

Auch lizenztechnisch stellt SPICE mittlerweile zudem keine Herausforderung mehr dar. Denn nachdem Red Hat Qumranet gekauft hat, fiel auch SPICE an das Unternehmen. Etwa ein Jahr später stellte Red Hat das SPICE-Protokoll unter eine freie Lizenz, was zum Entstehen einer regen Open-Source-Community [1] führte.

Wie in der Open-Source-Welt üblich, haben sich in dieser Community bald Gelüste entwickelt, SPICE auch außerhalb des ursprünglich vorgesehen Kontextes zu nutzen. Konkret war die Hoffnung, SPICE als Ersatz für VNC auch auf nicht-virtualisierten Systemen zu nutzen. Bei der SPICE-Architektur haben die Entwickler aber offensichtlich vieles richtig gemacht – denn sie ist flexibel genug, um einen SPICE-Server an verschiedenen Stellen im System unterzubringen. Mittlerweile existiert ein eigener X-Server mit SPICE-Schnittstelle als "X11spice" [2], das sich mit einem bestehenden X-Server verbindet und eine SPICE-Schnittstelle für diesen ausliefert.

Der Zugriff auf grafische Schnittstellen verschiedener Betriebssysteme sowohl virtualisiert als auch physisch ist aus technischer Sicht heute keine Herausforderung mehr. Windows wie macOS stellen eigene Werkzeuge zur Verfügung, die gut funktionieren, im Falle von macOS aber nicht ganz günstig sind.

Für Linux-Hosts und -VMs sowie Win-dows-VMs auf Linux-Hosts ist die Situation etwas komplexer. Die meisten Distributoren bieten zwar eine VNC-In- tegration, doch entspricht diese nicht mehr dem Stand der Technik. Besser wäre es, an dieser Stelle auf SPICE zu setzen, das moderner, sicherer und in Summe auch deutlich schneller ist. Die dafür notwendigen Komponenten sind unter einer freien Lizenz kostenlos verfügbar. Oft trennen den Administrator vom SPICE-Glück nur ein paar Minuten Recherche und die Installation einiger Pakete auf dem Host wie auf dem Gast – schon fluppt die entfernte Verwaltung virtueller Instanzen grafisch deutlich besser. Ein Blick lohnt sich also auf jeden Fall.