Site icon CormacHogan.com

More Virtual Volumes (VVols) and Snapshots goodness

VVolsWell, I got so many questions about my previous articles on a new way of doing snapshots with VVols that I decided to take the time and get even deeper into their behaviour. In this setup, I take a Windows 2008 Guest OS running in a virtual machine  deployed on an NFS datastore, and I compare it to an identical VM deployed on a VVol datastore. This is purely from looking at how we do snapshots. Remember with VVols, snapshots always run on the base disk, compared to the traditional way of doing snapshots where the VM always run on the top-most delta in the chain.

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"
Next, let’s examine that descriptor file for that 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:

  1. The parentCID is the CID of the base disk
  2. The format is VMFSSPARSE, also known as the redo log format
  3. 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.

Exit mobile version