Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Understanding virtual machine snapshots within Virtual Volumes (vVols) (51544)

Last Updated: 1/15/2022Categories: InformationalTotal Views: 9497Language:
English

21 like this article

Subscribe to get an email
newsletter with new updates

21 people found this helpful Please provide article feedback:

Purpose

The purpose of this article is to explain how virtual machine snapshots behave in virtual machines that are stored on a VMware Virtual Volume (vVols).

vVols constitutes five major components namely vVols Device, Protocol End Point, Storage Container, VASA Provider and Array and all these components are managed/used/handled by different components in vSphere Stack such as Virtual Center (VASA, SPBM), ESXi (Hostd, VVOLD, VVOL FDS Driver). It becomes necessary to get a holistic view of environment and configuration.

Characteristics of vVols:

No File System.

ESXi manages the array through VASA (vSphere APIs for Storage Awareness) APIs.

Arrays are logically partitioned into containers, called Storage Containers.

Virtual machine disks, called vVols, stored natively on the Storage Containers.

IO from ESXi host to the storage array is addressed through an access point called, Protocol Endpoint (PE).

Data Services are offloaded to the array. Snapshot, Replication, Encryption.

Managed through storage policy-based management (SPBM) framework.

The normal snapshot mechanism for virtual machines which reside on VMFS volumes, relies on a redo log format snapshot. For more information about this type of snapshot, see:

Understanding virtual machine snapshots in VMware ESXi and ESX (1015180)

Best practices for virtual machine snapshots in the VMware environment (1025279)

Snapshot on VMFS Datastore

Snapshot on vVols

When a snapshot of a virtual machine residing on a VMFS datastore is taken a child delta disk is created, the parent disk is the base virtual disk (VMDK).

When virtual machines are stored on a Virtual Volume (vVols), the first thing to remember is that with a virtual machine on snapshot is always running from the base VMDK disk.

The parent disk is considered a point-in-time (PIT) copy. When the snapshot is created the virtual machine now runs from the snapshot virtual disk (delta VMDK).

When a snapshot is taken, virtual machine no longer has its running point on a snapshot delta as it is pointed to base disk as mentioned above.

Base disk remains Read only as the Reads and Writes happen on the snapshot disk (delta disk).

Base disk remains RW for snapshot on vVols.

All new writes to the virtual machine's disks are recorded in the delta VMDK, disk read operations are served by the base VMDK and any data written since the snapshot creation is read from the delta VMDK disk(s).

The delta VMDK is responsible for maintaining a point-in-time (PIT) copy of the data which means that when the virtual machine sends I/O to the base VMDK disk, the delta VMDK is responsible for tracking the original data block.

Snapshots can negatively affect the performance of a virtual machine. Performance degradation is based on how long the snapshot or snapshot tree is in place, the depth of the tree, and how much the virtual machine and its guest operating system have changed from the time you took the snapshot.
Amount of time VM takes to power on will depend on the hierarchy of snapshot chain along with the size of Delta/sesparse.

With VVols, when you choose take snapshot of VM, VMware does not have any performance-impact while creating delta VMDK files that were traditionally used, but instead VMware entirely offloads this process to the array.

If a virtual machine has virtual hard disks larger than 2 TB, snapshot operations can take much longer to finish.

The snapshots are handled by the array and the copy-on-write (COW) operations that are needed to maintain the snapshot.

As a result, the I/O from the VM to the disk does not have the performance penalty because the VM is running on an active snapshot.

This diagram illustrates a virtual machine residing on a VMFS datastore, and what the snapshot structure looks like when the first and second snapshots are created.

This diagram illustrates a virtual machine residing on a vVols datastore, and what the snapshot structure looks like when the first and second snapshots are created.

Resolution

A virtual machine disk descriptor file on a Virtual Volume (vVols) no longer points to a flat VMDK file, it references a vVols object location.

This is an example of a virtual machine disk (VMDK) descriptor file before a snapshot is taken:

[root@ESXi60] cat testVM.vmdk

# Disk DescriptorFile
version=4
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"

# Extent description
RW 4194304 VMFS "vvol://1b38adb34b7f45f8-9abcb8e9eadba042/rfc4122.0a0a1e74-d7c4-4217-a49e-06281db2cffa"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "261"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "847f9654f70db75004bc90fbfffffffe"
ddb.uuid = "60 00 C2 91 c4 12 18 3b-5b 5c 70 bb 92 f6 9a e3"
ddb.virtualHWVersion = "11"

When the virtual machine snapshot is taken, the I/O is still directed to the base vVols object while the delta records the point-in-time (PIT) copy of the data. To achieve this, a new parameter called ddb.objectParentUri is added to the VMDK descriptor file on creation of the first snapshot. This line is the address of the base vVols object. The new string in the Extent description is the address of the snapshot file.

Descriptor file after snapshot:

[root@ESXi60] cat testVM.vmdk
# Disk DescriptorFile
version=4
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"

# Extent description
RW 4194304 VMFS "vvol://1b38adb34b7f45f8-9abcb8e9eadba042/rfc4122.c74ae2ab-c908-407c-b629-cf7495cd98d5"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "261"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "847f9654f70db75004bc90fbfffffffe"
ddb.nativeDeltaBytes = "2147483648"
ddb.objectParentUri = "vvol://1b38adb34b7f45f8-9abcb8e9eadba042/rfc4122.0a0a1e74-d7c4-4217-a49e-06281db2cffa"
ddb.uuid = "60 00 C2 91 c4 12 18 3b-5b 5c 70 bb 92 f6 9a e3"
ddb.virtualHWVersion = "11"

Note: The virtual machine configuration file (.vmx) file still appears to point to the delta virtual disk.

[root@ESXi60]  grep -i scsi.*file *vmx
scsi0:0.fileName = "testVM-000001.vmdk"

On closer inspection, when you read the delta VMDK's descriptor file you will see that it references the ddb.objectParentUri of the base VMDK VVol object UUID. So, even though it appears to be running from the snapshot, the virtual machines is still running from the base VMDK disk. This is called re-parenting, also known as swizzling.

Whenever a snapshot is consolidated, the related snapshot file is discarded, the ddb.objectParentUri line is removed and the base descriptor file reverts to point to the original VVol UUID (the Extent description line returns to it's original value).

[root@ESXi60] cat testVM-000001.vmdk
# Disk DescriptorFile
version=4
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="yes"
createType="vmfs"

# Extent description
RW 4194304 VMFS "vvol://1b38adb34b7f45f8-9abcb8e9eadba042/rfc4122.0a0a1e74-d7c4-4217-a49e-06281db2cffa"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "261"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "847f9654f70db75004bc90fbfffffffe"
ddb.nativeParentCID = "fffffffe"
ddb.nativeParentHint = "testVM.vmdk"
ddb.uuid = "60 00 C2 91 c4 12 18 3b-5b 5c 70 bb 92 f6 9a e3"
ddb.virtualHWVersion = "11"

Note: The delta VMDK descriptor also contains a new ParentCID and ParentHint parameter, you will notice that every vVols 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.

ddb.nativeParentCID = "fffffffe"
ddb.nativeParentHint = "testVM.vmdk"

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
Download and Install VMware Fusion (2014097)

KB
•
通过 PCoIP 连接到 VDI 桌面时显示黑屏并在 10 秒后断开连接 (1016633)

KB
•
VMware Horizon View Administrator ダッシュボードの反応が遅い (2131155)

Results 1-4 of 4

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSphere ESXi

Related Versions:

VMware vSphere ESXi 7.0.0

VMware vSphere ESXi 6.7

VMware vSphere ESXi 6.5

VMware vSphere ESXi 6.0

Take Our Survey

Support Assistant