Virtual volumes are encapsulations of virtual machine files, virtual disks, and their derivatives.
Virtual volumes are stored natively inside a storage system that is connected to your ESXi hosts through Ethernet or SAN. They are exported as objects by a compliant storage system and are managed entirely by hardware on the storage side. Typically, a unique GUID identifies a virtual volume. Virtual volumes are not preprovisioned, but created automatically when you perform virtual machine management operations. These operations include a VM creation, cloning, and snapshotting. ESXi and vCenter Server associate one or more virtual volumes to a virtual machine.
Types of Virtual Volumes
- A data virtual volume that corresponds directly to each virtual disk .vmdk file. As virtual disk files on traditional datastores, virtual volumes are presented to virtual machines as SCSI disks. Data-vVol can be either thick or thin-provisioned.
A configuration virtual volume, or a home directory, represents a small directory that contains metadata files for a virtual machine. The files include a
.vmx file, descriptor files for virtual disks, log files, and so forth. The configuration virtual volume is formatted with a file system. When
ESXi uses the SCSI protocol to connect to storage, configuration virtual volumes are formatted with VMFS. With NFS protocol, configuration virtual volumes are presented as an NFS directory. Typically, it is thin-provisioned.
Note: Starting with vSphere 7.0 Update 2, partners can increase the config-vVol to above 4 GB. Work with your Virtual Volumes partner on implementing this if it is supported by your partner and applicable to your environment.
- Created when a VM is first powered on. It is a virtual volume to hold copies of VM memory pages that cannot be retained in memory. Its size is determined by the VM’s memory size. It is thick-provisioned by default.
- A virtual memory volume to hold the contents of virtual machine memory for a snapshot. Thick-provisioned.
- A virtual volume for specific features. For example, a digest virtual volume is created for Content-Based Read Cache (CBRC).
Typically, a VM creates a minimum of three virtual volumes, data-vVol, config-vVol, and swap-vVol. The maximum depends on how many virtual disks and snapshots reside on the VM.
For example, the following SQL server has six virtual volumes:
- Data-vVol for the operating system
- Data-vVol for the database
- Data-vVol for the log
- Swap-vVol when powered on
By using different virtual volumes for different VM components, you can apply and manipulate storage policies at the finest granularity level. For example, a virtual volume that contains a virtual disk can have a richer set of services than the virtual volume for the VM boot disk. Similarly, a snapshot virtual volume can use a different storage tier compared to a current virtual volume.
The Virtual Volumes functionality supports a concept of thin and thick-provisioned virtual disks. However, from the I/O prospective, implementation and management of thin or thick provisioning by the arrays is transparent to the ESXi host. ESXi offloads to the storage arrays any functions related to thin provisioning. In the data path, ESXi does not treat the thin or thick virtual volumes differently.
You select the thin or thick type for your virtual disk at the VM creation time. If your disk is thin and resides on a Virtual Volumes datastore, you cannot change its type later by inflating the disk.
You can place a shared disk on a Virtual Volumes storage that supports SCSI Persistent Reservations for Virtual Volumes. You can use this disk as a quorum disk and eliminate RDMs in the MSCS clusters. For more information, see the vSphere Resource Management documentation.