VMware’s new storage architecture, Virtual Volumes (VVols), has been part of vSphere for over 3 years starting with the vSphere 6.0 release. However the initial release did not support array based replication which VMware eventually provided in vSphere 6.5. That support came with a caveat though, while replication was supported via Storage Policy Based Management (SPBM), orchestration of replication operations was a manual and painful process and not supported with SRM. To do a test failover, failover or failback you had to use PowerCLI and write your own scripts to orchestrate those operations, not exactly something you want to be dealing with in a time of crisis.
VMware SRM was designed to make BC/DR a simple and easy process and allow automated orchestration of replication by simply pushing a button. SRM essentially takes over the ownership and control of array-based replication using a Storage Replication Adapter (SRA) provided by each vendor specific to their storage arrays. Therefore when you click a button inside of vSphere, SRM has full control of array replication, bring up VMs at the recovery site and eventually failback to the primary site when needed by reversing replication. Having no SRM support for VVols is a show stopper for most customers that don’t want to deal with complex and manual scripts to perform BC/DR operations. Note you may have heard that SRM does support VVols today but that is ONLY if you are using vSphere Replication.
Let’s first examine how we got here and why it’s taken so long for SRM to support VVols. Most of VMware’s products are in silos, meaning they are run by different product teams, as a result product roadmaps and interoperability are not always in sync across products. Every product team has their own priorities and it may or may not include immediate support for other VMware products. VVols development has it’s own product team and they are mostly solely focused on developing VVols. Support for VVols with SRM is completely outside of the VVols engineering team and solely within the SRM engineering team. It’s not up to the VVols product manager to decide on when SRM will support VVols, it’s entirely up to the SRM product manager.
For the last year or so we’ve pleaded to the VVols team for SRM support and we were essentially told sorry, bring us customers that want it and we’ll try to push them to prioritize it. This of course frustrated everyone as support for replication without support for SRM wasn’t a complete solution. VMware’s dead silence on the issue also didn’t sit well with customers and left many customers not wanting to use VVols. Several months ago we had a face to face meeting at VMware with Lee Caswell and the product managers for VVols & SRM and again pleaded for VMware to take action. At that time they did finally commit to supporting VVols on the SRM roadmap but we also requested that they communicate that to customers sooner rather than later.
Well VMware finally broke their silence and announced SRM for VVols right before VMworld in a blog post. I’m betting the timing on this was deliberate as last year VMware got really beat up over this at VMworld and probably didn’t want a repeat of that. Note the blog post is very vague on purpose and this is just an announcement and don’t expect support for it right away. The SRM team is working on something else big right now which if you were at VMworld you could of seen a tech preview of it. The announcement basically acknowledges that VMware clearly sees SRM support for VVols as a key priority finally so customers and partners can put their pitchforks away.
Note with this announcement VMware is not just telling customers that support is coming so they can plan for it and start migrating to VVols, it’s also putting partners on notice to inspire them to prioritize finishing their support for VVols replication. To this day, almost 2 years after VVols replication was supported in vSphere 6.5 their are still only 2 partners (HPE/Pure) that support it. I think some partners may not have prioritized VVols replication support as they saw their was no SRM support for it and figured why bother.
So how will this marriage of VVols & SRM look? For one thing their will be no more SRA’s to install and maintain into SRM. Control of replication will be handled natively through the VASA Provider without any external components needed. This will be a welcome change and greatly simplify using SRM with external storage arrays. How this will impact certification (HCL) is TBD, presumably it will be handled through the VASA certification process. Beyond that we’ll have to wait and see, I know this is a nowhere near a minor change and represents a big engineering effort for the SRM team. I’m fortunate to be working closely with the SRM product manager and engineering team on this and am excited to see one of the final barriers for customers wanting to use VVols disappear.
