More Virtual Volumes (VVols) and Snapshots goodness
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:
# 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.
Great Blog! Thank you it is very helpful…
This is what is referred to as re-parenting.Does it means that the “snapshot” vvol gain the UUID of based VVOL disk (and hence base VVOL disk has different UUID?)
Hi Cormac,
Not sure if you have covered it yet, but does SRM support VVOLs?
I would assume that “Full integration with vSphere 6.0” means yes, but the release notes state:
NEW vSphere Replication 6.0 supports replication of virtual machines on Virtual Volumes (vVols) with limitations. Site Recovery Manager 6.0 does not support the protection of virtual machines on Virtual Volumes, even if you use vSphere Replication as the replication technology for protection.
My interpretation of this is that SRM 6.0 does not support VVOLs – if not do you know when it will.
Also is there anything else that does not support VVOLs or from an application point of view are they unaware that the storage system is using VVOLs?
Many thanks as always
Mark
The release notes are correct Mark. What we have is:
VR + VVOL = supported
SRM + VR + VVOL = not supported
Array based replication is also not supported with VVols in this initial release, so SRM support is moot in this case.
As from an application point of view, I’m not aware of any interop issues. However there is a VVol interop KB in the works which should be published any day now.
Hi Cormac,
I know I have asked this before, but are there any dependencies for VVOLs on VAAI?
Off-loading cloning, snapshots, etc are all functions of VAAI, but I assume these are included as standard with the VVOLs license.
As we said before VVOLs is included with vSphere Standard, but VAAI comes with Enterprise.
If my understanding is correct VVOLs is a super-set of VAAI and therefore as customers move to VVOLs, VAAI will become obsolete.
Or have I got this wrong as it is a little confusing.
Many thanks
Mark
VVols is more of a dependency on VASA rather than VAAI Mark.
If you look at this post on migrations – http://cormachogan.com/2015/02/27/migrations-and-virtual-volumes-deep-dive/ – you’ll see that first we try VASA primitives. If these don’t work, we try VAAI primitives and if they don’t work we’ll fall back to traditional methods.
However I don’t know what impact licensing has on this – one assumes that if you do not have a license for VAAI, you won’t offload if the VASA primitives are not supported. Let me check further.