More Virtual Volumes (VVOLS) and Snapshots Goodness

By Carina Burk|April 20th, 2017

More Virtual Volumes (VVOLS) and Snapshots Goodness

Cormac Hogan posted a very interesting article about Virtual Volumes, you can find the complete article here or scroll down.

Well, 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:

Virtual Volumes

Photo courtesy of Cormac Hogan

Compare this to the VM deployed on a VVol datastore:

Virtual Volumes

Photo courtesy of Cormac Hogan

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:

Virtual Volumes

Photo courtesy of Cormac Hogan

Next, let’s examine that descriptor file for that VMDK.

Virtual Volumes

Photo courtesy of Cormac Hogan

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:

Virtual Volumes

Photo courtesy of Cormac Hogan

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:

Virtual Volumes

Photo courtesy of Cormac Hogan

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:

Virtual Volumes

Photo courtesy of Cormac Hogan

The VM is now running off of the snapshot delta. If we display the descriptor file for the delta, we see the following:

Virtual Volumes

Photo courtesy of Cormac Hogan

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 know 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:

Virtual Volumes

Photo courtesy of Cormac Hogan

Next, let’s examine that descriptor file for that VVol.

Virtual Volumes

Photo courtesy of Cormac Hogan

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  nor do we attempt to quiesce the guest OS, filesystem or applications. The snapshot descriptor file now contains the following entries:

Virtual Volumes

Photo courtesy of Cormac Hogan

And if we check where the VM is running, it states that it is running off of the disk represented by this descriptor file.

Virtual Volumes

Photo courtesy of Cormac Hogan

It would appear that we are running off of the snapshot, but lets look at the snapshot descriptor. Notice anything?

Virtual Volumes

Photo courtesy of Cormac Hogan

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, this mechanism allows VVol snapshots to continue to run off of 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.

WOW! Thank you Cormac for this posting!

Sign up for Performance Analyzer today and start 30 days for free.

Related Posts

Log in

Forgot your password?
Don’t have an account? Register.