Observe the following recommendations when you use Virtual Volumes with ESXi and vCenter Server.
Guidelines and Limitations when Using Virtual Volumes
For the best experience with Virtual Volumes functionality, you must follow specific guidelines.
Virtual Volumes supports the following capabilities, features, and VMware products:
- With Virtual Volumes, you can use advanced storage services that include replication, encryption, deduplication, and compression on individual virtual disks. Contact your storage vendor for information about services they support with Virtual Volumes.
- Virtual Volumes functionality supports backup software that uses vSphere APIs - Data Protection. Virtual volumes are modeled on virtual disks. Backup products that use vSphere APIs - Data Protection are as fully supported on virtual volumes as they are on VMDK files on a LUN. Snapshots that the backup software creates using vSphere APIs - Data Protection look as non-vVols snapshots to vSphere and the backup software.
Note: Virtual Volumes do not support SAN transport mode. vSphere APIs - Data Protection automatically selects an alternative data transfer method.
For more information about integration with the vSphere Storage APIs - Data Protection, consult your backup software vendor.
- Virtual Volumes supports vSphere features such as vSphere vMotion, Storage vMotion, snapshots, linked clones, and DRS.
- You can use clustering products, such as Oracle Real Application Clusters, with Virtual Volumes. To use these products, you activate the multiwrite setting for a virtual disk stored on the Virtual Volumes datastore.
For more details, see the knowledge base article at http://kb.vmware.com/kb/2112039. For a list of features and products that Virtual Volumes functionality supports, see VMware Product Interoperability Matrixes.
Virtual Volumes Limitations
- Because the Virtual Volumes environment requires vCenter Server, you cannot use Virtual Volumes with a standalone host.
- Virtual Volumes functionality does not support RDMs.
- A Virtual Volumes storage container cannot span multiple physical arrays. Some vendors present multiple physical arrays as a single array. In such cases, you still technically use one logical array.
- Host profiles that contain Virtual Volumes datastores are vCenter Server specific. After you extract this type of host profile, you can attach it only to hosts and clusters managed by the same vCenter Server as the reference host. For more information, see Configuration Maximums document.
Virtual Volumes Limitations with NVMe
- Replication and Site Recovery Manager operations.
- NVMe reservations.
- NVMe deallocate and unmap operations.
- Disk sharing across VMs.
- NVMe in-band migration.
Best Practices for Storage Container Provisioning
Follow these best practices when provisioning storage containers on the Virtual Volumes array side.
Creating Containers Based on Your Limits
Because storage containers apply logical limits when grouping virtual volumes, the container must match the boundaries that you want to apply.
- Organizations or departments, for example, Human Resources and Finance
- Groups or projects, for example, Team A and Red Team
- Customers
Putting All Storage Capabilities in a Single Container
Storage containers are individual datastores. A single storage container can export multiple storage capability profiles. As a result, virtual machines with diverse needs and different storage policy settings can be a part of the same storage container.
Changing storage profiles must be an array-side operation, not a storage migration to another container.
Avoiding Over-Provisioning Your Storage Containers
When you provision a storage container, the space limits that you apply as part of the container configuration are only logical limits. Do not provision the container larger than necessary for the anticipated use. If you later increase the size of the container, you do not need to reformat or repartition it.
Using Storage-Specific Management UI to Provision Protocol Endpoints
Every storage container needs protocol endpoints (PEs) that are accessible to ESXi hosts.
When you use block storage, the PE represents a proxy LUN defined by a T10-based LUN WWN. For NFS storage, the PE is a mount point, such as an IP address or DNS name, and a share name. For NVMe storage, the PE is an ANA group and proxy namespaces are virtual.
Typically, configuration of PEs is array-specific. When you configure PEs, you might need to associate them with specific storage processors, or with certain hosts. To avoid errors when creating PEs, do not configure them manually. Instead, when possible, use storage-specific management tools.
No Assignment of IDs Above Disk.MaxLUN to Protocol Endpoint LUNs
By default, an ESXi host can access LUN IDs that are within the range of 0 to 1023. If the ID of the protocol endpoint LUN that you configure is 1024 or greater, the host might ignore the PE.
If your environment uses LUN IDs that are greater than 1023, change the number of scanned LUNs through the Disk.MaxLUN parameter. See Change the Number of Scanned Storage Devices.
Best Practices for Virtual Volumes Performance
To ensure optimal Virtual Volumes performance results, follow these recommendations.
Using Different VM Storage Policies for Individual Virtual Volume Components
By default, all components of a virtual machine in the Virtual Volumes environment get a single VM storage policy. However, different components might have different performance characteristics, for example, a database virtual disk and a corresponding log virtual disk. Depending on performance requirements, you can assign different VM storage policies to individual virtual disks and to the VM home file, or config-vVol.
When you use the vSphere Client, you cannot change the VM storage policy assignment for swap-vVol, memory-vVol, or snapshot-vVol.
Getting a Host Profile with Virtual Volumes
The best way to get a host profile with Virtual Volumes is to configure a reference host and extract its profile. If you manually edit an existing host profile in the vSphere Client and attach the edited profile to a new host, you might trigger compliance errors. Other unpredictable problems might occur. For more details, see the VMware Knowledge Base article 2146394.
Monitoring I/O Load on Individual Protocol Endpoint
- All virtual volume I/O goes through protocol endpoints (PEs). Arrays select protocol endpoints from several PEs that are accessible to an ESXi host. Arrays can do load balancing and change the binding path that connects the virtual volume and the PE. See Binding and Unbinding Virtual Volumes.
- On block storage, ESXi gives a large queue depth to I/O because of a potentially high number of virtual volumes. The Scsi.ScsiVVolPESNRO parameter controls the number of I/O that can be queued for PEs. You can configure the parameter on the Advanced System Settings page of the vSphere Client.
Monitoring Array Limitations
A single VM might occupy multiple virtual volumes. See Virtual Volume Objects.
Suppose that your VM has two virtual disks, and you take two snapshots with memory. Your VM might occupy up to 10 Virtual Volumes objects: a config-vVol, a swap-vVol, two data-vVols, four snapshot-vVols, and two memory snapshot-vVols.
Ensuring that Storage Provider Is Available
- Do not migrate a storage provider VM to Virtual Volumes storage.
- Back up your storage provider VM.
- When appropriate, use vSphere HA or Site Recovery Manager to protect the storage provider VM.