Home > Storage > PowerStore > Virtualization and Cloud > Dell PowerStore: Virtualization Integration > Virtual Volumes
The type of vVol provisioned depends on the type of data that is being stored:
At a minimum, three vVols are required for each powered-on VM: data for the hard disk, config for the configuration, and swap for the memory pages.
The Virtual Volumes card provides details about the vVols used for the VM. PowerStore uses the VASA protocol to communicate with vSphere to create, bind, unbind, and delete vVols automatically, as needed. Manual management of these vVols is not required. This page also provides options to migrate vVols, manage the Watchlist, and collect support materials.
Information such as the vVol name, type, capacity, storage container, appliance, and I/O priority are displayed, as shown in the following figure:
In PowerStoreOS 1.0, vVols can be migrated between appliances within the cluster. However, it is limited to vVols that are not in use so the virtual machine must be powered off before any of its vVols can be migrated. Starting with PowerStoreOS 2.0, online vVol migration is supported. This functionality allows vVols that are used for powered-on virtual machines to be migrated between appliances within the cluster.
In order to support online vVol migration, the ESXi host must be running VMware ESXi 6.7 P02 or higher. Previous versions of VMware ESXi do not support online vVol migration as this functionality requires ESXi vVol rebind orchestration. In this scenario, the vVol must be unbound manually by powering off the virtual machine or the ESXi host must be upgraded to the appropriate version.
The online migration operation is transparent to the virtual machine and no rescans are required. Like volume migrations, both manual and assisted migrations are available for vVols. The migration traffic flows over the first two ports of the four-port card using the Intra-Cluster Management (ICD) and Intra-Cluster Data (ICD) IPv6 networks.
It is possible to have multiple vVols for a single virtual machine spread across multiple appliances. The best practice recommendation is to have all vVols for a virtual machine on the same appliance. Online vVol migration can be used as a nondisruptive method to consolidate a virtual machine’s vVols onto a single appliance.
vVol migrations can be initiated from the VM Details > Virtual Volumes or Storage Container Details > Virtual Volumes pages. The following figure shows the migrate operation:
Here is the workflow for an online vVol migration:
For more information about manual and assisted migrations, see the document Dell PowerStore: Clustering and High Availability.
To enable optimal virtualization performance, accounting for a virtual machine’s storage placement is important. This section provides placement recommendations when using vVol storage.
For optimal performance, keep all vVols for a VM together on a single appliance. When provisioning a new VM, PowerStore groups all its vVols onto the same appliance. In a multi-appliance cluster, the appliance that has the highest amount of free capacity is selected. This selection is maintained even if the provisioning results in a capacity imbalance between appliances afterward. If all vVols for a VM cannot fit on a single appliance due to space, system limits, or health issues, the remaining vVols are provisioned onto the appliance with the next-highest amount of free capacity.
When provisioning a VM from a template or cloning an existing VM, PowerStore places the new vVols onto the same appliance as the source template or VM. This action enables the new VM to take advantage of data reduction to increase storage efficiency. For VM templates that are frequently deployed, it is recommended to create one template per appliance and evenly distribute VMs between appliances by selecting the appropriate template.
When taking a snapshot of an existing VM, new vVols are created to store the snapshot data. These new vVols are stored on the same appliance as the source vVols. In situations where the source vVols are spread across multiple appliances, the vVols created by the snapshot operation also become spread. vVol migrations can be used to consolidate a VM’s vVols onto the same appliance.
Each vVol has an attribute that is designated by PowerStore’s Resource Balancer called node affinity. The node affinity specifies the preferred path to the vVol, either through Node A or Node B. Paths on one node are designated as active/optimized while the paths on the other node are designated as active/non-optimized. Because both nodes on PowerStore are active and have full access to the vVol, the non-optimized paths can continue servicing IO if all optimized paths become unavailable. The architecture enables both load balancing and high availability.
In PowerStoreOS 4.0, dynamic node affinity is available for vVols. This provides Resource Balancer the ability to dynamically change a vVol’s node affinity based on performance metrics. This allows the appliance to maintain relatively consistent utilization, latency, and performance across both nodes. This has several benefits including balancing hardware utilization, optimizing performance, and providing the ability to adapt as workloads change.
This feature is designed to be completely transparent to the administrator and clients. The system makes changes automatically and intelligently as needed. It is enabled automatically after upgrading to PowerStoreOS 4.0 or later. It does not require any user intervention and is non-disruptive to clients.
Performance metrics are collected every five minutes and the rebalance operation happens every 30 minutes. For a rebalance to be initiated, the following criteria must be met:
If these checks pass, PowerStore attempts to first migrate volumes to achieve balance. If no further balancing can be done on volumes and there is still an imbalance, vVol node affinity can be changed in the next cycle. One vVol can be changed per cycle. Resource Balancer aims to achieve an even balance between the two nodes based on the throughput and bandwidth workload, regardless of the resource type.
When a vVol rebalance is initiated, PowerStore coordinates with all of the ESXi hosts to update the peer protocol endpoint to be the active/optimized path. When complete, this results in ESXi directing IO to the protocol endpoint on the peer node. ESXi automatically quiesces IOs until the pathing update is complete.
Data and config vVols are eligible for balancing. Data vVols store data, such as VM hard disks, snapshots, full clones, and fast clones and generally have the most IO. Config vVols store standard VM configuration data, such as .vmx files, logs, and NVRAM.
Some vVols are excluded from balancing. vVols that are unbound are not in use, such as a powered-off VM, so these are excluded from balancing. Also, vVols that have a migration in progress or were recently moved are excluded to avoid interference with ongoing migrations or moving resources back too quickly.