Lets start with a look at the NFS based VM’s home folder without any snapshots:
# ls -ltr total 13546974 -rw------- 1 root root 0 Mar 19 12:12 win8-on-nfs.vmx.lck -rw------- 1 root root 2147483648 Mar 19 12:12 win8-on-nfs-yy.vswp -rw------- 1 root root 178257920 Mar 19 12:12 vmx-win8-on-nfs-xx-1.vswp -rw------- 1 root root 550 Mar 19 12:17 win8-on-nfs_1.vmdk -rwxr-xr-x 1 root root 3022 Mar 19 12:17 win8-on-nfs.vmx -rw-r--r-- 1 root root 43 Mar 19 12:17 win8-on-nfs.vmsd -rw------- 1 root root 8684 Mar 19 12:17 win8-on-nfs.nvram -rw-r--r-- 1 root root 236925 Mar 19 12:17 vmware.log -rw------- 1 root root 25769803776 Mar 19 12:18 win8-on-nfs_1-flat.vmdk
Compare this to the VM deployed on a VVol datastore:
# ls -ltr total 376 drwxr-xr-x 2 root root 8192 Mar 18 16:39 lost+found -rw------- 1 root root 0 Mar 18 16:45 win8-on-vvol.vmx.lck -rw------- 1 root root 0 Mar 18 16:45 win8-on-vvol-37d84e31.vswp.lck -rw------- 1 root root 178257920 Mar 18 16:45 vmx-win8-on-vvol-xx-1.vswp -rw------- 1 root root 309 Mar 18 16:45 win8-on-vvol-yy.vswp -rw------- 1 root root 666 Mar 19 11:36 win8-on-vvol_1.vmdk -rwxr-xr-x 1 root root 3083 Mar 19 11:36 win8-on-vvol.vmx -rw-r--r-- 1 root root 43 Mar 19 11:36 win8-on-vvol.vmsd -rw-r--r-- 1 root root 273232 Mar 19 11:36 vmware.log -rw------- 1 root root 8684 Mar 19 11:36 win8-on-vvol.nvram
Really, the only major differences are the fact that the NFS based VM has the very large flat file, whereas the VVol based VM has a VVol object which is not visible in the listing. Let’s now go ahead and take some snapshots of the NFS based VM, and remind ourselves of how things traditionally worked.
Traditional snapshot functionality – VM on NFS
Initially, the VM is running on the base disk as shown here:
# grep vmdk *.vmx scsi0:0.fileName = "win8-on-nfs_1.vmdk"
# cat win8-on-nfs_1.vmdk # Disk DescriptorFile version=1 encoding="UTF-8" CID=3a1e7b0a parentCID=ffffffff isNativeSnapshot="no" createType="vmfs" # Extent description RW 50331648 VMFS "win8-on-nfs_1-flat.vmdk" <<--truncated-->>
What is interesting to note here is the CID (Content ID) of 3a1e7b0a and the extent description which points to the flat file win8-on-nfs_1-flat.vmdk.
Snapshot of NFS based VM – no quiesce, no memory
At this point, we will proceed with taking the first snapshot. There is no memory captured with this snapshot, nor do we attempt to quiesce the guest OS, filesystem or applications. The snapshot descriptor file now contains the following entries:
# cat win8-on-nfs.vmsd .encoding = "UTF-8" snapshot.lastUID = "2" snapshot.current = "2" snapshot0.uid = "2" snapshot0.filename = "win8-on-nfs-Snapshot2.vmsn" snapshot0.displayName = "snap1" snapshot0.createTimeHigh = "332195" snapshot0.createTimeLow = "901932146" snapshot0.numDisks = "1" snapshot0.disk0.fileName = "win8-on-nfs_1.vmdk" snapshot0.disk0.node = "scsi0:0" snapshot.numSnapshots = "1"
There is a single snapshot taken of the base disk of this VM. Lets now look at the NFS based VM’s home folder with a new snapshot:
# ls -ltr total 13547098 -rw------- 1 root root 0 Mar 19 12:12 win8-on-nfs.vmx.lck -rw------- 1 root root 2147483648 Mar 19 12:12 win8-on-nfs-xx.vswp -rw------- 1 root root 178257920 Mar 19 12:12 vmx-win8-on-nfs-yy-1.vswp -rw------- 1 root root 550 Mar 19 12:17 win8-on-nfs_1.vmdk -rw-r--r-- 1 root root 244153 Mar 19 12:18 vmware.log -rw------- 1 root root 25769803776 Mar 19 12:20 win8-on-nfs_1-flat.vmdk -rwxr-xr-x 1 root root 3029 Mar 19 12:20 win8-on-nfs.vmx -rw-r--r-- 1 root root 376 Mar 19 12:20 win8-on-nfs.vmsd -rw------- 1 root root 8684 Mar 19 12:20 win8-on-nfs.nvram -rw------- 1 root root 20051 Mar 19 12:20 win8-on-nfs-Snapshot2.vmsn -rw------- 1 root root 329 Mar 19 12:20 win8-on-nfs_1-000001.vmdk -rw------- 1 root root 16830464 Mar 19 12:20 win8-on-nfs_1-000001-delta.vmdk
At the end of the list, there is a new delta representing the snapshot, and just above it there is the associated descriptor file. Lets check which VMDK this VM is now running from:
# grep vmdk *.vmx scsi0:0.fileName = "win8-on-nfs_1-000001.vmdk"
The VM is now running on the snapshot delta. If we display the descriptor file for the delta, we see the following:
# cat win8-on-nfs_1-000001.vmdk # Disk DescriptorFile version=1 encoding="UTF-8" CID=cade0f91 parentCID=3a1e7b0a isNativeSnapshot="no" createType="vmfsSparse" parentFileNameHint="win8-on-nfs_1.vmdk" # Extent description RW 50331648 VMFSSPARSE "win8-on-nfs_1-000001-delta.vmdk" # The Disk Data Base #DDB ddb.longContentID = "76e3a7bf80a4d4175bdec1eecade0f91"
A few interesting things to note from the above output:
- The parentCID is the CID of the base disk
- The format is VMFSSPARSE, also known as the redo log format
- The extent descriptions shows this is indeed the descriptor for the snapshot delta
Traditional VM Snapshot Conclusion
Initially this NFS based VM was running off of base disk win8-on-nfs_1-flat.vmdk. A snapshot is taken. The .vmx file now references new snapshot -00001.vmdk. The descriptor file for this snapshot now references VMFSSPARSE -000001-delta.vmdk. This implies that the VM now runs from the new redo log disk. The snapshot chain is now snap1 delta -> base disk.
Let’s now turn our attention to the VVol based VM.
New Snapshot Functionality – VM on VVol
Initially, the VVol based VM is running on the virtual volume as shown here:
# grep vmdk win8-on-vvol.vmx scsi0:0.fileName = "win8-on-vvol_1.vmdk"
Next, let’s examine that descriptor file for that VVol.
# cat win8-on-vvol_1.vmdk # Disk DescriptorFile version=4 encoding="UTF-8" CID=d0f9a0d7 parentCID=ffffffff isNativeSnapshot="yes" createType="vmfs" # Extent description RW 50331648 VMFS "vvol://b66d7f4a83854914-8d72065ca1c700b6/\ rfc4122.1731611c-02ff-46c0-aec3-435425dcd184" <<--truncated-->>
The identifier in the extent description is a combination of the container ID and the VVol UUID. Let’s make a note of the second to last field of the VVol identifier: aec3.
Snapshot of VVol based VM – no quiesce, no memory
We will proceed the same as before, taking the first snapshot with no memory. We do not attempt to quiesce the guest OS, filesystem or applications. The snapshot descriptor file now contains the following entries:
# cat win8-on-vvol.vmsd .encoding = "UTF-8" snapshot.lastUID = "2" snapshot.current = "2" snapshot0.uid = "2" snapshot0.filename = "win8-on-vvol-Snapshot2.vmsn" snapshot0.displayName = "snap1" snapshot0.createTimeHigh = "332194" snapshot0.createTimeLow = "-1580666015" snapshot0.numDisks = "1" snapshot0.disk0.fileName = "win8-on-vvol_1.vmdk" snapshot0.disk0.node = "scsi0:0" snapshot.numSnapshots = "1"
And if we check where the VM is running, it states that it is running off of the disk represented by this descriptor file.
# grep vmdk win8-on-vvol.vmx scsi0:0.fileName = "win8-on-vvol_1-000001.vmdk"
It would appear that the VM is now running on the snapshot, but lets look at the snapshot descriptor. Notice anything?
# cat win8-on-vvol_1-000001.vmdk # Disk DescriptorFile version=4 encoding="UTF-8" CID=d0f9a0d7 parentCID=ffffffff isNativeSnapshot="yes" createType="vmfs" # Extent description RW 50331648 VMFS "vvol://b66d7f4a83854914-8d72065ca1c700b6/ \ rfc4122.1731611c-02ff-46c0-aec3-435425dcd184" <<--truncated-->>
Now, pay close attention to the VVol identifier in the Extent Description. Does it look familiar? Yes, it is the VVol identifier for the base disk – aec3 – noted earlier. So even though we appear to be running off of the snapshot, we are in fact continuing to run off of the base disk. This is what is referred to as re-parenting. Another term I’ve heard is descriptor swizzling. Whichever term is used, this mechanism allows VVol snapshots to continue to run on the base disk, bringing with it the advantages highlighted in my previous post. Hopefully you get the idea of how we can run with both the new “undo log” format of VVol snapshots in vSphere 6.0 as well as continuing to support the traditional “redo log” format of traditional snapshots, and still facilitate their management from vSphere.
New VVol snapshot Conclusion
When we started, this VM was running off of a VVol base disk with identifier aec3. Next we took a snapshot. The .vmx file now references a new snapshot -00001.vmdk. However the descriptor file for this snapshot references the original VVol base disk aec3. This implies that the VM continues to run from base disk VVol.
One other thing that you will notice is that every VVol snapshot is a “child” of the base disk. This is because every snapshot is a point-in-time representation of the base disk. As such every snapshot will reference back to the base disk.