Angenommen man braucht von einer virtuellen Maschine mehrere leicht veraenderte Varianten. Normalerweise wuerde man den ganzen Ordner der VM kopieren, die Kopie umbenennen und koennte diese Kopie dann separat starten. Dieses mag in manchen Faellen sehr sinnvoll sein - in anderen Faellen ist es aber eine Verschwendung von Festplattenplatz.
Es geht aber auch noch anders. Der Trick bei der Sache ist ganz einfach. Statt einer normalen vmdk gibt man einer VM das REDO-log einer anderen VM als Festplatte. Da VMware aber nach der Ausgangs-Festplatte suchen wuerde, wenn es etwas mit REDO im Namen als Festplatte vorgesetzt bekommt - muessen wir das REDO-log umbenennen.

Das hoert sich ganz einfach an - ist es auch - aber nur wenn wir die Aenderung an einer Descriptorfile vornehmen koennen. Geht es um eine vmdk ohne Descriptorfile wird die Sache um einiges schwieriger da dann das Umbenennen mit einem Hexeditor erfolgen muss und man eventuell eine Datei in Gigabyte-groesse in einen Hexeditor laden muss.

Also probieren wir den Vorgang erst einmal an einem leichten Beispiel und nehmen eine VM mit dem Festplattentyp twoGbMaxExtentSparse. Eine Festplatte dieses Typs hat eine Descriptorfile die auf mehrere einzelne Stuecke verweist, die in der Groesse wachsen koennen. Alle Modifikationen sind jetzt mit einem normalen Texteditor - wie Notepad oder Kate - einfach zu erledigen.

In diesem Fall nehmen wir mal eine frische Gastinstallation. Genauer gesagt ein XP. Nach der Installation und ein paar Neustarts nach zusätzlichen Installationen sind wir zufrieden und nehmen den derzeitigen Status des Gasts als Ausgangspunkt fuer unsere Maschinenvermehrung.
Das Ausgangsmaterial sollte etwa so aussehen wie unten aufgelistet.



Hier ist eine Auflistung der Dateien die sich typischerweise in einem Ordner befinden. Diese VM hat keinen Snapshot
basedisk.vmdk = Descriptorfile der Festplatte
basedisk-s00* = dieses sind die einzelnen Stuecke aus der sich die Festplatte zusammensetzt
basedisk.vmx  = Dies ist die Liste mit der eingebauten virtuellen Hardware
nvram = non-volatile RAM - hier befinden sich sozusagen unsere BIOS-einstellungen
vmware.log = hier werden alle Missetaten der VM vermerkt

Diese Datei zeigt VMware wo die Festplatten stuecke sich befinden. 

Achtung: diese Datei nur dann editieren, wenn man ganz genau weiss was man tut.

Diese Datei wird wohl in jedem Fall anders aussehen.

Uns kommt es im Moment aber nur auf die Festplatte an. Hier finden wir den Verweis auf die 'basedisk.vmdk'

Wenn wir mit dem Ausgangsmaterial zufrieden sind machen wir davon einen Snapshot.
Ab diesem Zeitpunkt werden alle Veraenderungen nicht mehr direkt in die vmdk geschrieben sondern werden in ein REDO-log umgeleitet.
Zu diesem Zeitpunkt wollen wir nicht mit der VM arbeiten sondern nur ein REDO-log anlegen. Deswegen reicht es voellig aus, die VM nur ganz kurz zu starten - noch bevor irgend etwas geladen wird stellen wir die VM auch schon wieder ab.
Schauen wir uns doch mal den Ausgangsordner an und registrieren was passiert ist.



Was hat sich veraendert? Es sind 6 Dateien mit einer REDO-extension hinzugekommen. Ein REDO-log aehnelt im Aufbau einer normalen vmdk. Es gibt eine Descriptorfile in der, wie bei einer normalen vmdk, vermerkt ist, wo sich die einzelnen Stuecke befinden.
Aus diesem Ordner entwenden wir jetzt skrupellos alle *REDO* - Dateien.
Das sind in diesem Fall

Mit diesem Diebesgut unter dem Arm suchen wir uns am besten schnell ein Versteck. Was eignet sich dafür besser als ein bislang unbescholtener neuer Ordner ?

Also nisten wir uns mit den 6 Dateien im Ordner "kid1" ein.
Was bei Autoschiebern gängige Praxis ist muss sich bewährt haben - also folgen wir diesem Beispiel.
Wir erreichen dadurch das unsere neue "Festplatte" nicht als REDO-log erkannt wird.
Da wir im Moment keine Autos verschieben muessen wir nicht in einer Hinterhofwerkstatt mit Lackierkabine Nitroverduennung einatmen sondern nehmen einfach Explorer oder Konqueror und benennen unsere Beute einfach um.
In einem Abwasch erstellen wir auch noch einen neuen Gast - entspricht in etwa der Faelschung neuer KFZ-papiere.

Dann sieht kid1 etwa so aus:




Jetzt fehlt nur noch die Fahrgestellnummer - was in unserem Fall der Descriptorfile entspricht.

Dieser Schritt ist der wichtigste der ganzen Aktion.
Das Kind muss natuerlich wissen wo sich das Basis-image befindet.

Bei einer normalen *vmdk zeigt dieser Hint (Hinweis) auf sich selbst. Im Betrieb der VM wird diese Angabe von den REDOs ausgewertet.
Bei einer 'Monolithic Sparse Disk' muesste man fuer diesen kleinen Editiervorgang ein Hexeditor verwenden und muesste peinlich genau darauf achten bei dem Editiervorgang die Struktur nicht zu beschaedigen.

Als VMX fuer das Kind nehmen wir entweder eine Kopie der basedisk.vmx bei der dann einige Eintraege angepasst werden muessen - oder erstellen mit dem Wizzard eine ganz neue.
displayName = "kid1" - natuerlich bekommt das Kind einen neuen Namen

Alle uuid und MAC Eintraege werden geloescht - beim ersten Start werden diese Angaben automatisch neu erzeugt - um Duplikate zu vermeiden ist das auch genau das, was wir wollen.

Achtung: falls irgendwelche Eintraege dieser Art vorhanden sind:
*.redo keys
checkpoint.* keys
undopoint.* keys --------- Das sind Altlasten - damit koennen wir uns nicht belasten : also - weg damit.

Von diesem Muster kann man jetzt beliebig Kopien machen und diese auch alle gleichzeitig laufen lassen!
Am besten legt man sich ein Muster davon an die Seite und nimmt eine frische Kopie davon wenn man ein neues Kind haben will.

Das erste Kind in Aktion ...

Dieses Kind laeuft mit persistent mode

Das zweite Kind in Aktion ...

Dieses Kind hat gerade selber einen Snapshot gemacht und laeuft in undoable mode

Während dessen in 'basedisk' ...

Zur Sicherheit sollte man in diesem Ordner vielleicht alles bis auf die Festplatte loeschen - sonst koennte man vielleicht einmal auf die Idee kommen und die urspruengliche Maschine starten - was dazu fuehren wuerde das alle Kinder unbrauchbar werden.

ACHTUNG

Ganz wichtig: Die urspruegliche basedisk.vmdk sollte man unbedingt auf ReadOnly stellen - das geht am sichersten durch Setzen von Datei-attributen.
Vergisst man diesen Schritt und drueckt bei einem der Kinder auf den Snapshot-button werden auf einen Schlag alle Kinder unbrauchbar.

Ich konnte auf meinem Rechner etwa 4 Kinder starten und diese unabhaengig voneinander laufen lassen.