Correcting Persistent Myths About Virtual Volumes

by Chris Preimesberger

You need one VVOL for Config, one for Swap and one for each vDisk. That’s a minimum of three per VM. Then, for every snapshot you need one more VVOL for each vDisk and one Memory VVOL per snapshot. Bottom line: You might need hundreds of VVOLs for one VM.

In fact, the number of VVOLs a storage provider can support with 4U of rack space can vary from less than 2,000 to 1 million. Given the first myth (how quickly your VVOL count will grow), you should look for a vendor that can support a lot of VVOLs.

VVOLs aren’t products; they are an application programming interface (API). So, VVOL functionality is entirely dependent on your storage provider’s underlying structure and ability to implement VVOLs.

You have to upgrade to vSphere 6 (or later). You will probably need to upgrade the firmware on your array. Not all arrays are VVOL-ready, even in the same array family. Each array will implement VVOLs differently with different limitations.

Once the VVOL API places a VM, it is up to the array to provide quality of service (QoS) and other policies—and those are still enforced by the storage array at the storage container or volume/LUN level, not for each VM. You might have to learn to live with those neighbors.

VMware has suggested that VVOL users can create just one storage container per array, but that’s hardly granular. Whatever policies (disk type, QoS, dedupe, snapshots, replication, etc.) you apply to that container may apply to all the VMs on that container. You’re going to need a VVOL implementation that can support a lot of containers.

VVOLs allow you to choose VM-level services the storage admin has already set up—the VM admin can select desired performance policies for each VM. However, it does not set or guarantee performance; it merely determines into what storage container the VM will fall.