Desktop-Deployment
Aufgrund des Box-Charakters des Serversystems hat der Administrator mit diesem nicht allzu viel Mühe. Im Fokus der VDI stehen vielmehr die virtuellen Desktops – und hier gilt es entsprechend viel Zeit und Sorgfalt einzukalkulieren.
Kaviza organisiert die Generierung und das Deployment von Desktops in mehreren Schritten:
-
Die Basis für einen neuen Virtuellen Desktop ist eine vorhandene Windows-VM. Unterstützt werden Windows XP und Windows 7 (32 und 64 Bit).
-
Aus dieser "Ur-VM" erstellt der Kaviza Manager zunächst ein sog. Working Image. Achtung: Die ursprüngliche VM existiert nach diesem Vorgang nicht mehr!
-
Der Kaviza Manager führt im Working Image einen Sysprep-Vorgang durch und erstellt dabei das endgültige Desktop Image.
-
Mittels Templates konfiguriert der Administrator die Eigenschaften der Desktops, wie Menge an Arbeitsspeicher, angeschlossene Peripheriegeräte und weitere Eigenschaften.
-
Auf Basis des Templates und des zugrundeliegenden Desktop Images werden pro Anwender dynamisch virtuelle Desktops deployed. Technisch handelt es sich um eigenständige VMs, welche aus dem Desktop Image gecloned werden (linked clones).
Die eigentliche Flexibilität entsteht aus der Fähigkeit, aus einem Desktop Image viele virtuelle Desktops generieren und mittels Templates deren Eigenschaften dynamisch bestimmen zu können. Mehrere verschiedene Templates dürfen dabei auf einem Image basieren. Somit ist die Verwaltung stark zentralisiert, der Administrationsaufwand wird minimiert.
Der eigentliche Vorgang der Generierung virtueller Desktops bis hin zur produktiven Nutzung ist von der Bedienung her einfach, vom gesamten Prozess jedoch durchaus diffizil, da bereits durch Kleinigkeiten der beschriebene Generierungsprozess fehlschlagen kann.
Vor allem muss der Kaviza-Administrator bei der Bereitstellung der Ur-VM eine ganze Reihe von Restriktionen kennen und penibel beachten: Beispielsweise muss die VM im selben Storage liegen wie die Kaviza-Server-VM selbst, zudem dürfen keine Snapshots zu der VM im Hypervisor existieren. Die Ur-VM darf nur über eine NIC und eine Festplatte verfügen. Bei Windows XP ist außerdem eine aktivierte Lizenzierung auf Basis einer Volumen-Lizenz zwingende Voraussetzung. RDP-Zugriff muss möglich sein, der HDX-Port freigeschaltet sein, der Administrator muss ein aktives Konto besitzen. Weiterhin muss der Windows-Patch KB 976494 installiert werden.
Hat der Administrator die Ur-VM derart vorbereitet, kann er in der Kaviza-Webkonsole die virtuellen Desktops generieren und das Deployment automatisieren.
Probleme können im wesentlichen nur dann entstehen, wenn der Administrator die Voraussetzungen nicht beachtet bzw. die Ur-VM nicht korrekt vorbereitet. Die eigentliche Schwierigkeit für den Verwalter liegt darin, dass Kaviza keine Fehlermeldungen ausgibt, sondern er einfach nur feststellt, dass die VM entweder nicht gespeichert oder später nicht deployed wird. In einer künftigen Version soll der Administrator ausführlicher informiert werden.
Als Best Practice ist es empfehlenswert, nach der Erstellung einer "gültigen" Ur-VM diese als "Golden Kaviza Master" sofort zu clonen (nicht linked clone), um für spätere Desktop-Generierungen wieder auf eine fertige VM zurückgreifen zu können. Denn Kaviza wandelt die Ur-VM in ein VM-Template um, welches nicht mehr direkt als VM nutzbar ist.