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:
1. 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.
2. 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 its own container (with its own policy), and the storage administrator wouldnt 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 its own policy (though its notable that in the VSAN 1.0 release, the policy is pretty basic basically mirroring and striping) but in VSANs case, its even MORE tightly coupled (for better and for worse) in the sense you dont 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.
were almost there (but still not quite)!
BTW this is a relatively heavy engineering lift for everyone, as were talking about:
At EMC, weve 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, Ill share the current sequence and plans for VVOL support across the EMC family but first, I want to show the latest demonstrations that were sharing at VMworld for VMAX3 and VNXe. Read on!
First the VMAX3 VVOL demo (using block protocol endpoints).. Whats REALLY cool about this one is: a) how the VMAX3 SLO policy engine for storage containers maps so nicely into VVOLs ; b) shows how PowerPath can integrate with block protocol endpoints to ensure they are solid very important with VVOLs; c) the new SnapVX engine enabling hardware-accelerated snapshots [no more Copy-on-Write VMFS snapshots, yeah!] between different storage policy sets and the resulting difference in VM-level behavior!; d) VM-level QoS behavior controls as a VVOL rule set
I have to say, this is one of the coolest VVOL demos Ive seen (after perhaps the use case of using VVOLs to switch replication gears from async/sync dynamically with vmotion VPLEX one from VMworld 2012 here).
See full story on virtual geek.typepad.com