© fuzzbones, 123Rf

Linux- und Windows-Desktops aus der eigenen Wolke verteilen und auch noch zentral verwalten – das ist kein Kinderspiel, und ansprechende Linux-Rezepte dafür sind rar. Auf der Karte der Bremer Linux-Küche Univention steht seit Kurzem auch eine Desktopvirtualisierung.

Während Linux-basierte Hypervisoren in letzter Zeit maßgeblich daran beteiligt waren, die private Cloud massentauglich zu machen [1], scheint die Open-Source-Szene das Thema Desktopvirtualisierung verschlafen zu haben: Bislang finden sich kaum quelloffene Lösungen für das zentrale Deployment von Desktops in virtuellen Maschinen. Dabei haben Unternehmen das Thema Virtual Desktop Infrastructure (VDI) als eine der zentralen Aufgaben der nächsten Jahre identifiziert (siehe [2] und den Kasten “VDI im Kommen”).

UCS DVS

Diese Lücke will Univention [3] mit den Univention Corporate Server Desktop Virtualization Services (UCS DVS) schließen. Die Bremer Linux-Company setzt das neue Produkt nahtlos auf dem komplexen UCS auf ([4] und Kasten “Preise und Verfügbarkeit”). Die zentral betriebenen und verwalteten Windows- und Linux-Desktops sollen mittels Virtualisierung Kosten und Aufwand mindern und die Hardware besser ausnutzen.

Integrierte Architektur

UCS DVS setzen auf dem Univention Virtual Machine Manager (UVMM) auf und virtualisieren die Desktops auf Basis von KVM. Die in UVMM vorhandene Xen-Unterstützung steht dafür nicht zur Verfügung. Die DVS erben aber die ganze Palette der UCS-Features: komfortables, Web-basiertes und zentrales Management, Verteilung der Management- und Virtualisierungs-Infrastruktur auf mehrere Server zur Verbesserung der Verfügbarkeit sowie LDAP-basiertes UCS-Identitymanagement.

Mit den Desktop Virtualization Services können IT-Verantwortliche Desktops auf Basis von Windows XP, Windows 7 (32 und 64 Bit) sowie Univention Corporate Desktop virtualisiert betreiben.

Das Desktop-Virtualisierungssystem erzeugt dabei je Anwender individuelle Desktop-VMs automatisch auf Basis von Vorlagen. Jedem Anwender sind dabei im Univention-System virtuelle Desktops zugeordnet, die der Server beim Start aus der Vorlage klont. Die virtualisierten Desktops sind in die UCS- oder in eine Active-Directory-Domäne integriert und Teil des Vertrauenskontexts. Anwender greifen auf ihren virtualisierten Desktop entweder von einem Thin Client oder von einem Windows- oder Linux-PC aus zu, auf dem der native DVS-Client installiert ist. Je nach Desktop-Betriebssystem nutzt er RDP oder X2GO, um sich mit der virtuellen Maschine zu verbinden. Drucker- und Audiostreams der Windows-Desktops werden dabei auf Wunsch auf den Client weitergeleitet.

Eine DVS-Umgebung ist modular aufgebaut und besteht aus folgenden Komponenten (Abbildung 1):

Abbildung 1: Die modulare UCS-DVS-Architektur in der schematischen Darstellung.

• Das UCS-Managementsystem hält die Domänendaten in einem zentralen LDAP-Verzeichnis – etwa die Benutzer- und Rechnerkonten – und ist über ein Web-basiertes GUI steuerbar.
• DVS-Nodes sind KVM-Hosts, die die virtualisierten Desktops betreiben. Diese lassen sich für besseren Lastausgleich und Hochverfügbarkeit auf beliebig viele DVS-Nodes verteilen. Fällt ein Node aus, verschiebt der Server die laufenden Desktops automatisch auf einen anderen Knoten.
• Der Session-Broker ist die zentrale Komponente jeder VDI-Umgebung. Sie übernimmt die Verwaltung der laufenden Benutzersitzungen. Benutzer melden sich über diesen Dienst an und erhalten dabei die Informationen über die zu verwendende Gastinstanz. Der Session-Broker regelt auch den Start und das Pausieren der Benutzersitzungen bei An- und Abmeldung oder nach Erreichen eines Timeout. Zum Lastausgleich sind auch mehrere Session-Broker pro DVS-Umgebung möglich.
• Ein oder mehrere Thin-Client-Server stellen Thin Clients ihr Bootimage bereit. Ein bootender Thin Client bindet das Unterverzeichnis entweder via NFS oder vom lokalen Compact-Flash- oder vom USB-Speicher als sein Rootverzeichnis ein.

Aufgrund des komplexen Aufbaus ist der Admin gut beraten, sein Setup vorab gründlich zu planen. UCS-Server bedienen sich für die Administration eines umfangreichen Rollenkonzepts.

Rollen

Für den Betrieb einer DVS-Umgebung bedarf es mindestens eines Servers in der Rolle als Domänencontroller-Master. Wem Ausfallsicherheit wichtig ist, der sollte auch einen entsprechenden DC-Backup-Server vorsehen. Soll die Umgebung hochverfügbar gestaltet sein, benötigt er zentralen Speicher auf Basis von NFS, I-SCSI oder FC für das Speichern der DVS-Vorlagen.

Auf dieser Grundlage lassen sich dann die benötigten Dienste Session-Broker, Thin-Client-Umgebung und DVS-Node beliebig auf weitere Rechner mit der Rolle Domänencontroller-Slaves verteilen, wo dann jeweils ein DVS-Node läuft. DVS muss in der Lage sein, über das UCS-Managementsystem die Namen und IP-Adressen der virtuellen Instanzen zu vergeben. Hierfür benötigt die Umgebung ein funktionierendes DNS und DHCP. Beides bringt UCS mit.

Testumgebung

Für die Testumgebung genügt das Aufsetzen eines Univention-Servers in der Systemrolle als Domaincontroller-Master. Auf dem Master installiert der Sysadmin das Managementsystem, also den Univention Directory Manager, und Infrastrukturkomponenten wie Open LDAP, PKI, Kerberos und DNS-Server.

Zum Test bietet sich die “Free for personal Use”-Edition an ([5], auch auf der DELUG-DVD). Bei Redaktionsschluss stand die in Version 2.4 bereit, wobei die Installation mit einem menügeführten Textinstaller erfolgt. Um die Virtualisierungskomponenten einzurichten, muss der Admin bei der Software-Auswahl »Virtual Machine Manager (UVMM)« und »KVM« auswählen. Danach ist das Update auf die aktuelle Version fällig:

univention-updater net --updateto 2.4-3

Mit den Kommandos aus Listing 1 installiert er auf der Kommandozeile die Pakete für DVS, Terminalclient-Server und Session-Broker sowie die zugehörigen LDAP-Schemata. Alle Installationen lassen sich auch über das Web-GUI des UMC durchführen.

 # Komponenten TCS und DVS über das Repository einbinden
univention-config-registry set repository/online/component/dvs=yes repository/online/component/dvs/version=current
univention-config-registry set repository/online/component/tcs=yes repository/online/component/tcs/version=current # Pakete univention-dvs-schema und univention-thin-client-schema installieren
univention-install univention-dvs-schema
univention-install univention-thin-client-schema # Installation eines DVS-Nodes
univention-install univention-dvs-node
univention-run-join-scripts # Installation des Thin-Client-Servers
univention-install univention-thin-client
univention-install univention-thin-client-dvs
univention-run-join-scripts # Installation des Session-Brokers
univention-install univention-dvs-sessionbroker
univention-run-join-scripts
reboot

Hat der Administrator das Aufsetzen der Server und Dienste hinter sich, beginnt die eigentliche Arbeit: In mehreren Schritten (Abbildung 2) installiert er den künftigen Desktop als virtuelle Maschine, generiert daraus eine Vorlage und ordnet diese anschließend Benutzern zu.

Abbildung 2: UCS DVS arbeitet mit Vorlagen, die Instanzen lassen sich einzelnen Benutzern zuordnen.

Univentions Managementkonsole erweist sich hier als hilfreiches Werkzeug: Via »UVMM | Node | Hinzufügen | Erstellen einer virtuellen Instanz« wählt der Administrator die Systemparameter der VM und installiert darin Windows oder Linux von einem DVD-Laufwerk oder aus einer ISO-Datei, die als DVD-Laufwerk eingebunden ist.

Virtio-Treiber

Wer Wert auf hohe Performance legt, sollte das Festplattenlaufwerk sowie die Netzwerkkarte mit paravirtualisierten Virtio-Treibern ausstatten. Für Windows-VMs muss dabei das Image mit den Virtio-Treibern als Diskettenlaufwerk eingebunden sein, damit die Treiber beim Windows-Start laden können.

Da diese erste VM zum “Golden Master” avanciert, sollte der Admin den Desktop mit allen Updates sowie Applikationen ausstatten, die er für den späteren Betrieb benötigt. Außerdem muss er in der Windows-Firewall den RDP-Port freigeben. Mit »net user administrator /active:yes« aktiviert er den Administrator-Account und ordnet ihm dann ein Passwort zu. Anschließend fährt er die VM herunter und erstellt sicherheitshalber einen Snapshot des aktuellen Zustands mit der Sicherungspunkte-Funktion des UVMM. Für den Fall, dass statt einer frischen Installation ein bereits installierter physischer Client als Vorlage dienen soll, hält Univention im Wiki ein entsprechendes Rezept bereit [6].

DVS-Vorlage erstellen

Über das Modul »DVS-Vorlagen« (Abbildung 3) auf dem Server, auf dem der Session-Broker läuft, macht sich der Admin im nächsten Schritt daran, die vorbereitete virtuelle Instanz in eine DVS-Vorlage umzuwandeln. Hierzu vergibt er im Vorlagen-Assistenten einen Namen und wählt die zuvor erstellte virtuelle Maschine als Instanz aus. Dabei sollte er die Option »Für das Erstellen der Vorlage eine Kopie dieser Instanz erzeugen und verwenden« aktivieren, damit die ursprüngliche Installation der VM erhalten bleibt und für die Erstellung anderer Vorlagen verwendet werden kann.

Abbildung 3: Im UMC-Dialog erstellt der Admin eine DVS-Vorlage.

Die Option »Instanz für SysPrep starten« bereitet die DVS-Vorlage auf die Individualisierung mit Sysprep vor. Dies sorgt später beim Start der individuellen Desktop-Instanz für den jeweiligen Benutzer dafür, dass der Desktop automatisch die korrekten Netzwerkeigenschaften, eine neue MAC-Adresse, den Lizenz-Schlüssel und Anmeldeinformationen eingeprägt bekommt (Abbildung 4 ).

Abbildung 4: Die UCS-Rechnerobjekte spiegeln die virtuellen Desktops wieder.

Nachdem er die Vorlage kopiert hat, verbindet sich der Administrator per VNC mit dem Desktop, um jetzt die Sysprep-Einstellungen vorzunehmen. Er kann dabei entweder eine XML-Konfigurationsdatei editieren, um die benötigten Einstellungen zu hinterlegen, oder die interaktive Variante wählen, für die er allerdings zunächst das Windows-AIK-Paket installieren muss. Die erforderlichen Schritte beschreibt das DVS-Handbuch [7] ausführlich.

Nach dem Editieren der »sysprep.xml« , die der Server bereitstellt, und dem Ausführen der Batchdatei »UCS-DVS-sysprep-noninteractive.bat« fährt der Desktop herunter, der Administrator wechselt nun in die Management Console (Abbildung 5) zurück. Im abschließenden Dialog kann er noch auswählen, ob das Generieren der Benutzer-Desktops aus der Vorlage die Option »Copy-on-Write« verwenden soll. Ist sie aktiviert, speichert DVS pro Benutzerdesktop nur die Abweichung vom Vorlagesystem. Dieser Ansatz spart bisweilen deutlich Speicherplatz. Ein Klick auf »Fertigstellen« schließt das Zusammenbasteln der Vorlage ab. Diese erscheint nun auch in der Übersichtsliste des Moduls und lässt sich dort den Benutzern zuweisen.

Abbildung 5: Die Univention Management Console mit DVS-Modulen.

Univention-Linux-Vorlage erstellen

Auch Linux-Vorlagen bedürfen der Vorbereitung. Hierzu verbindet sich der Sysadmin per SSH oder VNC mit der Basisinstallation und installiert das DVS-Paket sowie das UCD-Vorbereitungspaket (Listing 2)

univention-config-registry set repository/online/component/dvs=yes
univention-install univention-dvs-sysprep-ucd-boot

Anschließend führt der DVS-Manager das Kommando »univention-dvs-sysprep-ucd« aus und gibt Benutzernamen und Kennwort für den Zugriff auf die DVS-Freigabe ein. Danach gilt es, die Vorbereitungsskripte zu laden, die Maschine auf DHCP umzustellen und ein Init-Skript zu installieren, welches das System beim nächsten Start in die Domäne holt. Nach der Einrichtung der Vorlage fährt die virtuelle Maschine herunter.

Fragile Einrichtung

Nun ist die Virtualisierungs-Infrastruktur fast fertiggestellt. Der Admin wechselt abschließend in das Modul »DVS-Vorlagen« und verbindet dort die entsprechende, zuvor erstellte DVS-Vorlage mit dem gewünschten Benutzer. Die DVS generieren dann einen Klon des Desktops und führen automatisch den Sysprep-Vorgang zur Individualisierung der Anwender-VM durch. Dabei trägt der Server automatisch im Univention-Manager ein Rechner-Objekt mit dem passenden UCS-Konto sowie den DNS- und DHCP-Records ein.

Bei diesem Schritt erschien der Einrichtungsprozess im Test des Linux-Magazins noch etwas fragil. Es gelang nicht immer, den ersten Sysprep-Vorgang auf Anhieb zum Erfolg zu führen. Problematisch ist dabei, dass das übersichtliche Web-GUI einen aufgetretenen Fehler zwar anzeigt, aber nicht näher erläutert. Dem Administrator bleibt also gar nicht anderes übrig, als sich selbst in den Logfiles auf die Suche zu machen.

Auch ist schade, dass die Hardwareparameter wie RAM und Anzahl der CPUs bereits bei der Erstellung der Vorlage anzugeben sind. Möchte der Admin für einen User oder eine Gruppe die Einstellungen ändern, muss er hierfür die Konfiguration jeder VM einzeln bearbeiten. Eine Sammeloperation im Sinne einer Standardeinstellung, die für eine Gruppe von Desktops gilt, fehlt.

Jetzt steht der Desktop, der automatisch der UCS-Domäne beitritt, dem Anwender mit seinem normalen Domänen-Login zur Verfügung. Für maximalen Nutzen kommen dabei typischerweise Thin Clients zum Einsatz, womit sich die dezentrale Pflege von Desktops komplett erübrigt. Eher für Einzelfälle ist der native DVS-Client vorgesehen, für den zunächst Python und Qt auf dem Linux- oder Windows-PC zu installieren sind.

Hat der Administrator beim Erstellen der DVS-Vorlage die Option »Automatische Ermittlung« gewählt, werden die virtuellen Desktops beim Start dynamisch auf die verfügbaren DVS-Nodes verteilt. Das Zuteilungsverhalten kann er dabei über Soft- und Hardlimits flexibel bestimmen. Die DVS schicken auch automatisch VMs, die gerade nicht in Benutzung sind, in die Pause. Der Hypervisor schaltet sie in den Suspended-Modus, der Session-Broker weckt sie auf, sobald der Benutzer wieder auf sie zugreift.

Tief verwurzelt

Univention hat die DVS sehr tief im UCS integriert. Das zeigt sich auch daran, dass der Admin im Univention Directory Manager (UDM) festlegen kann, beim Anlegen eines neuen Benutzers solle der Server diesem automatisch einen bestimmten Desktop oder einen spezifischen DVS-Knoten zuordnen (Abbildung 6).

Abbildung 6: Interaktiv verwaltet der Admin die DVS-Vorlagen in der Univention Management Console.

Etwas befremdlich mutet allerdings an, dass die DVS es zwar ohne Weiteres ermöglichen, Anwendern beliebig viele VMs zuzuordnen, dem User jedoch immer nur entweder die als Standard markierte oder die zuletzt angelegte VM anbietet (Abbildung 7). Auswählen darf er selber (noch) nicht, dieses Feature ist laut Univention jedoch bereits geplant.

Abbildung 7: Anwendersicht: So sieht die Anmeldung an einer DVS-Sitzung im Thin Client aus.

User-Profile und durchdachte Verwaltung

Die Arbeit hört für den Admin an dieser Stelle aber noch nicht auf. Wie es für VDI-Szenarien typisch ist, muss er die Benutzerdaten sowie deren Userprofile unabhängig vom Betriebssystem-Image vorhalten, damit sich die Desktopvorlagen zentral pflegen und aktualisieren lassen. Nur unter dieser Voraussetzung kann er über neue DVS-Vorlagen frische Systeme ohne Datenverlust an die Anwender ausliefern.

Mit Univentions Desktop Virtualization Services erhalten Administratoren eine zuverlässige und einfach zu administrierende Lösung für die Virtualisierung von Desktops, die alle benötigten Komponenten in einem Paket liefert. Die Services überzeugen vor allem durch die durchgängige und vor allem einheitliche Verwaltung aller Funktionen. Sie stellen nicht nur Benutzer-bezogene VMs bereit, sondern kümmern sich auch um die Ausfallsicherheit, sinnvolle Lastverteilung sowie das durchgängige Benutzermanagement insbesondere in heterogenen Windows-Netzwerken.

Mit Univentions DVS sorgt die IT-Abteilung für eine verbesserte Hardwarenutzung, spart Aufwand beim Desktopmanagement und ermöglicht den Anwendern einen standortunabhängigen Zugriff auf ihre individuellen Desktops.

Kleiner Funktionsumfang zum kleinen Preis

Allerdings erweist sich der Funktionsumfang von UCS DVS im Vergleich zu etablierten kommerziellen Lösungen als spürbar kleiner. So ist etwa noch kein Pooling von Desktops eingebaut. Werkzeuge, mit denen sich Userprofile und Anwendungen vom System-Image trennen lassen, müssen Admins zudem bei Drittherstellern erwerben.

Auch die Protokollunterstützung erweist sich als etwas eingeschränkt. So stehen auf Desktopvirtualisierung spezialisierte Protokolle wie Red Hats Spice [8] nicht zur Verfügung, ebenso fehlen von anderen Anbietern bekannte Beschleunigungsverfahren. Für die Integration weiterer RDP-Beschleunigungsfeatures arbeitet Univention mit der Open Thin Client Initiative zusammen – hier verspricht man sich vom geplanten Umstieg von Rdesktop auf Freerdp in der nächsten Univention-TCS-Release bereits Verbesserungen bei der Grafikperformance.

Insgesamt eignet sich das Univention-System damit eher für kleinere Virtualisierungsprojekte sowie für Endanwender ohne High-End-Ansprüche. Es dürfte aber gerade für bestehende UCS-Kunden interessant sein. Testen lässt sich das anhand der freien Version [5] oder dem Image auf der DELUG-DVD.