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.
This has been a long journey – I did posts on VVOLs here, here, and most recently here….
… 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!
First – the VMAX3 VVOL demo (using block protocol endpoints).. What’s 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 I’ve 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).
Second – the VNXe VVOL Demo (using Filesystem protocol endpoints). This demo shows the path that the VNX family is taking (and VNXe will be the first EMC platform to beta – in fact, looking for participants now). You can see how VNX behaviors (like FAST autotiering and flash-based caching) are surfaced at VM-level granularity.
BTW – a huge thank you to the great EMC team that made this demo video: Brian Tobia, Chris Banck, Karol Boguniewicz, Raj Dawar, Doug Pardue, plus of course the awesome EMSD vVOL team!
So – what’s the sequence of VVOL support EMC customers should expect? We’ll as we always try to strive for – we want to be there in lockstep with VMware – and will be there day one with VNXe.
Inevitably hard choices to not back-port are rooted in “degree of code change + memory footprints + impact to existing customer base + risk to existing code stacks” trade-offs, and I’m sure there will be some comments (please make them!), but I’m a big believer in transparency. If VNXe will be first, other targets will take a little longer, but not very long… here’s the scoop!
- VNXe3200 will be first and will be there with day one suppport. We are looking for beta participants now for a Q4 Beta (email VVOLBETA@emc.com to get in). BTW - filesystem protocol endpoints implementation is the furthest along, but at GA, will be block and file protocol models.
- This will be the route where VVOLs will expand to the whole VNX family: using Unity using the common C4 codebase and CBFS architecture.
- VMAX3 will be next and relatively quickly after VMware GA’s VVOL release (VVOL thinking was built into the whole product design for VMAX3 – which you can see from the demo). VVOL support won’t be back-ported to previous generation VMAX.
- ViPR Controller will support VVOL control path communication (VASA 2.0+) relatively quickly also which means it can “front” storage targets that support vVol data path functions.
- XtremIO will support VVOL later after VMware GAs vVols
- VPLEX will support VVOL later after VMware GAs vVols (this is the use cases for VERY async vMotion)
- ScaleIO will support VVOL, but this is still being scoped.
If you’re at VMworld – here are things to check out:
- STO1963: This the broad VMware VVOL Business overview session. With Denis Vilfort as the EMC speaker (and Denis is great, grab him afterwards!) – Tuesday 11:30 – 12:30
- INF1864-SPO - Software Defined Storage - What’s Next? With little ol’ me (and some surprises in store!), Tuesday, Aug 26, 4:00 PM - 5:00 PM, Moscone West, Room 2016
- STO3161 - What Can Virtual Volumes Do For You? Matt Cowger with VMware on Tuesday, Aug 26, 12:30 PM - 1:30 PM, Moscone West, Room 2002
- Also – email Veena Joshi or Wadah Sayyed (all EMC emails are firstname.lastname@emc.com format) to get an NDA peek – they are at the event, and are responsible for big chunks of our VVOL support from a product mgmt standpoint.
- You can try VVOLs for yourself at the EMC Hands on Labs – where we are showing VVOL demonstrations of all kinds!
There you have the scoop! Sign up for the beta! I would LOVE your thoughts, comments and feedback!
Hi Chad,
"This will be the route where VVOLs will expand to the whole VNX family: using Unity using the common C4 codebase and CBFS architecture"
Is the whole VNX family (assuming just VNX2) going to support vVols or just the Unity/C4 models (like VNXe3200)? We've bought (3) 7600's and a 5800 in the past 12 months, sure would be disappointing if in early-2015 EMC says our 1.5 year old arrays won't support vVols.
Ben
Posted by: Ben Conrad | September 03, 2014 at 12:11 AM
@Ben - thank you for being an EMC customer! We're still finalizing the VNX2 plan. I know the engineering team wants to back-port as much as we can - but I want to emphasize, VVOLs are a material data path change.... Drop me an email, would love to talk about it more, and loop in the product team..
Posted by: Chad Sakac | September 03, 2014 at 12:17 AM
Hey, any updates on VNX2 & vVol futures?
We got few VNX5400 and looking for info on this.
Posted by: sk | January 17, 2015 at 06:42 AM
Hi Chad,
Is EMC expect to be ready, to offer vVOL, with vSphere 6 GA for VNX2 and VNXe3200?
Some of my customers will quickly try this technology.
Thanks for your answer !
Cédric
Posted by: Cedric Megroz | February 26, 2015 at 04:59 AM
@SK - I'll be doing an update on VNX2 support shortly. Hold tight. The engineering team is trying to pull forward some things.
@Cedric - VNXe3200 will be one of the first, and available after the vSphere 6.0 GA release. VNX2 details are still being ironed out. I'll do a post soon.
Posted by: Chad Sakac | March 01, 2015 at 04:44 AM
I have the VMAX3 and XTREMIO and I cannot wait for vvol support.
Posted by: John Ford | April 14, 2015 at 12:30 PM
Nice article.
Are there "known" any timeframes for the VPLEX support? (3rd Quarter/4th Quarter?) :-)
Bgrds,
Finnur
Posted by: Finnur Gudmundsson | April 15, 2015 at 07:39 PM