Monthly Archive: June 2016

Jun 17 2016

Some Top vBlog 2016 result statistics

vsphere-land-top-vblog2016-logoWhile we wait for the results announcement which should come next week via a live Google Hangout with John Troyer and VMTurbo I thought I would release some statistics on the results as an appetizer before the big meal arrives.

  • This year there were 1600+ votes, down a bit from 2200 last year.
  • There were 411 blogs in the voting last year, this year there were 321. Blogs that did not have at least 10 posts in 2015 were left off the voting ballot this year.
  • There were 83 new blogs added this year to the ballot that were not there last year.
  • There was 1 new blog (started in 2015) that made the top 50.
  • There were 12 additional blogs that made it into the top 50 that were not there last year.
  • There were 7 blogs that made it into the top 25 that were not there last year.
  • There was 1 new blog to the top 10 (and one long time top 10 blog that fell out).
  • There was 6 position changes in the top 10.
  • There was a very heated and close battle this year for the #1 spot. Do we have a new #1? Watch the live results show to find out.
Share This:

Jun 16 2016

Observations and feedback on VMware VVols gathered from HPE Discover attendees

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.

IMG_4306

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.

Share This:

Jun 15 2016

Top vBlog 2016 voting results coming soon

vsphere-land-top-vblog2016-logoThe voting survey closed at the end of May, we had just over 1600 votes this year. I just finished a big road trip that was half vacation, half work right after the voting closed so the results announcement has been a bit delayed. On the trip we ended up driving from Denver, CO to Roswell, NM, then to Phoenix, AZ for a few days to celebrate my 50 b-day, then on to Vegas for a week at HPE Discover (work) and then driving down the Extraterrestrial Highway for a brief stop at Rachel, NV (you’ll know what’s there if you saw Independence Day) and finally a stop in Richfield, UT before heading back to Denver.

I’ll be publishing some voting stats this week as a teaser and am checking the availability of Mr. Troyer and the VMTurbo folks so we can set a date and time for the live results show which will hopefully be next week. Until then enjoy some pics from my road trip and stay tuned for more on Top vBlog 2016:

Poolside in Phoenix, it was 116 degrees when we got there, I don’t miss living there at all:

2016-06-05 13.56.44-small

My office in Las Vegas for the week:

2016-06-06 14.19.28-smallCool items that were actually used in the new Star Trek movie, first two are the Captains command chair:

2016-06-07 16.50.51-small2016-06-07 16.51.10-small

Escape pods from the Enterprise:

2016-06-07 16.52.33-small2016-06-07 16.52.47-small2016-06-07 16.52.54-small

Cool Internet Of Things interactive exhibit:

2016-06-07 16.53.27-smallRachel, NV, close to Area 51 and featured in the Independence Day movie:

2016-06-10 12.22.46-small

 

Share This:

» Newer posts