In VMDK terminology, all the following are synonyms: child disk, redo log, and delta link. From the original parent disk, each child constitutes a redo log pointing back from the present state of the virtual disk, one step at a time, to the original. This pseudo equation represents the relative complexity of backups and snapshots:
A backup image (such as on magnetic tape) is less than a child disk because the backup image is merely a data stream. A snapshot is more than a child disk because it also contains the virtual machine state, with pointers to associated file system states on VMDK.
Generally, you create the first child from the parent and create successive children from the latest one in the chain. The child VMDK tracks, in SPARSE type format, any disk sectors changed since inception, as illustrated in Child Disks Created from Parent.
VixDiskLib_CreateChild() creates a child disk (or redo log) for a hosted virtual disk:
vixError = VixDiskLib_CreateChild(parent.Handle(), appGlobals.diskPath, VIXDISKLIB_DISK_MONOLITHIC_SPARSE, NULL, NULL);
After you create a child, it is an error to open the parent, or earlier children in the disk chain. In VMware products, the children’s vm.vmdk files point to redo logs, rather than to the parent disk, vm-flat.vmdk in this example. If you must access the original parent, or earlier children in the chain, use VixDiskLib_Attach().
VixDiskLib_Attach() attaches the child disk into its parent disk chain. Afterwards, the parent handle is invalid and the child handle represents the combined disk chain of redo logs.
For example, suppose you want to access the older disk image recorded by Child1. Attach the handle of new Child1a to Child1, which provides Child1a’s parent handle, as shown in Child Disks Created from Parent. It is now permissible to open, read, and write the Child1a virtual disk.
The parent-child disk chain is efficient in terms of storage space, because the child VMDK records only the sectors that changed since the last VixDiskLib_CreateChild(). The parent-child disk chain also provides a redo mechanism, permitting programmatic access to any generation with VixDiskLib_Attach().
With (parent) base disk B and children C0, C1, and C2, opening C2 gives you the contents of B + C0 + C1 + C2 (not really addition linked data sectors), while opening C1 gives you the contents of B + C0 + C1.
A better solution than recording base disks and which children are descended from which is changed block tracking, QueryChangedDiskAreas in the vSphere API. See Algorithm for vSphere Backup.