Create linked clones for VMplayer

 

Let's create some linked clones for VMplayer without the help of the Workstation-version.

Sorry - Linux-users - this is for Windows only.

All you need is Ken Katos vdk.exe and a text-editor (no text scrambler like Word).

 

Starting conditions:

Let's make it simple and assume we have a OpenBSD-VM called obsd.vmx - this VM uses one virtual SCSI-disk named 1gscsi.vmdk. In this example you will have 3 files in your VM-directory:

 

If you open the descriptorfile of the virtual disk (1gscsi.vmdk) in a texteditor it will look like

 

# Disk DescriptorFile
version=1
CID=e775e767
parentCID=ffffffff
createType="twoGbMaxExtentSparse"
# Extent description
RW 2097152 SPARSE "1gscsi-s001.vmdk" # The Disk Data Base
#DDB ddb.toolsVersion = "0"
ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "32"
ddb.geometry.heads = "128"
ddb.geometry.cylinders = "512"
ddb.virtualHWVersion = "4"

Creating a snapshot

 

Make sure that your VM is in a good and healthy state before you create the snapshot. (The VM must be powered down)
Now run Ken Katos vdk.exe like this:
vdk.exe open 0 1gscsi.vmdk /undo

Vdk.exe will complain about an unknown adapter-type - but will offer you a choice - enter S for SCSI.
Look at the output of vdk.exe:



If you get so far - everything is fine.
Look in the directory of your VM - you should see something like this:



In case you see the newly created REDO-log run

vdk close 0
To unmount the disk again.
Don't try to look at the disk with explorer - it's OpenBSD's filesystem and you will not be able to mount the disk in Windows anyway.

Have a look at the descriptorfile of the REDO-log:

# Disk DescriptorFile
version=1
CID=43cc166c
parentCID=e775e767
createType="twoGbMaxExtentSparse"
parentFileNameHint="1gscsi.vmdk"
# Extent description
RW 2097152 SPARSE "1gscsi.vmdk-s001.REDO"
# The Disk Data Base
#DDB

The REDO points to its parent-disk - which is in the same directory - so it uses a relative path.

 

Creating Clones:

 

 

From now on we will regard the original disk 1gscsi.vmdk as read-only. We want that several clones use this disk as basedisk. To make sure that we don't accidentaly use this disk directly again we will store it in a new directory called 'basedisk'
Let's assume we want to go on with 2 clones ...

Each clone needs a new dir and so we create 'clone1' and 'clone2' directories.

In each of this 2 directories we need a copy of the newly created REDO - log.
Usually I rename the REDO to something more friendly like clone1.vmdk and clone1-s001.vmdk.






The directory of the original VM now contains 3 new subdirs with files like listed above.

 

Editing vmx and vmdk ...

 

 

As you might have guessed we of course have to do some adjustments - as we had renamed the disks and changed paths and so on.
Clone1 now uses the virtual-disk clone1.vmdk

# Disk DescriptorFile
version=1
CID=43cc0ceb
parentCID=e775e767
createType="twoGbMaxExtentSparse"
parentFileNameHint="E:\obsd\basedisk\1gscsi.vmdk"
# Extent description
RW 2097152 SPARSE "clone1-s001.vmdk"
# The Disk Data Base
#DDB

Clone 2 now uses the virtual-disk clone2.vmdk

# Disk DescriptorFile
version=1
CID=43cc0ceb
parentCID=e775e767
createType="twoGbMaxExtentSparse"
parentFileNameHint="E:\obsd\basedisk\1gscsi.vmdk"
# Extent description
RW 2097152 SPARSE "clone2-s001.vmdk"
# The Disk Data Base
#DDB

The path for the basedisk has to be an absolut path now as a relative one will not work any longer.

Now there is only one thing left to do and that is pointing both vmx-files to their new disks.
Clone1.vmx points to clone1.vmdk and clone2.vmx points to clone2.vmdk - both times we can use relative paths.

Well - better be safe than sorry - set the directory of the basedisk to read-only via NTFS-permissions. If you ever touch this disk again directly - you will mess up your clones.


OK - that was 5 minutes work and from now on you can run two linked clones from one basedisk.