June 2016 archive

I was out at HPE Discover last week, I delivered a theater session on storage for vSphere which covered VVols and also staffed the VMware demo station which had a big focus on VVols. Throughout the event I probably spoke with at least 50 people and I wanted to share what I observed and heard from those conversations.

Observation 1: Most people still don’t know what VVols is

I’d say 80% of the people that came to my demo station had heard of VVols but really did not have a basic understanding of what it is and the benefits that it provides. While my demo had a running vSphere environment with VVols configured, it seemed that the majority of my time with people seemed to be focused on presenting slides largely based on my VVols VMworld presentation last year to educate people on what VVols is. I probably spent at least 15-20 minutes per person explaining the concepts and benefits of VVols to people. This lack of knowledge seemed to exist both at the channel level and customer level.

Observation 2: Once people understood what VVols was all about they were excited about it

Almost everyone universally liked the benefits that VVols provides, the big ones were the changes to the snapshot mechanism, automated provisioning and reclamation, no more LUNs and silo’s, better efficiency and the ability to use storage policies.

Observation 3: Storage admins seemed OK with it but had some concerns

I talked to both sides of the fence, vSphere admins and storage admins and heard perspectives from each side. vSphere admins of course loved it as it empowers them with the ability to provision and manage storage resources. Most of the storage admins seemed OK with it as well despite giving up some level of control of provisioning and common storage tasks. A few concerns that storage admins had were around limiting VVol available space on the array, suppressing some of the array capabilities to vSphere and better visibility into VVol objects from the array side. There are some workarounds to address these that can be implemented on the array side.

Observation 4: While people thought the new snapshot mechanism is great, bulk snapshot management is not so great

With VVols there are two big changes to how snapshots work. The first is that there are no more vSphere managed snapshots, you still create snapshots the same way in the vSphere client but all VVol snapshots are actually array managed snapshots. The other big change is with the snapshot operation, with VMFS the base disk of a VM becomes read only and all changes are written to separate delta files. Once you delete a snapshot those delta files all have to be merged back into the base disk which is both resource and time intensive. With VVols the base disk remains read/write when a snapshot is taken, the delta files hold the original data when a change is made. When you delete a snapshot you can simply discard the delta files as the base disk already contains all the latest data, this is very quick and efficient.

Both these changes are great, now for the not so great, for people that want to do bulk VM snapshots (more than 1 VM), with VMFS you could do an array snapshot of the entire LUN, you can’t really do that with VVols though as each VVol is essentially its own LUN. You also can’t really do it in the vSphere Client either, you would have to snapshot each VM one-by-one which can be a pain in the butt especially if you are doing it to many VMs. You could try and script something with PowerCLI but it makes management more difficult. It would be nice if VMware could build a snapshot group feature into the vSphere client natively so you could take and manage snapshots of multiple VMs simultaneously.

Observation 5: People that are using VVols today had some concerns

I did run into a few people using VVols today and it ranged from some just testing it out to a few using it more large scale. Most people were OK with it but there were a few minor concerns. I had one person that had concerns around certificate expiration of the VASA Provider, if the cert were to expire your VASA Provider would essentially be unavailable which is not a good thing. You can manage certs for the VASA Provider on either the array side or the vSphere side, what they wanted to see is an alert mechanism/alarm that would let them know ahead of time so they were not surprised by a certificate expiring. Another concern was around protocol endpoints and the efficiency of using a single protocol endpoint on the storage array. I don’t feel this is a big concern area though as we have done extensive testing and found a single protocol endpoint to be sufficient. I brought them over to our product manager that had done some of the testing to get further re-assurance. The other concerns were around the lack of maturity of the new VASA spec (VVols 1.0) and lack of replication support. I think these will go away on their own with the next release of vSphere.

Observation 6: A lot of people are still on vSphere 5.x

I discovered a lot of people are still running vSphere 5.1 & 5.5 which prevents them from using VVols which requires vSphere 6.0. This also explains the lack of VVols understanding as it simply doesn’t exist in their world. The majority of them had upgrades planned in the next 6-9 months and they seemed excited to be finally able to start using VVols in their environment.