16 Templates (VM-Vorlagen)

Templates sind äußerst nützlich, wenn es darum geht, neue virtuelle Maschinen schnell zu erstellen. Dies nicht nur im normalen Betrieb, sondern auch im Katastrophenfall sehr hilfreich. Um Templates zu erstellen, benötigt man nicht unbedingt ein neues Produkt, denn man kann das auch manuell mit den Werkzeugen der Virtualisierungsserver tun.

Was sind Templates und welchen Nutzen hat man davon?

Unter Templates versteht man Vorlagen oder Vorlagendateien, die dazu dienen, bei der Erstellung z. B. eines neuen Word-Dokumentes Zeit einzusparen. Das ist jedoch nicht alles: Man grenzt auch Fehlerquellen ein bzw. beseitigt sie, in dem man, um beim Word-Beispiel zu bleiben, sich wiederholende Textpassagen in eine Vorlage speichert und mittels dieser immer wieder neue Dokumente erstellt. Natürlich hat dies auch den entscheidenden Nachteil, dass bei einem Fehler in der Vorlage alle darauf basierenden Dokumente auch von diesem Fehler befallen sind. Aber es gibt nur eine Fehlerquelle, nämlich einzig und allein die Vorlage selbst. Daher sollte man auch bei der Anlage des ersten Templates äußerst sorgfältig vorgehen, um spätere Probleme schon im Voraus auszuschließen.

Abbildung 16.1 Erstellung eines Images von einer physikalischen Maschine

Mittlerweile hat man dieses doch sehr nützliche Verfahren nicht nur bei Word- oder allgemeinen Dokumenten eingebracht, sondern auch in Form von Images für physikalische Maschinen z. B. durch Symantec Ghost. Dort installiert man ein Betriebssystem mit allen benötigten Anwendungen, löscht die individuellen Einstellungen wie die Netzwerkeinstellungen und sichert diese Daten in ein Image (Abbildung 16.1). Mit diesem Image werden dann alle weiteren Systeme deutlich schneller und fehlerfreier installiert, als es manuell möglich wäre. Einen großen Nachteil hat dieses Verfahren, zumindest bei physikalischen Maschinen: Es läuft nur bei identischer Hardwarekonfiguration sicher und fehlerfrei.

Virtuelle Maschinen passen durch die immer gleiche virtuelle Hardware allerdings perfekt in den Mechanismus von Templates. Es kommt hinzu, dass meistens nur eine Datei (die Festplattendatei des Betriebssystems) benötigt wird und nicht einmal ein Imaging Tool eingesetzt werden muss, um ein Image herzustellen, denn Sie haben dieses automatisch, sobald die virtuelle Maschine fertig installiert ist. Daher empfiehlt es sich auch, die System- und Datenpartition einer VM zu trennen und als unterschiedliche Festplattendateien anzulegen.

Wenn man diesen Gedanken weiterspinnt, kommt man sehr schnell dazu, dass nicht nur ein Template, sondern viele verschiedene Templates erstellt und hinterlegt werden können, die verschiedenste Betriebssysteme mit unterschiedlichsten Softwareständen und Service Packs enthalten können. Dadurch lassen sich in kürzester Zeit, bei guter Festplattenleistung in ca. 15 Minuten, neue virtuelle Maschinen auf der Basis eines Templates erstellen. Diesen Vorgang könnte man sogar noch automatisieren, um beispielsweise eine Test- oder Entwicklungsumgebung regelmäßig neu aufzusetzen. Aber vor allem das Disaster Recovery wird durch Templates sehr verbessert, da Sie mehrere Templates für die einzelnen Service Pack-Stände Ihrer virtuellen Maschinen hinterlegen und sie je nach ausgefallenem System entsprechend »zurücksichern« können. So schnell können Sie kein physikalisches System in seinem Ursprungszustand wiederherstellen.

16.1 VMware

Bei VMware wird zwischen dem »COW«-Format, das bei VMware GSX und Workstation verwendet wird, und dem »monolithischen Format«, wie es beim VMware ESX Verwendung findet, unterschieden. Solange Templates nur innerhalb einer Version benutzt werden, ist eine Konvertierung nicht zwingend notwendig, bei einer Verwendung zwischen GSX und ESX hingegen schon. In Kapitel 13, VMware VirtualCenter, wurden Sie schon auf die einfachste, weil durch einen Wizard unterstützte Art der Erstellung hingewiesen, allerdings ist eine Erstellung auch durch manuelles Kopieren problemlos möglich. Da eigentlich nur die virtuelle Festplattendatei, die das System beinhaltet, zur Erstellung des Templates benötigt wird, müssen Sie im Endeffekt nur die entsprechende .dsk- oder .vmdk-Datei (oder Dateien bei einem 2 GB Split beim COW-Format) kopieren und damit eine neue virtuelle Maschine aufsetzen.

Abbildung 16.2 Endausbau einer funktionierenden virtuellen Infrastruktur mittels Templates

Unabhängig von diesem Problem könnte man mit Templates die gesamte virtuelle Infrastruktur wesentlich verbessern. Templates werden zentral für die jeweiligen Betriebssysteme (oder Softwarestände) auf einem Server abgelegt, und man nutzt diese als Basis, sobald eine virtuelle Maschine erstellt oder wiederhergestellt werden muss. In Abbildung 16.2 sehen Sie ein Beispiel für eine solche Infrastruktur, in der alle Templates auf einem Templateserver vorgehalten werden, die sowohl von virtuellen Maschinen auf GSX Servern als auch auf ESX Servern genutzt werden können.

16.1.1 Erstellung

Abbildung 16.3 Ablauf einer Template-Erzeugung mittels Sysprep

In Abbildung 16.3 sehen Sie den Ablauf, an dessen Ende ein fertiges Template für zukünftige VMs zu steht. Zuerst müssen Sie eine virtuelle Maschine der von Ihnen gewünschten Art installieren und auf den aktuellen Stand bringen. Danach können Sie, falls es eine Microsoft Windows VM ist, das Tool Sysprep über das System laufen lassen, um alle individuellen Konfigurationen wie Rechnername, Seriennummer oder Netzwerkkonfiguration zu entfernen. Nachdem Sysprep den Rechner heruntergefahren hat, müssen Sie sich nur den Namen und Pfad der Festplattendatei merken. Diese können Sie dann einfach auf ein Netzlaufwerk, eine weitere lokale Festplatte oder an einen Ablageort innerhalb des SAN kopieren.

Eine VM mit einem anderen Gast-System als Windows wird prinzipiell genauso behandelt, nur dass Ihnen das Sysprep Tool nicht zur Verfügung steht. Unter Linux müssen Sie nur darauf achten, dass alle Netzwerkeinstellungen (vor allem keine feste IP-Adresse auf dem Template belassen) und der Rechnername vor der Verwendung als Template neutralisiert werden.

Damit ist die Erstellung schon abgeschlossen und Ihnen steht ein funktionstüchtiges Template bereit. All diese manuellen Eingriffe nimmt Ihnen das VMware VirtualCenter (zumindest für VMware Server) komplett ab, bzw. führt Sie mittels eines Assistenten sehr einfach durch die notwendigen Schritte. Ein weiterer Vorteil des VirtualCenters zeigt sich darin, dass Sie sich nicht um das Format der Festplattendateien kümmern müssen, was bei einem manuellen Eingriff sehr wohl der Fall sein kann.

COW Format der Festplattendateien (VMware GSX/WS)

Wie schon angesprochen, legen VMware Workstation und VMware GSX die Festplattendateien im so genannten »COW« (Copy on Write)-Format ab. In diesem Format können die Festplattendateien auf »normalen« Dateisystemen (NTFS, EXT3, ... nicht-VMFS) lesbar in =<2 GB großen Dateien abgelegt werden. Die 2 GB-Grenze entsteht durch die mangelnde Unterstützung mancher Dateisysteme, wie dem aus Linux bekannten EXT2, die keine größeren Dateien verarbeiten können. Ebenso existieren immer noch Programme, die keine Dateien, die größer als 2 GB sind, verarbeiten können. Mittlerweile wurde dieses Format allerdings so angepasst, dass auf Wunsch keine Aufteilung in 2 GB-Dateien mehr stattfinden muss. Allerdings wollen wir bei der alten Ablageart bleiben, ist sie doch noch sehr weit verbreitet.

Das COW-Format der Festplattendateien sieht eine Beschreibungsdatei und ein oder mehrere Festplattendatendateien vor (Abbildung 16.4). Hier sehen Sie den Inhalt einer solchen Beschreibungsdatei namens hdd1.vmdk, die den ersten Teil der Dateigruppe darstellt:

# Disk DescriptorFile 
version=1 
CID=7d4fb1cf 
parentCID=ffffffff 
createType="twoGbMaxExtentFlat"     ß Festplattentyp 
 
# Extent description 
Diese Dateigruppe besteht aus einer Beschreibungsdatei und  
3 Datendateien 
RW 4193792 FLAT "hdd1-f001.vmdk" 0  ß erste Datenplatte 
RW 4193792 FLAT "hdd1-f002.vmdk" 0  ß zweite Datenplatte 
RW 1024 FLAT "hdd1-f003.vmdk" 0     ß dritte Datenplatte 
 
# The Disk Data Base 
#DDB 
 
ddb.toolsVersion = "0" 
ddb.adapterType = "buslogic"       ß Adaptertyp 
# Geometriedaten der Festplatte 
ddb.geometry.sectors = "63" 
ddb.geometry.heads = "255" 
ddb.geometry.cylinders = "522" 
ddb.virtualHWVersion = "3"         ß Hardwareversion

Abbildung 16.4 Festplattendateien einer virtuellen Maschine unter VMware GSX

Monolithisches Format der Festplattendateien (VMware ESX)

Unter VMware ESX können Festplattendateien einer virtuellen Maschine nur auf VMFS-Partitionen und damit im monolithischen Format genutzt werden. Dieses monolithische Dateisystem ist für große Dateien optimiert und eignet sich daher ideal als Basis für leistungsstarke virtuelle Maschinen. In diesem Format wird keine 2 GB-Aufteilung mehr vorgenommen, d. h., sie liegt in einem Stück vor, und es existiert auch keine Beschreibungsdatei für die Festplatte. Zudem werden Festplatten in diesem Format immer mit der maximal möglichen Größe angelegt. Das bedeutet, dass eine 20 GB Festplatte, die auf dem GSX Server zwar 20 GB maximale Größe hat, jedoch nur mit 5 GB gefüllt ist, im monolithischen Format immer 20 GB Platz benötigen wird. Die Größenbegrenzung einer Festplattendatei unter VMware ESX im monolithischen Format ist eigentlich nur theoretisch erreichbar und liegt bei 28.5 TB.

Umwandlung COW ↔ in monolithic(ESX) Format

Da es Sinn macht, Templates nicht nur in dem System zu nutzen, auf dem Sie erstellt wurden, kann man diese Formate in das jeweils andere problemlos umwandeln. Die nach der Umwandlung entstandenen Dateien können danach ohne weitere Aktion direkt in virtuellen Maschinen verwendet werden. Gerade bei der Umwandlung von monolithischen Festplatten in COW-Festplatten müssen Sie daran denken, alle enstehenden Festplattendateien in das Verzeichnis der VM auf dem GSX Server zu kopieren.

Umwandlung COW → monolithic

Abbildung 16.5 Umwandlung der COW-Festplattendatei in ein monolithisches Format (import)

Da ein VMware ESX Server auf das monolithische Dateisystem ausgerichtet ist, kann er nicht auf Festplatten im COW-Format zugreifen. Daher müssen diese Platten vor der Verwendung mit dem vmkfstools-Befehl importiert werden, denn es wird immer von der Seite des ESX Servers ausgegangen. Es müssen alle Teile der Festplattendatei (Festplattenbeschreibung und alle Festplattendatendateien) auf eine Partition kopiert werden, auf die der ESX Server Zugriff hat.

Wenn wir von den Dateien in Abbildung 16.4 ausgehen und uns vorstellen, diese wären schon ins /vmimages-Verzeichnis des ESX Servers kopiert worden, würde der Vorgang folgendermaßen ablaufen. Als Ziel der Festplatten soll die VMFS-Partition /vmfs/local dienen. Über den Befehl vmkfstools –i /vmimages/ hdd1.vmdk /vmfs/local/hdd-esx-1.dsk würden wir den Import anstoßen. Sobald dieser Import abgeschlossen ist, kann die Datei /vmfs/local/hdd-esx-1.dsk als Festplatte für eine virtuelle Maschine auf dem ESX Server genutzt werden. Alle Informationen zu diesem Befehl finden Sie in Anhang A.

Umwandlung monolithic → COW

Abbildung 16.6 Umwandlung einer monolithischen Datei in das COW-Format (export)

Wenn die Festplattendatei auf einem ESX Server erstellt wurde, aber nun von einer virtuellen Maschine auf dem GSX Server genutzt werden soll, müssen wir den umgekehrten Weg gehen. In diesem Fall liegt eine Datei Hdd-esx1.dsk im monolithischen Format vor und muss ins COW-Format konvertiert werden. Da wir vom ESX Server ausgehen, machen wir einen Export mittels vmkfstools –e /images/hdd1.vmdk /vmfs/local/hdd-esx-1.dsk. Wenn Sie sich beide Befehle (Im- und Export) im Vergleich ansehen, werden Sie merken, dass die VMFS-Partition immer der zweite Parameter sein muss, daher werden Quelle und Ziel vertauscht. Sobald der Befehl erfolgreich ausgeführt wurde, erhalten Sie in diesem Beispiel vier Dateien. Eine Beschreibungsdatei und drei Datendateien, die maximal 2 GB groß sein dürfen.

16.1.2 Verwendung

Die Verwendung der Templates, besser der Template-Festplattendatei, ist deutlich simpler als deren Erstellung. Natürlich müssen Sie erst die Festplattendatei kopieren und umbenennen, denn sonst hätten Sie kein Template mehr.

Nun muss lediglich eine neue virtuelle Maschine angelegt werden, in der Sie die Festplattendatei über Existing bei der Festplattenauswahl angeben. Sobald nun die virtuelle Maschine gestartet wird, können Sie diese konfigurieren. In unserem Beispiel wird mit Sysprep automatisch ein Assistent gestartet, der alle notwendigen Angaben abfragt.

Abbildung 16.7 Bei der Erstellung einer neuen VM muss nur die Kopie der Template-Festplatte als »existing virtual disk« angegeben werden

Abbildung 16.8 Die neue virtuelle Maschine auf der Basis der mit Sysprep vorbereiteten Festplatte, startet mit einem Assistenten, der alle benötigten Informationen bezüglich des neuen Systems abfragt.

Wenn Sie zu einem späteren Zeitpunkt das Template ändern wollen, müsste auch nur die Festplattendatei in eine virtuelle Maschine integriert werden. Nach dem Start und der möglichen Anpassung kann die VM wieder heruntergefahren und als Template weiterverwendet werden. Idealerweise legen Sie sich vor dem Anwenden von Sysprep eine Kopie der Festplatte an, damit Sie leichter Änderungen an dem Original-Template vornehmen können, ohne die Fragen des Setup-Assistenten (Abbildung 16.7) jedes Mal beantworten zu müssen.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.