There’s been a lot of noise around Virtual Volumes (VVol) after VMware announced their availability at its Partner Exchange conference in February 2015.
And it’s been a long time coming—VMware first presented the concept at VMworld in 2011.
But at Tintri, we’ve been thinking about VM-level capabilities for some time. In fact, we released our first VMstore in 2011, around the same time VMware proposed VVol. From the beginning, we’ve architected specifically for virtual machines and workloads, which now encompass 75 percent of all workloads, up from 2 percent in 2005. The modern data center has evolved to think and act in VMs—and we’re happy to enable it.
So don’t worry—we’ve got our head wrapped around VVol. Let’s break down three things you should consider when it comes to VMware Virtual Volumes:
1. Adding VVol on top of your conventional storage doesn’t solve all storage problems for VMs
Conventional storage is managed entirely with LUNs and volumes. If an application performs poorly, there is no way to pinpoint the cause at the VM level—since conventional storage is at the LUN level. This lack of VM-level visibility makes it difficult, if not impossible, to identify the issue and deal with it.
When you layer on VVol, the storage admin can create storage containers (kind of like carving LUNs), assigning each one specific policies (performance, cloning, snapshot frequency, etc.). Then the virtualization admin can select performance characteristics for each VM they provision. VVol plays matchmaker, aligning VMs to appropriate storage container and rebalancing as necessary.
While this puts you on the 10-yard line, Tintri puts you in the end zone. With Tintri VMstore, virtualization or storage admins set the exact policies they desire for every individual VM. There’s no need to map them to a container (or a LUN or volume); the VMs are the containers—the most granular available. That’s true VM-aware intelligent infrastructure.
2. VVol is an API
That means it’s up to storage vendors to make VVol work for the masses. And that means not all VVol implementations will be equal. In fact, given their architecture, most conventional storage providers will only support the most basic VVol features.
Most storage providers plan to support between 200 and 1,000 VVol. Tintri supports up to 1,000,000. This might sound like overkill—but you need more than you think. To create one VM, you need (at least) three VVol—and for every snapshot that’s (at least) two more. Since data centers routinely take dozens of snapshots for hundreds of VMs, your VVol will add up quickly.
Conventional storage arrays that usually manage relatively smaller numbers of LUNs and volumes may need to rewrite their operating systems to handle this number of “units.” That’s just one of the reasons the VVol API demands a storage provider with the right building blocks.
3. VVol doesn’t guarantee VM performance
Once virtualization admins select their desired performance characteristics, the VVol API will choose a storage container that best fits the request. But it doesn’t always work out. The assigned container might include a few noisy neighbors—rogue VMs that suck up performance meant for other VMs in the container. So, VVol may reshuffle VMs to different containers with characteristics that are less optimal. As all this happens, you have very limited visibility or control. In other words, no matter what services storage administrators want, VMs with VVol are still at the mercy of LUNs and volumes.
With Tintri VMstore, that doesn’t happen. The admin can toggle the exact Quality of Service for each individual VM and there is no shuffling between containers—the VM’s performance is guaranteed.