Virtual Volumes (VVOLs) has been a perennial topic at VMworlds dating all the way back to closed door sessions in 2010, and more broadly in 2011 and 2012. The reason is simple:
- Datastores work in the most essential sense (providing persistence storage to ESX to put VMs on something), but don’t fit well with virtualization in general because the “container unit” isn’t granular to a VM, but instead to all the VMs you put in it.
- Point #1 then means that administrators need to build convoluted processes around this fundamental truth (whether using VMFS or NFS) – like careful placement logic of VMs into datastores that support the right SLA/cost/performance/features, or thinking “oh wait – if I put this VM in this datastore, it will be snapped/replicated – but in this one it won’t” (and if the storage admin changes that – the VMware admin has no idea).
Virtual Volumes as an idea has promised a better way: each VM would get it’s own container (with it’s own policy), and the storage administrator wouldn’t manage “LUNs and Filesystems”, but rather logical containers out of which vSphere could allocate freely and as needed… and in a way that could apply across the industry as a whole.
VSAN 1.0 has a “pre-cursor” (in a sense) to VVOLs – each VM has it’s own policy (though it’s notable that in the VSAN 1.0 release, the policy is pretty basic – basically mirroring and striping) – but in VSAN’s case, it’s even MORE tightly coupled (for better and for worse) – in the sense you don’t even need to interact with a VASA provider, or configure “storage containers”. But – if you like the “VM-ness” of VSAN, you understand why VVOLs are important.
… we’re almost there (but still not quite)!
BTW – this is a relatively heavy engineering lift for everyone, as we’re talking about:
- Data plane changes (always more finicky than control plane)
- the number of logical “things” the array (and remember – this isn’t a “hardware appliance” thing – but rather a software thing, so applies equally to SDS data planes running on commodity hardware) is thinking about hundreds of thousands (maybe even millions) of “things” (VVOLs) vs. hundreds or thousands of LUNs/Filesystems. Then of course this reverberates into things like replication, and other data services.
At EMC, we’ve been taking little steps along the way of course (VM-object awareness in Unisphere and other things), but VVOLs is a big leap.
Near the bottom of this post, I’ll share the current sequence and plans for VVOL support across the EMC family – but first, I want to show the latest demonstrations that we’re sharing at VMworld – for VMAX3 and VNXe. Read on!