September 2018 archive

Pat showed off his newly obtained tattoo in the first day keynote, he was wearing a sport coat to begin and they went to play a video to celebrate VMware’s 20th anniversary and once they came back first thing I noticed was he looked different (no sport coat). He then rolled up his sleeve and displayed a pretty sizeable VMware tattoo on his arm. He said he got it to take his commitment to VMware to the next level and came into town a few days early and went to Bad Ass Tattoo to get it. He also said sometime what happens in Vegas (tattoo) doesn’t stay here.

Now everyone’s immediate reaction was, holy cow is that real? He did say “doesn’t stay in Vegas” which indicated it was permanent but that was quite a big tattoo in a very visible spot and to have that for life is more than just taking commitment to the next level, that’s going right to the top level. Later that day he also tweeted out a pic of him actually getting the tattoo.

I’m still undecided myself, it could be a marketing stunt, but who knows. I saw Pat in person the next day and he rolled up his sleeve and it wasn’t faded at all so it very well could be real.

Being the overly curious type though and always wanting to solve a mystery I investigated and here’s what I found.

• There is no tattoo shop called “Bad Ass Tattoo” in Vegas, now he might have just been generalizing instead of wanting to name the place specifically.
• The picture of him getting the tattoo wasn’t at a tattoo shop, it really looked like a hotel room to me. I figured he would be staying at the Delano or Four Seasons and sure enough I matched the room decor in the picture of him getting the tattoo with a picture of the dining room in the Presidential Suite at the Four Seasons hotel from TripAdvisor (see comparison below). Now if he was to get a tattoo, I could see him wanting to do it in a private location like a hotel room so doesn’t necessarily mean it was a staged picture. However the picture showed the tattoo finished and not as a work in progress so it could of very well been staged.

• If it was indeed a temporary tattoo, it was no way applied with a tattoo gun, all tattoo’s done by a tattoo gun’s needles are permanent. Temporary tattoo’s are all applied by printing out an image on transfer paper and using water to apply it, they generally last 1-5 days. It could also have been airbrushed which last about a week or even done using a sharpie which typically fade after a few months.
• If he had it done a few days beforehand the area would typically be red or flaky, it looked completely healed which typically takes at least 2 weeks. Normally as the skin heals it may be red and oozy for the first week and eventually flaky after that.

So real or not? I can’t say for sure, it’s entirely possible he got the tattoo before coming to Vegas to give it enough time to heal and then staged the part about getting it there. It’s also entirely possible that it was done with a Sharpie that would of lasted the whole show without fading.

I guess we’ll have to wait until VMworld next year and see if it’s still there to know for sure. One thing I do no doubt one bit is Pat’s commitment to VMware, I don’t think anyone could question that. VMware is lucky to have such a great leader and I could definitely see how he might want to replicate the mark he’s made on VMware onto himself.

You can read more about Pat Gelsinger in this blog post I did last year.

VMware’s new storage architecture, Virtual Volumes (VVols), has been part of vSphere for over 3 years starting with the vSphere 6.0 release. However the initial release did not support array based replication which VMware eventually provided in vSphere 6.5. That support came with a caveat though, while replication was supported via Storage Policy Based Management (SPBM), orchestration of replication operations was a manual and painful process and not supported with SRM. To do a test failover, failover or failback you had to use PowerCLI and write your own scripts to orchestrate those operations, not exactly something you want to be dealing with in a time of crisis.

VMware SRM was designed to make BC/DR a simple and easy process and allow automated orchestration of replication by simply pushing a button. SRM essentially takes over the ownership and control of array-based replication using a Storage Replication Adapter (SRA) provided by each vendor specific to their storage arrays. Therefore when you click a button inside of vSphere, SRM has full control of array replication, bring up VMs at the recovery site and eventually failback to the primary site when needed by reversing replication. Having no SRM support for VVols is a show stopper for most customers that don’t want to deal with complex and manual scripts to perform BC/DR operations. Note you may have heard that SRM does support VVols today but that is ONLY if you are using vSphere Replication.

Let’s first examine how we got here and why it’s taken so long for SRM to support VVols. Most of VMware’s products are in silos, meaning they are run by different product teams, as a result product roadmaps and interoperability are not always in sync across products. Every product team has their own priorities and it may or may not include immediate support for other VMware products. VVols development has it’s own product team and they are mostly solely focused on developing VVols. Support for VVols with SRM is completely outside of the VVols engineering team and solely within the SRM engineering team. It’s not up to the VVols product manager to decide on when SRM will support VVols, it’s entirely up to the SRM product manager.

For the last year or so we’ve pleaded to the VVols team for SRM support and we were essentially told sorry, bring us customers that want it and we’ll try to push them to prioritize it. This of course frustrated everyone as support for replication without support for SRM wasn’t a complete solution. VMware’s dead silence on the issue also didn’t sit well with customers and left many customers not wanting to use VVols. Several months ago we had a face to face meeting at VMware with Lee Caswell and the product managers for VVols & SRM and again pleaded for VMware to take action. At that time they did finally commit to supporting VVols on the SRM roadmap but we also requested that they communicate that to customers sooner rather than later.

Well VMware finally broke their silence and announced SRM for VVols right before VMworld in a blog post. I’m betting the timing on this was deliberate as last year VMware got really beat up over this at VMworld and probably didn’t want a repeat of that. Note the blog post is very vague on purpose and this is just an announcement and don’t expect support for it right away. The SRM team is working on something else big right now which if you were at VMworld you could of seen a tech preview of it. The announcement basically acknowledges that VMware clearly sees SRM support for VVols as a key priority finally so customers and partners can put their pitchforks away.

Note with this announcement VMware is not just telling customers that support is coming so they can plan for it and start migrating to VVols, it’s also putting partners on notice to inspire them to prioritize finishing their support for VVols replication. To this day, almost 2 years after VVols replication was supported in vSphere 6.5 their are still only 2 partners (HPE/Pure) that support it. I think some partners may not have prioritized VVols replication support as they saw their was no SRM support for it and figured why bother.

So how will this marriage of VVols & SRM look? For one thing their will be no more SRA’s to install and maintain into SRM. Control of replication will be handled natively through the VASA Provider without any external components needed. This will be a welcome change and greatly simplify using SRM with external storage arrays. How this will impact certification (HCL) is TBD, presumably it will be handled through the VASA certification process. Beyond that we’ll have to wait and see, I know this is a nowhere near a minor change and represents a big engineering effort for the SRM team. I’m fortunate to be working closely with the SRM product manager and engineering team on this and am excited to see one of the final barriers for customers wanting to use VVols disappear.