«

»

Apr 07 2015

So VMware Virtual Volumes (VVols) is here, when will people start using it

VVols (1)

After many years in the making VMware’s new storage architecture, Virtual Volumes (VVols) is finally available as part of vSphere 6.0. VVols certainly looks cool but does the old adage hold true, if you build it will they come? In this post I’ll take a look at some reasons why people may want to wait to begin using VVols and some reasons why they might want to start using VVols right now.

Before we begin lets address what VVols is, VMware hasn’t stated this as far as I know but VVols will replace VMFS at some point. VMware never keeps two of any big infrastructure components around as it doubles their development work. They phased out ESX a few years after ESXi was launched, they just killed off their VSA in favor of VSAN and they are still trying to get rid of the vSphere Client in favor of the Web Client, at some point I expect them to phase out the Windows based vCenter Server in favor of the VCSA. So the same will most likely hold true with VVols, at some point VMware will phase out VMFS after it matures and more people start adopting it. Further evidence of this is that VVols is included in every edition of vSphere and it is not an add-on that you only get with certain editions.

Now lets first cover some reasons why you might want to wait before using VVols:

1. No support for storage array replication yet

This is a big one especially for larger enterprises that rely on storage array replication for BC/DR. Storage replication support is not part of the current VASA 2.0 specification so SRM and vMSC are not supported with VVols, for many that’s a show stopper right there. However despite VMware not supporting storage array replication yet some vendor implementations will or do support it now so that could be a workaround but you still can’t use it with SRM or vMSC until VMware builds it into the VASA spec.

2. It’s a 1.0 storage architecture

Yeah it’s been years in the making but it’s still 1.0 and like any 1.0 product there is always growing pains which could cause some people to wait. In addition there is still some feature and compatibility support missing in VVols (i.e. replication) which could prevent some people from adopting it right away. In addition on the storage array side support for it within the array which required a lot of development work from storage vendors is essentially 1.0 as well. A few storage vendors such as HP, NetApp and Dell were design partners and have been developing support for VVols for years so expect them to have the most mature implementations.

3. Not all storage vendors have full support for it yet

There were only a handful of companies (4) that had Day 1 support for VVols in the VMware Hardware Compatibility Guide, expect this to increase as more storage vendors finish their development work and complete the VMware certifications for VVols. In addition storage vendors are still working on broadening their supported features with VVols.

4. Who will win the data center politics game

Remember how it was when you first told your network admins about vSwitches and your networking requirements for vSphere. Yeah they felt they were giving up control and probably put up a fight. The same scenario might play out with VVols, storage admins may not like the fact that they are giving up some control and may push back on it. Resistance has proven to be futile though, the vSphere admins won the networking battle and they will eventually wear down the storage admins as well. To make this easier I encourage you to keep them fully involved, explain what VVols is and how it works and how it will ultimately make their job easier and allow for a much better relationship between VMs and storage.

5. How well does it scale

I have yet to see any performance numbers to show how well VVols does as it scales and a comparison to VMFS. Will it be better than VMFS, the same or worse? I expect it to at least be on par with VMFS, possibly even better, VVols isn’t really about boosting performance over VMFS, it’s about implementing a new VM-centric storage architecture that makes the VM a unit of storage to the storage array. The same held true with RDM’s vs. VMFS, it wasn’t about performance and VMware proved they performed equally as well so I expect the same to hold trued with VVols. It would be nice to have some testing though to back this up and I’ve heard that VMware is working on it.

6. Array features must be licensed

VMware has long tried to mimic storage array features inside of vSphere such as thin provisioning, VM snapshots, Storage vMotion, Storage I/O Control and more. Using many of those features on the vSphere side will not be possible any longer with VVols as everything shifts back to the storage array. So when you take a VM snapshot it will automatically be an array snapshot, same with using thin provisioning, the array will be doing it. This is a good thing as the array is better equipped to handle these functions faster and more efficiently. However this does require you to have those features licensed on your storage array to use them. Some vendors may include these features as part of their core feature set but others may not so check to see how much they will cost.

7. When will the backup vendors get on board

VVols changes the direct to SAN backup model as you now have a Protocol Endpoint and VASA Provider to deal with. I haven’t heard of any backup vendors that support this model with VVols yet but I expect to see support coming soon. Check with your backup vendors to see where they are at with VVol support and what there plans are for it. I expect to see Veeam be one of the first to support VVols as they tend to be ahead of the pack with supporting any new vSphere features.


This may seem like a lot of reasons to discourage you from jumping in and start using VVols but fear not, despite the reasons listed above VVols does provide some great benefits and is the right storage architecture for vSphere. Just like VSAN brings Storage Policy Based Management (SPBM) to the VM-level VVols does the same for shared storage. Aligning VMs directly to storage resources and having the storage array visibility to the VM-level is a very good thing to have. So lets now look at some reasons why you should start using VVols right now:

1. It’s not all or nothing with VVols

You can use VVols right along side of VMFS or NFS and you are not having to completely switch over to VVols all at once. VVols simply becomes another storage option that you can choose to put VMs on. You can easily move VMs from VMFS/NFS to VVols and back using Storage vMotion, so you can setup your Storage Container for VVols and then create or move VMs to it at your own pace.

2. Get early experience with VVols

Where you one of those last few people that made the switch from ESX to ESXi then had to struggle to learn the nuances of ESXi compared to ESX? Are you struggling with learning the vSphere Web Client? Why wait and have to learn how to use VVols when you are forced to do it as you have no other choice. Getting early experience and hands-on with VVols will get you ahead of the game and ensure you are ready when others are struggling to learn about it. You can also serve as a SME for VVols and help others learn it as well.

3. Get your disk space back!

This is big one, remember back in vSphere 5.0 when VMware introduced automatic space reclamation via UNMAP and then was forced to make it a manual process as it was causing some issues. They never did figure out how to make it an automatic process again until now, VVols is the answer. With VVols the storage array is VM-aware and knows when a VM is deleted or moved and can reclaim the disk space that it occupied right away. No more having to running a time and resource intensive process using esxcli to try and reclaim space, it’s automatic with VVols. If that wasn’t good enough on top of that UNMAP commands get passed from the guest OS to the storage array with VVols so you get even more granular space reclamation. This will ensure that you reclaim all capacity possible automatically and give you the best efficiency to maintain the smallest footprint on your storage array.

4. It’s available in all vSphere editions

Anyone can use VVols as long as your storage array supports it, there is nothing extra to license in vSphere. The setup for VVols is fairly easy as well so there is nothing stopping anyone from getting started with VVols right now.

5. Start using Storage Policy Based Management

Don’t get left out, get started using the same SPBM that VSAN users have been enjoying for the last year. SPBM allows you to define storage policies that are aligned to storage array capabilities that provide a whole new level of aligning storage array features and resources directly to VMs. SPBM allows you to pick and choose exactly what a VM should have from a storage perspective and it maintains compliance to ensure that the VM has whatever is defined in the storage policy. This is a powerful capability that VMware has put a lot of development effort in to make sure VMs have the best possible alignment with storage resources and that you can apply storage arrays features on an a la carte basis instead of at the large LUN level on many VMs.

6. Let the storage array do what it does best

The storage array is an I/O engine with software that is written specifically to work with that engine which makes it capable of powerful data movement and manipulation. Using VMFS and vSphere storage features you essentially have a 3rd party telling the array what to do which isn’t the best or most efficient way to do things. By letting the storage array do what it was designed to do without handicapping with a control freak that is pulling all the strings it allows for the array to do what it does best which results in the best possible efficiency. In addition array features are more powerful then comparable vSphere storage features and the array has better visibility into storage resources then vSphere has. As a results features like thin provisioning, snapshots and QoS are all more effective and efficient when done by the storage array.

7. Easier for the IT generalists

VVols ensures that IT generalists that may not have strong storage skills don’t have to be storage admins and can spend most of their time in the vCenter console instead of having to go to the storage console. With SPBM and VVols integration into vCenter you get a single unified management tool for storage that combines the best of both worlds, powerful storage array features managed directly from within vCenter.

8. One architecture to rule them all and in the darkness bind them

File or block? NFS, iSCSI, Fiber Channel, who cares? VVols provides a unified storage architecture across all storage protocols and puts them on a mostly level playing field with vSphere. With VVols you don’t have different types of files systems anymore, VMFS for block and NFS for file, you just have VVols and the various components that are universal to any storage protocol. Yes each protocol will still have some of it sown uniqueness still but VVols helps to eliminate some of that and make the protocol that is used less important.

8. The VM is a unit of storage

Saving the best reason for last, this is what VVols is all about, the storage array now has visibility to see individual VMs. With VMFS we only have visibility from the storage array at the LUN level, we could not see inside it and had no knowledge of the VMs that reside on that VMFS volume. Now with VVols that all changes, the VM is a first class citizen to the storage array and can be treated as a unit of storage. If we want to do an array snapshot on just one VM we can, with VMFS we had to take a snapshot of a whole LUN. If you want to assign QoS policies to certain Tier-1 VMs and not others you can, just about any storage array feature can now be done at the VM-level which is awesome. This eliminates the VMFS silo-ed approach which was wasteful and in-efficient from a storage array perspective. We can now provision storage only as needed without allocating huge chunks of it to VMFS datastores. This is the reason why VMware created VVols to begin with.


Everyone will have their own decision to make on when they want to get started with VVols, keep in mind at some point it will not be “if you will switch to VVols” it will be “when will you switch to VVols”. VVols certainly has some great benefits and better aligns storage resources to individual VMs but you will need to look how they fit into your own environment before making the decision to switch to them. I encourage you to get started as soon as you are able to, because you can use VVols alongside NFS or VMFS it makes the decision much easier as you can slowly dip into the pool instead of jumping all in.

 

Share This:

1 comment

1 ping

  1. Dmytro

    Hi. NetApp have DR capability in VASA Provider: VP is stored VVOL metadata with the VVOL objects resident in Data ONTAP.
    So it enables you to recover your VVOLs environment. In another words we can use SnapMirror for VVOLs. And Veeam support SnapMirror.

    Does Veeam support SnapMirror for VVOLs?

    Thanks,
    Dmytro

  1. Virtual Volumes (VVols) and Replication/DR | CormacHogan.com

    […] then brings us on to the lack of support for “array-based replication”. In a recent blog post on VVols by Eric Siebert over at HP, the “No support for storage array replication yet” is also called out. Eric goes on […]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


*

Please answer the following to prove you're not a bot * Time limit is exhausted. Please reload the CAPTCHA.