Tag Archive: VVols

May 24 2019

4 out of 5 storage partners surveyed would recommend VVols for their customers who use VMware

Remember the old Trident gum commercial, it was a ringing endorsement from dentists for their patients that chew gum. Well recently VMware hosted a Virtually Speaking podcast featuring various storage partners to talk about VVols. The podcast featured representatives from key VVols partners: HPE, Pure, HDS and NetApp along with Bryan Young (VVols product manager), Pete Flecha, John Nicholson and Jason Massae from VMware.

I happened to be one of the people representing HPE and we talked about various topics including adoption and how customers are using VVols. When it comes to adoption both VMware and all partners are seeing increasing customer usage of VVols and every partner recommends that customers check out VVols and see what they are missing out on. So go listen to the podcast here, and what about that 5th partner? Apparently they didn’t show up but I’m confident they would recommend VVols to their customers as well.

Share This:

Mar 11 2019

Happy 4th Birthday VVols! – Is 2019 the year of VVols?

VMware’s new Virtual Volumes (VVols) storage architecture became available exactly 4 years ago today as part of the vSphere 6.0 GA. The vSphere 6.0 datasheet described VVols in this manner:

Transform Storage for your Virtual Machines – vSphere Virtual Volumes* enables your external storage arrays to become VM-aware. Storage Policy-Based Management (SPBM) allows common management across storage tiers and dynamic storage class of service automation. Together they enable exact combinations of data services (such as clones and snapshots) to be instantiated more efficiently on a per VM basis.

I was very involved in the initial launch of VVols and worked closely with VMware to promote and market it. There was very little ecosystem support for VVols at launch, only 4 vendors supported it on day 1, and looking back over the years VVols has come a long way since it’s initial release.

Last year I wrote that I felt 2018 wasn’t the year of VVols for a number of reasons, this year however I feel that 2019 will be the year that VVols adoption picks up pace and we finally start to get towards seeing mainstream usage. I recently wrote an article on the HPE blog detailing the reason for this, you can go read my thoughts behind that over there. I did want to talk a bit about the dreaded “Chasm” that is typical of technology adoption and how VVols relates to that model.

I recently took a product management leadership course and they covered in detail the stages of product adoption from the early market stage where products are born and launched to the chasm stage which must be crossed before you get to the mainstream stage. The chasm represents a significant challenge for a product or technology for it to cross over from early adopters to more mainstream adoption. The representative user base for any technology product typically includes the following user types:

  • Innovators/Techies – always adopting new stuff right away
  • Early Adopters/Visionaries – trying to stay ahead of the herd
  • Pragmatists – sticking with the herd
  • Conservatives – OK with the status quo and moves only when they have to
  • Skeptics – no way are they moving

The chasm exists between the visionaries and pragmatists which represent a very small percentage of a user base and winning over the pragmatists are the key to the adoption of any new technology and it going mainstream. This illustration that Pete Flecha from VMware used in his VMworld session illustrates this:

In this illustration the chasm looks fairly small and easy to cross but in reality that chasm is very wide and can represent many years to cross. The course I took highlights 2 key deliverables that a product must have to cross the chasm and win over the Pragmatists:

  • Credible customer references from fellow trusted Pragmatists, references from early adopters/visionaries are interesting but not sufficient
  • 100% minimum viable whole product that truly solves the Pragmatists pain point

To date VVols has been lacking in both of these key areas. If you look around you will find very few (if any) customer case studies with VVols. I know in general it’s often very hard to find customers willing to be references and have a case study done. I did have one years ago for VVols that was translated from an Asian language that wasn’t all that great. I don’t think I have seen any other vendors that have published one and VMware has not published any that I’m aware of as well. VMware did do a customer session on VVols last year at VMworld which was good but that doesn’t apply well beyond VMworld and is not easily consumable for anyone looking for VVols case studies today.

I think what VVols desperately needs is a lot more customer references and case studies. I came across a new one internally just last week that is in development and I plan on being very active in that one. What is needed though is for all partners, particularly the ones with larger VVols user bases to identify customers and develop these, the biggest VVols partners today are HPE, Pure, EMC and NetApp. Besides that I believe if VMware itself would publish some it would greatly help all partners as VMware has a larger audience and independent credibility from its partners. For that I’m calling out Lee Caswell who offered to help us promote VVols, having a good case study or two would really help move VVols adoption forward.

On the next point of having a 100% minimum viable whole product, VVols has been largely a work in progress since it’s initial release, this includes both the deliverables from VMware and the deliverables from partners trying to build VVols solutions. I would refer to these as two completely separate products as VMware has a product to deliver for VVols and partners have their own VVols products to deliver. On the VMware side in the beginning there were limitations including compatibility issues and lack of feature support with VVols. Over the years most of those limitations have disappeared, the big one we are still waiting on is SRM support which is finally coming this year. VMware is very near to having a 100% minimum viable whole product with VVols.

On the partner side, many partners have mature VVols solutions today but there are also many that are still playing catch up as well. Scale has been an issue with most partners that have to support many thousands of LUNs with VVols, expect scale to continue to increase as vendors continually optimize their arrays to handle VVols at large scale. How close any partner is to having a 100% minimum viable whole product with VVols is entirely up to each partner, I’d argue a few vendors are very close to being there but there are others that are pretty far off.

Overall I would say VVols is definitely ready for prime time, it’s assuredly ready for use across just about every vendors platform however there may be a “but” involved with some platforms and as long as you understand and accept that “but” you won’t have any issues with VVols. By “but” I’m saying VVols works just fine and does this and this “but” it just doesn’t do this right now. An example of a “but” may be doesn’t support replication or doesn’t scale over 5,000 VVols. If that “but” doesn’t apply to your environment you have nothing to worry about, if it does you can still use VVols to the extent you can while avoiding the “but” scenario and using VMFS for whatever may require it.

The bottom line is I feel 2019 is the year where VVols adoption will accelerate at a faster pace than it has before. From a development perspective it’s in a good place right now, the core VVols product is solid, there is really nothing limiting partners from building out complete VVols solutions right now. Partners will continue to mature and enhance their VVols solutions and SRM support is coming this year. I can’t say that VVols will completely cross the chasm this year but if VMware and it’s partners collectively promote the benefits of VVols and help increase customer awareness it will go a long way towards getting there. It will really take a group effort and that includes customers as well, if you are a customer that uses VVols today please reach out to VMware and/or your storage vendor and tell us your VVols story. Together we can navigate the chasm and climb the mountain to get VVols to be mainstream where it deserves to be.

Share This:

Jan 22 2019

VVols update

I’ll be doing a few posts on VVols in the coming weeks right here but I wanted to highlight a recent post on VVols that I did on the HPE Around the Storage Block blog. In that post I highlighted the following:

  • A recent webinar I did with VMware on the benefits of VVols
  • Why nobody was really ready for VVols until recently
  • How VVols is like a foundation for the house and it’s up to each vendor to build their house
  • Why I feel 2019 will be the years that VVols will start to take off
  • Some statistics on VVols adoption
  • What’s new from HPE related to VVols

So go check it out here and stay tuned for a lot more right here.

Share This:

Nov 28 2018

Recorded webinar now available: A Farewell to LUNs – Discover how VVols forever changes storage in vSphere

Pete Flecha from VMware and I just finished recording a webinar on VVols where we discuss challenges with external storage, the benefits of VVols along with the latest adoption trends and ecosystem readiness. If you are on the fence about VVols or just want to learn more about it be sure and check it out.

 

Share This:

Sep 15 2018

Why VMware VVols are Simpler, Smarter and Faster then traditional storage

Recently at VMworld in Vegas, Pete Flecha from VMware did a presentation on VVols at the HPE booth which highlights the benefits of VVols being simpler, smarter and faster than traditional storage with vSphere. The link to the presentation is below but I thought I would also summarize why VVols are simpler, smarter and faster.

VVols are Simpler

The reason VVols are simpler is because of storage policy based management which automates the provisioning and reclamation of storage for VMs. VVols completely eliminates LUN management on the storage array as vSphere can natively write VMs to a storage array, VVols are provisioned as needed when VMs are created and automatically reclaimed when VMs are deleted or moved.

VVols are Smarter

The reason VVols are smarter is again because of storage policy based management and also by the dynamic real time nature of storage operations between vSphere and the storage array. With VVols a storage array stays as efficient and thin as possible as space is always reclaimed immediately for VMs and snapshots and even when data is deleted within the guest OS it can be reclaimed on the storage array. In addition the array manages all snapshots and clones and array capabilities can be assigned at the VM level with SPBM.

VVols are Faster

The reason VVols are faster is not what you might think, data is still written from vSphere to a storage array using the same storage queues and paths, there is no performance difference between VVols & VMFS for normal read/write operations. Where VVols is much faster than VMFS is when it comes to snapshots, because all vSphere snapshots are array snapshots they are much more efficient and they take the burden off the host, In addition because there is no need to merge any data that has changed while a snapshot is active, deleting snapshots is always an instant process which can have a very positive impact on backups.

 

Go watch the whole video to learn more about why VVols are so great , it’s only about 15 minutes long.


Share This:

Sep 06 2018

VMware VVols from a customer perspective

What do donuts and nuclear power plants have in common beyond the obvious answer? (hint: The Simpsons) They both are companies that are running VMware VVols! At VMworld this year instead of VMware putting on a VVols partner panel they chose to do a customer panel session instead. This was a great move as it lets you hear direct from customers actually using VVols on their experiences with VVols and the benefits that they found with VVols. Below is my summary of the session and some highlights from it:

Session:  Leveraging Virtual Volumes (VVol) to Simplify Storage Management (HCI2550PU)  (View session recording)

Speakers: Bryan Young, Group Product Manager, VMware – JJ Seely, Sr. Server Administrator, NuScale Power, LLC – Michael Bailess, Infrastructure Technology Manager, Krispy Kreme Doughnut Corporation

  • The panel was moderated by Bryan Young from VMware who is the product manager for VVols and consisted of 2 customers, J.J. Seely from NuScale Power and Michael Bailess from Krispy Kreme donuts.

  • Bryan first gave an update on where VMware is at with VVols, he showed off the timeline of VVols from it’s initial release as part of vSphere 6.0 in March 2015 to the vSphere 6.5 update in November 2016 which brought the long awaited support for replication and finally to the most recent release, vSphere 6.7 in April 2018 that added a few more VVols enhancements

  • Next he made the point that despite you not hearing too much from VMware anymore about VVols, it is a very active program and growing significantly. Over the last few months they have seen a 2x increase in the number of deployments of VVols and a 3x increase in the capacity of VVols deployments, much of that happening in the last 6 months. In case you are wondering they can track this with vCenter Analytics Cloud data (phone home). The partner commitment around VVols remains strong with many partners working to finishing their VVols 2.0 (replication) solutions. On VMware’s side they are growing their engineering team to support VVols and have a solid roadmap going forward for enhancing VVols.

  • VMware’s partner ecosystem for VVols has been growing and every major storage vendor at least supports VVols 1.0 today. As each partner is at different stages of completing their VVols solutions it’s best to reach out to them and find out their roadmaps for supporting VVols.

  • Bryan reviewed what VMware delivered in vSphere 6.7 around VVols, the big one being support for  SCSI-3 Persistent Reservations. Why is that one big? Because there is no more need for RDMs as VVols can support this natively. Many customers are still using RDMs to support Microsoft Windows Failover Cluster Server which is really the only use case for RDMs. Nobody really likes managing RDMs so it’s great that VVols can do this natively now. I actually know a few customers that have mass migrated their RDMs to VVols.

  • Bryan then highlighted an important aspect of VVols that many people don’t get. VVols & vSAN are not an either/or decision, they work perfectly together as they are both based on the same Storage Policy Based Management engine native to vSphere. There is seamless interoperability between VVols & vSAN and VMs can move freely from one to the other.

  • From that point each customer did a short presentation and there was a lot of Q&A from the attendees. Go listen to the recording and find out what they had to say. You can also listen to a separate breakout session where Michael Bailess from Krispy Kreme went into his experience with VVols in more detail.
Share This:

Aug 08 2017

Learn about VVol Replication online and at VMworld

The ability to use VVol replication is new in vSphere 6.5 and there aren’t a whole lot of vendors that support it yet. Right now HPE is the only vendor that supports it on their 3PAR & Nimble platforms. You can see for yourself who supports it by going to the VVols’s Compatability Guide and selecting “VVols Storage Replication” in the Features window. As with anything VVol’s related, it’s on each partner to design their own implementations of any array capabilities related to VVols while staying within VMware’s VASA specification. As a result every partner will typically have a much different way of integrating with VVols.

Take Nimble for example, they actually supported replication in vSphere 6.0 by building it into their storage policies as a capability. With vSphere 6.5, replication was added as a separate SPBM Component that could be attached to a storage policy, this is the way 3PAR is doing it. They both are a means to the same end but they were just designed and implemented a bit differently. While the replication part is fairly straightforward and is automated through storage policies, the recovery operations can be a bit complicated as you pretty much have to rely on PowerCLI scripts to perform operations such as failover, failback and test failover.

HPE and VMware have published a few resources to help you with this and provided you with some sample PowerCLI scripts to get you started. The scripts are fairly vendor agnostic so they could be leveraged by any storage platform that supports VVol replication. Below are the links to some resources that will help you understand and implement VVol replication. In addition if you are attending VMworld be sure and check out session [STO3305BUS]: Replicating VMware VVols: A technical deep dive into VVol array based replication in vSphere 6.5 were I’ll be presenting with some technical folks from 3PAR & Nimble to give you plenty of great information including demo’s on VVol replication. In addition there is a HOL (SPL182701U) were you can experience VVols  first hand.

VVol Replication resources:
Share This:

Sep 15 2016

Top 10 reasons to start using VVols right now

VMware’s new storage architecture, Virtual Volumes (VVols), has been out for a year and a half now as part of the vSphere 6.0 release and adoption continues to be very light for a variety of reasons. This kind of adoption can be typical of any 1.0 release as users wait for it to mature a bit and better understand the differences of it compared to what they are used to using. VVols brings a lot of great benefits that many are unaware of so in this post I though I would highlight those to try and make a compelling use case to start using VVols right now.

top10list-crop10 -You don’t have to go all in

It’s not all or nothing with VVols, you can easily run it right alongside VMFS or NFS on the same storage array. Because VVols requires no up-front space allocation for it’s Storage Container, you will only be consuming space on your existing array for any VMs that are put on VVol storage. Since VVols is a dynamic storage architecture, whatever free space you have remaining on the array is available to your VVols Storage Container which is purely a logical entity unlike a VMFS volume which requires up-front space allocation.

You can easily move running VMs from VMFS to VVols using Storage vMotion and back again if needed or create new VMs on VVols. This allows you to go at your own pace and as you move VMs over you can remove VMFS datastores as they are emptied out which provides more available space to your Storage Container. Note that Storage vMotion is the only method to move existing VM’s to VVols and you cannot upgrade VMFS datastores to VVol Storage Containers.

9 – Gain early experience with VVols

VMware never keeps 2 of anything around that do the same thing, they always eventually retire the old way of doing it as it is double the development work for them. At some point VVols will be the only storage architecture for external storage and VMFS will be retired. How long did you wait to switch from ESX to ESXi or to switch from the vSphere C# client to the web client? Did you wait until the last minute and then scramble to learn it and struggle with it the first few months. Why wait, the sooner you start using it the sooner you will understand it and you can plan on your migration over time instead of waiting until you are forced to do it right away. By gaining early experience you will be ahead of the pack and can focus on gaining deeper knowledge of it over time instead of being a newbie who is just learning the basics. There are no shortage of resources available today to help you on your journey to VVols.

8 – Get your disk space back and stop wasting it

With VVols both space allocation and space reclamation is completely automatic and real-time. No storage is pre-allocated to the Storage Container or Protocol Endpoint, when VM’s are created on VVols storage they are provisioned thin by default. When VMs are deleted or moved space is automatically reclaimed as the array can see VMs as objects and knows which disk blocks they reside on. No more manually running time and resource intensive cli tools,  vmkfstools/esxcli to blindly try and reclaim space on the array from deleted or moved VMs. VVols is designed to allow the array to maintain a very thin footprint without pre-allocating space and carving up your array into silos like you do with VMFS and at the same time being able to reclaim space in real time.

7 – It’s available in all vSphere editions

VVols isn’t a vSphere feature that is licensed only in certain editions such as Enterprise Plus, it’s part of the vSphere core architecture and available in all vSphere editions. If you have vSphere 6.0 or higher you already have VVols capabilities and are ready to start using it. VVols is mostly under the covers in vSphere so it won’t be completely obvious that the capability is there. It is part of the same Storage Policy Based Management (SPBM) system in vSphere that VSAN uses and also presents itself as a new datastore type when you are configuring storage in vSphere.

6 – Let the array do the heavy lifting

Storage operations are very resource intensive and a heavy burden on the host. While server’s are commonly being deployed as SAN’s these days, a server really wasn’t built specifically to handle storage I/O like a storage array is. VMware recognized this early on which is why they created vSphere APIs for storage such as VAAI to offload resource intensive storage operations from the host to the storage array. VVols takes this approach to the next level, it shifts the management of storage tasks to vSphere and utilizing policy based automation storage operations are shifted to the storage array.

So things like thin provisioning and snapshots which can be done either on the vSphere side or the storage array side with VMFS are only done on the storage array side with VVols. How you do these things remains the same in vSphere but when you take a snapshot in the vSphere client you are now taking an array based snapshot. The VASA specification which defines VVols is basically just a framework and allows the array vendors to implement certain storage functionality, however they want to handle things within the array is up to each vendor. The storage array is a purpose built I/O engine designed specifically for storage I/O, it can do things faster and more efficiently, why not let it do what it does best and take the burden off the host.

5 – Start using SPBM right now

VSAN users have been enjoying Storage Policy Based Management for quite a while now and with VVols anyone with an external storage array can now use it as well. While Storage Policies have been around for even longer when first introduced in VASA 1.0, they were very basic and not all that useful. The introduction of VASA 2.0 in vSphere 6.0 was a big overhaul for SPBM and made it much more rich and powerful. The benefit of using SPBM is that makes it easier for vSphere and storage admins by automating storage provisioning and mapping storage array capabilities including features and hardware attributes directly to individual VMs. SPBM ensures compliance of defined policies so you can create SLA’s and align storage performance, capacity, availability and security features to meet application requirements.

4 – Snapshots don’t suck anymore

vSphere native VM snapshots have always been useful but they also have a dark side. One of the big disadvantages of vSphere snapshots is the commit process (deleting a snapshot) which can be very time and resource consuming, the more so the longer a snapshot is active. The reason for this is that when you create a vSphere snapshot, the base disk becomes read only and any new writes are deflected to delta vmdk files that are created for each VM snapshot. The longer a snapshot is active and the more writes that are made the larger the delta files grow, if you take multiple snapshots you create more delta files. When you delete a snapshot all those delta files have to be merged back into the base disk which can take a very long time and is resource intensive. As backup agents routinely take snapshots before doing a backup of a VM, snapshots are a pretty common occurrence.

With VVols the whole VM snapshot process changes dramatically, a snapshot taken in vSphere is not performed by vSphere but instead created and managed on the storage array. The process is similar in the fact that separate delta files are still created but the files are VVol snapshots that are array-based and more importantly what happens while they are active is reversed. When a snapshot of a VM on VVol-based storage is initiated in vSphere a delta VVol is created for each virtual disk that a VM has but the original disk remains Read-Write and instead the delta VVols contain any disk blocks that were changed while the snapshot is running. The big change occurs when we delete a snapshot, with VVols because the original disk is Read-Write, we can simply discard the delta VVols and there is no data to commit back into the original disk. This process can take milliseconds compared to minutes or hours that is needed to commit a snapshot on VMFS datastores.

The advantage of VVol array based snapshots are many, they run more efficiently on the storage array and you are not using up any host resources. In addition you are not waiting hours for them to commit, your backups will completed quicker and there is no chance of lost data from long snapshot chains trying to be written back into the base disk.

3 – Easier for IT generalists

Because storage array management shifts to vSphere through SPBM, IT generalists don’t really have to be storage admins as well. Once the initial array setup is complete and the necessary VVols components created, all the common provisioning tasks that you would normally do on the array to support vSphere are done through automation. No more creating LUNs, expanding LUNs, configuring thin provisioning, taking array based snapshots, etc., it’s all done automatically. When you create a VM, storage is automatically provisioned on the storage array and there is no more worrying about creating more LUNs, determining LUN sizes and increasing LUN sizes when needed.

With VVols you are only managing VMs and storage in vSphere, not in 2 places. As a result if you don’t have a dedicated storage admin to manage your storage array, an IT generalist or vSphere admin can do it pretty easily. Everything with SPBM is designed to be dynamic and autonomic and it really unifies and simplifies management in a good and efficient manner to reduce the overall burden of storage management in vSphere. Instead of having the added complexity of using vendor specific storage management tools, with VVols management becomes more simplified through the native vSphere interfaces.

2 – It unifies the storage protocols

VMFS and NFS storage are implemented pretty differently in vSphere and what VVols does is dictate a standardized storage architecture and framework across any storage protocol. There were several big differences with file and block implementations in vSphere, with block you presented storage to ESXi hosts as LUNs and with file as a mount point. You still do this to connect your array’s Protocol Endpoint to a host but the standard storage container that is presented to a host to store VMs is just that, a Storage Container, not a LUN or mount point anymore.

When it came to file systems with block an ESXI host would manage the file system (VMFS) and with file it was managed by the NAS array. With VVols there is no file system anymore, VVols are written natively to the array without a file system regardless of it’s a file or block array. And the biggest change is that VMs are written as files (VVols) to block storage in the same manner that file storage has been doing it all along. This creates a  unified and standardized storage architecture for vSphere and eliminates the many differences that existed before between file and block. VVols creates one architecture to bring them all and in the darkness bind them (LOTR reference).

1 – The VM is now a unit of storage

This is what it’s all about, the LUN is dead, because it’s all about the VM, ’bout the VM, no LUN. With VVols the VM is now a first class citizen and the storage array has VM-level visibility. Applications and VMs can be directly and more granularly aligned with storage resources. Where VMFS was very LUN-centric and static creating silos within an array, aligning data services to LUNs and utilizing pre-allocated and over provisioned resources. VVols is VM-centric and dynamic where nothing is pre-allocated, no silos are created and array data services are aligned at the more granular VM-level. This new operational model transforms storage in vSphere to simplify management, deliver better SLAs and provide much improved efficiency. VVols enables application specific requirements to drive provisioning decisions while leveraging the rich set of capabilities provided by storage arrays.

Share This:

Older posts «