Linked Clones VMs mit VMware vSphere 4

4-mal dasselbe bitte…

Letztens kam mal wieder jemand an und wollte mal eben, aber immerhin nur temporär vier PCs mit der selben Softwareausstattung für einen Datenexport haben. – Gut, er meinte natürlich, dass ich ihm vier VMs anlegen solle. So ist das halt, wenn man mittels Server-Virtualisierungsumgebung schneller als jeder andere in der EDV Abteilung Maschinen bereit stellen kann…

Moment mal…

Da fiel mir ein, dass ich vor einiger Zeit gelesen hatte, dass VMware vSphere (auch ESX 4 genannt) linked Clones beherrscht, also VMs mit einer gemeinsamen virtuellen Basis-Festplatte. – Das hier schien mir der optimale Zeitpunkt das mal auszuprobieren. Gedacht ist die ganze Sache eigentlich wohl für “VMware View”, der Haus-eigenen VDI-Lösung. – Technisch gesehen kann man die API wohl auch “so” ansprechen, und linked Clones oder “Linked Virtual Machines”, wie es offiziell heißt erstellen. Infos hier: Linked Virtual Machines – VMware Technical Note

Die Fertigmischung…

Da es keinen Button oder eine Option in den weiten der Menüs des vCenter Clients dafür gibt (halt nur in View…), wäre wohl Skripten angesagt. Aber auch hier gilt: Man muss ja nicht immer das Rad neu erfinden! – William Lam von yirtuallyGhetto hat das schon erledigt: vGhettoLinkedClone.pl

An die Arbeit

Nulltens

Für das Ganze brauchen wir das “VMware vSphere CLI” aus dem VMware Downdload Center. Weiterhin muss das dort enthaltene Perl-Modul apps\AppUtil.pm im Perl-Suchpfad sein. Bei meiner Standard-Installation unter Windows XP musste ich C:\Programme\VMware\VMware vSphere CLI\Perl\apps\AppUtil berücksichtigen. Der genutzte vSphere/ ESX Server muss außerdem von einem Virtual Center verwaltet werden.

Eine Grundlage schaffen

Wir gewünscht eine Windows XP VM “export1” deployed und die benötigte Software installieren lassen. Hiermit hatten wir schon mal eine VM.

Bitte recht freundlich

Erstmal einen Schnappschuss, äh Snapshot von unserer Basis-VM machen, einfach mit dem vCenter Client. Es macht Sinn einen Namen ohne Lehrzeichen zu verwenden. z.B. “Clone_Basis”

Und jetzt Klonen

Während das Original läuft jetzt auf der Kommandozeile mit dem Perl-Skript einfach die Klone erstellen:

C:\>perl .\vGhettoLinkedClone.pl --server vcenter.mein.netz
--username vcadmin --vmhost esx22.mein.netz --vmname
export1 --vmname_destination export2 --snapname Clone_Basis

Enter password:

Link Cloning virtual machine 'export2' from 'export1' ...

Clone 'export2' of virtual machine 'export1' successfully created.

Das ganze dauerte nicht wirklich lange. Ist ja auch kein Wunder, da ja im Gegensatz zu einer “normalen” Dublette einer VM  ja nicht alle Dateien einmal auf dem Storage kopiert werden müssen, sondern  nur die relativ kleinen Konfigurationsdateien für eine VM erstellt werden, wo die ursprüngliche vHDD Datei als Basis-Disk eingetragen wird und eine vHDD Datei für die zu schreibenden, geänderten Blöcke wie eine Snaphot-Datei eingetragen.

Das Skript eben noch für die weiteren zwei VMs laufen gelassen und fertig.

Et voila

Wenn man sich nun auf dem ESX Host umschaut, sieht man die Platz-Erparniss:

[root@esx22 VMSTORAGE]# ll -h export*
export1:
total 12G
-rw------- 1 root root 2.6G Aug 22 10:46 export1-000001-delta.vmdk
-rw------- 1 root root  294 Aug 22 10:47 export1-000001.vmdk
-rw------- 1 root root  17M Aug 22 11:28 export1-000002-delta.vmdk
-rw------- 1 root root  277 Aug 22 10:46 export1-000002.vmdk
-rw------- 1 root root 1.0G Aug 17 17:42 export1-8d3ef1db.vswp
-rw------- 1 root root  15G Aug 18 11:04 export1-flat.vmdk
-rw------- 1 root root 8.5K Aug 19 13:04 export1.nvram
-rw------- 1 root root 1.1G Aug 18 11:05 export1-Snapshot1.vmsn
-rw------- 1 root root  543 Aug 22 10:52 export1.vmdk
-rw-r--r-- 1 root root  503 Aug 22 11:20 export1.vmsd
-rwxr-xr-x 1 root root 2.7K Aug 22 10:46 export1.vmx
-rw-r--r-- 1 root root  266 Aug 17 17:42 export1.vmxf
-rw-r--r-- 1 root root 216K Aug 17 17:31 vmware-1.log
-rw-r--r-- 1 root root 231K Aug 22 11:21 vmware.log

export2:
total 2.0G
-rw------- 1 root root  1.0G Aug 22 10:56 export2-8d3ef1dc.vswp
-rw------- 1 root root 1009M Aug 22 11:29 export2-delta.vmdk
-rw------- 1 root root  8.5K Aug 22 11:03 export2.nvram
-rw------- 1 root root   387 Aug 22 10:56 export2.vmdk
-rw-r--r-- 1 root root     0 Aug 22 10:56 export2.vmsd
-rwxr-xr-x 1 root root  2.8K Aug 22 11:28 export2.vmx
-rw-r--r-- 1 root root   266 Aug 22 11:15 export2.vmxf
-rw-r--r-- 1 root root  216K Aug 22 10:56 vmware-1.log
-rw-r--r-- 1 root root  113K Aug 22 11:28 vmware.log

export3:
total 2.0G
-rw------- 1 root root 1.0G Aug 22 10:56 export3-8d3ef1dd.vswp
-rw------- 1 root root 993M Aug 22 11:28 export3-delta.vmdk
-rw------- 1 root root 8.5K Aug 22 10:55 export3.nvram
-rw------- 1 root root  387 Aug 22 10:55 export3.vmdk
-rw-r--r-- 1 root root    0 Aug 22 10:56 export3.vmsd
-rwxr-xr-x 1 root root 2.8K Aug 22 11:28 export3.vmx
-rw-r--r-- 1 root root  266 Aug 22 11:14 export3.vmxf
-rw-r--r-- 1 root root 216K Aug 22 10:55 vmware-1.log
-rw-r--r-- 1 root root  63K Aug 22 10:55 vmware-2.log
-rw-r--r-- 1 root root 113K Aug 22 11:28 vmware.log

export4:
total 2.0G
-rw------- 1 root root 1.0G Aug 22 10:53 export4-8d3ef1de.vswp
-rw------- 1 root root 993M Aug 22 11:28 export4-delta.vmdk
-rw------- 1 root root 8.5K Aug 22 10:53 export4.nvram
-rw------- 1 root root  387 Aug 22 10:52 export4.vmdk
-rw-r--r-- 1 root root    0 Aug 22 10:52 export4.vmsd
-rwxr-xr-x 1 root root 2.8K Aug 22 11:27 export4.vmx
-rw-r--r-- 1 root root  266 Aug 22 11:14 export4.vmxf
-rw-r--r-- 1 root root 216K Aug 22 10:52 vmware-1.log
-rw-r--r-- 1 root root 113K Aug 22 11:27 vmware.log

VM export1 belegt 12GB (und würde noch mehr belegen, wenn die vHDD nicht Thin Provisioned wäre) während export2 bis export4 nur 2GB belegen, wovon ein GB jeweils für die beim Einschalten einer jeden VM erstellte Swapdatei in Größe des konfigurierten vRAMs drauf geht…

 

Windows 98 mittels VMware Converter und VMware Player virtualisieren (P2V)

Wie es begann

Letztens kam jemand um die Ecke und meinte “Du machst Doch Virtualisierung und so?!”. Ich: “Ja…”.

Dann kam’s: Es gab da einen (ur-)alten PC mit MS Windows 98 als Betriebssystem (sofern man das so nennen sollte). Dieser PC fing langsam an Mucken zu machen und weigerte sich das ein- oder andere Mal zu starten. Ob ich den nicht virtualisieren könne.

Und los geht’s

Ich schaute mir also das für IT-Zeitrechnung schon ziemlich historische Gerät an: Intel Pentium Prozessor, 32MB RAM und 2GB IDE-Festplatte (von 1997!). – Mit der RAM-Ausstattung entfiel schon mal die Möglichkeit direkt mit einer CD eines aktuellen Platten-Imaging Produktes zu booten.

Wie es doch ging

Also Platte raus, in einen mittelalten PC mit IDE Controller als zweite Platte rein, dann von CD gebootet und mir Acronis ein Image geschossen. Soweit so gut.

Jetzt virtuell

Den PC gebootet (Windows XP, ähem also auch nicht das neueste) und den VMware Converter Standalone angeschmissen. Option Dritthersteller Images konvertieren und Ziel-System?! Naja, gönnen wir uns mal das neueste und vermeintlich beste, was da ist: VM für VMware Player v. >2.5.

(Virtuell) Fertig und los

Gesagt, etwas gewartet und fertig. – Dann das Windows 98 in der VM mit VMware Player 3 gebootet und los ging der “Spaß”. Das Plug’n’Play fand ein Gerät nach dem anderen, und vor allem PCI-Bridges bis zum Abwinken! Der “Neue Hardware” Assistenten lief und lief und würde wohl heute noch laufen, wenn ich nicht abgebrochen hätte.

Zurück in die (virtuelle) Steinzeit

Tja, mein gut gemeinter Wunsch eine VM für VMware Player v. > 2.5 zu erstellen hatte mir VMware virtuelle Hardware Version 7 beschert. Da gibt es so spannende Features wie 32(!) PCI Bridges und vieles derer mehr. – Für ein alten System wie Windows 98 eine nicht wirklich gute Idee.

Also nochmals den VMware Converter angeworfen und die VM in eine für u.a. VMware Player v. 1 konvertiert: VMware virtuelle Hardware Version 4…

Zurück auf Los (und keine 4000 Mark…)

Die VM gebootet, einmal den Hardware-Assi durchgeklickt, VMware Tools für Pre Windows 2000 rausgesucht und installiert, nochmal den Hardware Assistenen “Fertig” geklickt und gut war.

Fazit

Also lerne ich daraus: Das Neueste ist (auch virtuell) nicht immer das Beste.

Bei einem älteren Betriebssystem in einer VM darf es auch ruhig eine ältere virtuelle Hardware-Version (v. 4 für z.B. VMware Player 1) sein.