Sam Walker

VMware VVol - Real-world experience

Blog Post created by Sam Walker on Oct 8, 2015

So it has been a few months since we first had our VVol customer (mentioned in a post here Experience with VMware VVols)  in to discuss this new functionality that is/was going to revolutionise the way they store data... but has it? 


First of all, about the customer.  For obvious reasons, I will keep their name and type of business out of it, but Customer X has been a long-time Hitachi storage customer with many PBs of data on our arrays.  The reason for them striking up a conversation with us, other than keeping current and relevant, was that they were under pressure from their VMware team pushing for VSAN...  I try and keep myself neutral when designing solutions; just because I work for HDS doesn't mean that VSAN is always an inappropriate solution.  Most of our customers are of the size whereby VSAN is not a consideration unless for ROBO deployments, which we can do on our UCP1000 EVO:RAIL appliance, but I digress.


The reason for this pressure was that the VMware team were keen to move away from the model I see in a vast number of enterprise organisations; the 'us and them' between VMware and storage teams... Quite often, VMware administrators will find themselves cutting corners to avoid what can be an arduous wait for provisioning storage.  Also, I have sat on the side of the storage administrator; "Why do you need so much storage?", "why such a fast tier of disk?", "that's a backup LUN, are you sure it needs to be replicated in addition to our backup replica?", etc.  Artificial road-blocks are put in place because of process, change control, people factors.


So what has VVol promised to do and has it delivered? 


Due to the current limitations with VVol, the current deployment is in their test and dev facility.  This is so they can continue to use SRM, Array Based Replication (ABR), vROps (or vCOps as I believe it's called on their current prod version) plus other limitations that VVol currently imposes (see here VMware KB:     VMware Virtual Volumes (VVols) interoperability with other vSphere products and features).  Additionally, they have a vSphere 5.5 production environment and upgrading a whole infrastructure of their size to 6.0 will take them a long while of planning and careful execution.


Currently, all functionality tests have been successful.  We are in discussions around which policies they should be creating on their array and how they should be mapping these through to VMware.  I am keen to avoid the 'Gold', 'Silver' and 'Bronze' discussions - which unfortunately for most demos is a must because we don't understand the customer's application requirement.  What I have been discussing is the required characteristics of their applications (an example I used in Experience with VMware VVols was how a database would have a different set of requirements for OS, DB and Logs).  As such, although a lot of the marketing material will appear that enabling SPBM is a one-click setting, in reality, to make it work properly for your business, it takes will take a proper period of design.


One benefit is that the task of quickly standing up VMs and their storage is something that no longer takes the discussion between the VMware and storage team.  All VMs consume their own storage on the array, there is less for the VMware admins to manage as they no longer have the VMFS datastore as a management / monitoring point... so the benefits of VVols have been realised already.


So what's next...  Hopefully, for Customer X and other customers in their position, there will be a proper 'business requirements down' design where VVols are planned in a way that will improve VM consumers experience and we don't find customers reverting to the traditional VMFS datastore method for the wrong reasons.