VCAP 6 DCV – Deploy Exam

Earlier this month I took the VCAP 6 DCV – Deploy exam to round out my VCIX 6.5 certification.  Previously, I mentioned how important I felt time management was during the VCAP 6.5 DCV – Design exam, well that exam had nothing on the Deploy exam.  I used the entire duration and probably could have used another 30 to 40 minutes to increase my level of confidence walking out the door.

I walked away leaving two questions unanswered because while I knew what was needed to answer them correctly, I don’t work in those aspects of vSphere enough to know how to accomplish them without digging around in the documentation.

Beyond that I had one question I knew was wrong, and another two I felt iffy about.

Regarding the experience of the exam itself:

It was incredibly stressful – imagine the stress of a huge meltdown in your environment at work.  Stressful right?  When the day is over you want to go home and sit on the couch with a beer.  Now take that stress level and subject yourself to it 27 times in a little over 3 hours, in an environment that you have never touched before, on someone elses computer, and you don’t have google (or coworkers/VMware support).   I took the exam first thing in the morning, and when I was done I was completely toast.

That said, the exam interface itself used the HoL format used in the online training courses and well the Hand on Labs.  I had no issues there other than that I just missed driving my good old Zenbook or Surface.

My biggest complaint about the whole experience was that it took over a week to get my results, which was more stressful than the exam itself.  Fortunately, when the email came the news was good news!

Content wise I felt it was a really good all around test of ability for a vSphere administrator/engineer/architect type person.  If I had to redo I’d focus on those areas of the vSphere suite that I don’t do every day.  i.e.  The stuff I do everyday or have focused on a lot in the past: powercli, HA, DRS, esxcli, iSCSI, networking I would flat-out ignore.  Anything related to those I either don’t need documentation or I simply need a reminder of the exact spelling of an advanced parameter or something similar.

Review the blueprint and drill into those things that you aren’t comfortable with. You don’t have to build to a level of mastery, but get yourself to the point where you know what needs to be done so you can accomplish it 70% to 80% on your own and you can find the last 20% to 30% in the documentation within 30 to 60 seconds – i.e. you understand the breakout of the vSphere documentation and you know the keywords you are looking for to find the section quickly in a PDF.

Lastly – the only real preparation I did for this exam was the solutions4crowds exam simulator.  The simulator was only 17 questions, but it provided a great mockup of what to expect and it was worth every bit of the $10 the owner asks for to utilize it.

Triathlon and me

The chief cause of  failure and unhappiness is trading what you want most for what you want now.

I will leave out my thoughts on Ironman Texas 2018, the race, both the positive and negative.  Instead I want to talk about my relationship with triathlon over the last couple years.   Aside from my relationship with my wife and my career, triathlon is the longest running activity I have engaged in in my life – this August it will be 15 years that I have been doing triathlons.  It isn’t surprising that it has had it’s ups and downs.

What I have struggled with these last two years +- is that it “started” with a great race and then fed into a series of poor performances, poor training and increasing frustration.  There have been a number of contributing factors:

  • Layoffs at work in 2017 = stressful work environment
  • Assignment to a new team/project at work getting to do awesome stuff = Very engaging job
  • 3 young children = Crazy Train
  • Paradoxical downward self-feeding cycle of triathlon related events = Very little excitement about training or racing.

The truth is in terms of life overall I can’t say that I have ever been more happy, but in terms of my pursuit of triathlon I have been incredibly unhappy, to the point where after Ironman Wisconsin last fall I contemplated if I really wanted to do another triathlon.

Early this year I signed up for Ironman Texas, ostensibly to get a Kona slot for this fall, which incidentally didn’t happen, but even after signing up I didn’t change my level of engagement or behaviors.  My engagement was so low that at one point my wife actually questioned if going to race Texas was the right thing to do.

  • Could I really have a race that would contribute to changing the direction that triathlon was going in my life?
  • Was I going to enjoy myself?
  • Was it fair to my family to make this solo trip without a chance of accomplishing the original purpose of it?

If I’m honest about it, the answer to all those questions at the time of the conversation was likely no, but for whatever reason I could not just not do a race that I had signed up for.  It was as if I needed  to do the race to tell myself what I needed to do.

In the lead up to the race I was excited and nervous about it – was I going to enjoy myself, would it be a positive day?

In the end the race was not great in an absolute sense but I had fun and for the first time in over two years I enjoyed myself and was 100% engaged the entire race.  It’s probably a bit premature to say that my love of triathlon is back and the furnace is roaring, but yesterday was a huge step in the right direction and I’m excited to see if I can rekindle it and find out if I can return to my level of fitness that I had just a handful of years ago.

VCAP 6.5 DCV – Design

A couple of weeks ago I sat the VMware VCAP 6.5 DCV – Design exam as part of the process of completing the prerequisites for submitting for VCDX.  I don’t have a lot of insight to add beyond the excellent post by vHersey.  I did want to jot a few notes to help relieve the dearth of information out there on this exam.

The things that really stood out to me:

  • Read the questions carefully
  • Practice, practice, practice identifying RCARs
  • Understand the difference between functional and non-functional requirements
  • On several questions it was easy to eliminate answers simply by being able to identify technical non-starters

Beyond that – manage your time well.  Overall I found the exam to be much less technical than the VCP 6.5 DCV exam, but the VCAP 6.5 DCV – Design was significantly more intense as I felt the devil was in the details of many of the questions and answers.

Hopefully the 6.5 Deploy exam will be released shortly so I can say on track for my submission goal date.


Let’s Build an image pipeline! (part 2)

Sorry for the delay in getting part two published, life had been busy the past week or so.  Today we are going to build upon what we covered in part one, namely the pieces of the code and/or things you need to adapt about the packer template file for it to be functional for your environment.

This is the second post of a planned 4 part series:

Continue reading

Let’s Build an image pipeline! (part 1.5)

As I was working on part two of this planned four part series about packer, I realized I forgot a crucial step in setting up Jenkins!  Due to part of our pipeline including deployment to an artifact repository and a vSphere environment, we need to create some credentials within Jenkins.  I have also created a friendly link to all parts of this walk through.  I will retroactively edit the links as the posts are written.

Continue reading

Let’s Build an image pipeline! (part 1)

Imagine a world where the next meltdown level vulnerability is announced and you have to patch your image 5 minutes ago. You  calmly run a script to force approve patches in your patch manager  and 45 minutes later the base template you deploy from in vSphere is updated and all new machines are based on the new image, all while you drink coffee and play the Block Game.  Sounds pretty cool right?  It’s definitely better than the old school way of:

  • Installing Windows or Linux to a new virtual machine
  • Performing your organizations steps to customize it
  • Install patches
  • Stage the system for customization
  • Shut it down
  • Mark it as a template
  • etc
  • etc

While the steps may very slightly depending on the exact platform you are leveraging: Linux, Windows, KVM, Azure.  Or maybe you’ve scripted some of the steps.  No matter where your process stands, at the end of the day this activity is a huge time suck, a huge potential for mistakes, and in no way contributes to a cloud way of working, which results in your platform looking like a pretty poor option to those desiring to do “cloud first.”  Not only that, how can you prove to yourself or auditors that a given image is properly built according to defined standards and controls?

There are potentially many tools out there to help automate the image build process, and like many things in life; some are better than others.  I’m about to walk you through the recipe I settled on and I think is best.  Your mileage may vary.
This is the second post of a planned 4 part series:

Continue reading

VCDX – my kind of stupid


I have always been one to pick stupid goals and then make it happen, fortunately for me as I’ve progressed in life from childhood to adulthood I actually learned that when you set an outlandish goal, you probably need to do things bordering on outlandish to accomplish them.

After gaining my MCSE 2003 certification, I pretty much swore off certifications.  To much work, not enough reward, etc, etc.  Then over the last 18 months or so at work I have had the fortunate opportunity to play a significant role in some incredibly awesome efforts: Always-on Horizon implementation, and SDDC/Automation PoC, and the design and implementation of a full on SDDC.  While shooting the breeze with a co-worker numerous times throughout this period we have discussed that much of the work we have executed for these efforts would make a hell of a VCDX design submission – for the track of our choice.

Continue reading

Blog 2.0

A log time ago, in a place not very far a way, I had an irregularly updated blog dedicated to tech stuff that I encountered at work and in my lab, which I unfortunately abandoned (the blog). Recently work has gotten exciting and at the same time I’ve been “forced” to rebuild my home lab, resulting in me deciding to revive said blog.

This is the story of that adventure.  There will be stories of intrigue, heartbreak, and magic involving dragons, progress bars, Nutanix, vSAN, NSX, Openstack, vRA, and lots of other buzzwords.



An important aspect about the SAFe framework, which I talked about a little last time, is accountability.  Namely, holding yourself accountable for accomplishing the things you have committed to.  This is done by defining clear acceptance criteria around that commitment.  The acceptance criteria describes why you are doing something, what you are doing, and what the end result of that will be.

Three weeks ago, I stated that the first thing I needed to correct was my bike fit and return me to a state where I am comfortable, confident, and that I have faith in my fit; all with a target date of the end of October.

Now that it’s November 4th, the important question is, did I do it?  Yes, thanks to Todd at TTbikefit, things are in a much better place.  I think there is still a bit of work to do in terms of me adapting to the position and revisiting it after some rides on the road, but we made a few surprisingly simple changes and things are now back to a position I feel comfortable and happy with.  It will be interesting to see how it progresses as I ramp things up over the next week or two after I end the break period this weekend with a 50k trail run.

So what’s the next step of action am I taking?  Much like last time, it’s pretty straight forward, primarily a return to normal training after a pretty relaxed 4 weeks post Kona.  So 3/4 swims per week, 6/7 runs per week, and 4 rides per week.  I am planning to focus pretty strongly on the bike with the goal of getting adapted to the position and making some gains in specific areas on the bike.  I’m going to focus on three key bike workouts most weeks, with running being nothing but easy running, and a typical swim program.

I am looking to judge myself not by absolute gains, but by my ability to execute those three key workouts each week, using the gains I’m looking for as not the success/failure point but as a light house guiding the way and using it and the calendar to tell me when it’s time to change focus.  Process, not outcome.

At this point there is not a need to do more than simply run, as while my running wasn’t “on” this year, it’s in my body, and a stronger bike will lead to a stronger run, regardless of absolute run fitness.  The primary target is 23 months away, so there is no pressing need to try to kill all the required birds with the first handful of stones.

Inspect and Adapt

“Fuckity fuck fuck.”

“This is such a disappointment.”

“I need to get off this bike.”

“I need a hug.”

These are all words that have come out of my mouth in the last 36 hours or so.  All of them the result of Ironman Hawaii and my poor performance.  I don’t want to dwell more than a paragraph or two on Kona;  If it isn’t obvious, I sucked.  Badly.


The race had three redeeming qualities

  • My swim wasn’t horrible, perhaps not quite what I was hoping for but squarely in the acceptable category.
  • It wasn’t a personal worst time.
  • I got to hang out with Ben Meer a lot.

Now that the pity party is out of the way, let’s get my hands dirty and go back to the subject of this post – Inspect and Adapt.  What am I talking about?  Inspect and Adapt, I&A, is a mechanism of the SAFe framework. Which is an exceptionally buzzword filled method for accomplishing things effectively in a modern Information Technology workspace.  It boils down to breaking larger projects/efforts (features) that can be completed in a “Program Increment” into smaller components that can be delivered in full at the end of each “iteration” of the Program Increment.  A typical duration of an iteration is two weeks, and a program increment could be twelve weeks.  During each iteration you partake in mid-block reviews and retrospectives.  The focus is on accomplishing the work you commit to and minimizing outside interference.  I&A comes at the end of each program increment where you review what worked, what didn’t, and make adjustments to your program to improve it and go at it again.

Now that I’ve totally lost you, I’ll stop the buzzword bingo.  Hopefully, some of those things I described trigger the words planning and periodization to pop into your head.  The number one goal of SAFe is to enable organizations to deliver expected, desired, and valuable outcomes in a predictable and cost effective fashion.  The same is true of periodization, and the associated planning process for training.

So back to Kona: I sucked. Again. I put in the work. Again. I didn’t get the outcome I expected. Again. Which means something went wrong in the process. (Again.)  What went wrong?

I am going to chalk it up to one thing:  riding the trainer too much.  Not for the usual reason that I don’t feel comfortable in the wind (I do), or I’m a panzie on downhills (I am), but simply that the bike fits differently on the trainer than it does on the road.   Most likely resulting from me setting my fit to be comfortable on the trainer, without frequent enough or long enough outdoor sessions to provide WTF feedback.

The hot spots on both my feet from last minute new shoes (not by choice), and my inability to tolerate my position on my bike led to me being just miserable.  And unwound my day.

Aside from Kona, I am really tired of my inability to deliver consistent performances.

I have been the top amateur at WTC events.  Twice.

I have gained eligibility for a USAT elite membership.  Three times.

I have finished high enough, at the right races, to earn a Kona slot. Eight times.

I should not consider 4:28 a good day.

I should not finish 44th in my division at USAT Nationals.

I should be ashamed I can’t qualify for 70.3 Worlds when that is the reason for putting my wife and child through ~22 hours of driving.

I am sick of the trend line going in the wrong direction, with a year or two between upticks.

I bitch and moan a lot on this blog interspersed with thoughtful and helpful posts, and to share stories of my success.  For better or worse a lot of those whiny blog posts center around a lot of similar things: Wah I suck or wah my bike fit sucks (I didn’t do a through review so there could be lots of other WAHs out there). With a lot of fluffy talk, then usually with a performance good enough to forestall serious action.

I need to fix these two problems, because not enjoying my bike and not having fun are killing my enthusiasm for the sport and are resulting in me questioning if putting my family through the stress of training for anything less than what I am capable of is worth it.  Both my family and myself do not deserve outcomes like yesterday for the effort we have put into it over the past year.  If I can’t do my family and myself justice come race day, I need to search elsewhere for self-validation.

Shit or get off the pot.  At 37 I have only a handful of years, if any to maximize my racing before it starts to taper off despite what I wish.

The first order of business is to fix my fit.  I’m going to set a goal of making this happen by the end of the month.  That gives me two weeks after I get back from Hawaii to get myself to someone and do something about it.  Most importantly I am giving myself a hard deadline to do something, with a short enough target window that I can’t have some lucky coincidence leave me thinking action doesn’t need to be taken or it can be delayed.  Accountability.

After that we will have to inspect and adapt to fix the consistency of performance issue; Weighted Shorted Jobs First.