Tag Archives: certification

VCDX: Defense Preparation Timelime

The VCDX defense preparation phase includes both slide deck creation and common tasks such as skill updates, potential question creation, alternatives, deep dives, skill transfers, mock defenses and study group meetings.

When is it best to start? Depending on your mental state at the time of design document submission, right away. I took 7 days off until I started creating my presentation and working on all the other items.

Never mind if you don’t know if the design was accepted. Just start. Worse case scenario is that you spent some hours on a presentation that you will use the next time you submit the design.

It will get really hard if you know 3 weeks before the defense that you are going to defend and the presentation is still a New button in PowerPoint.

As for which item to address first I focused on the presentation first and got a good template and the layout just right while getting feedback from my mentor and the study group.

Then I addressed my weakest skills, added to my presentation and did further study group sessions, including design mocks and troubleshooting/design scenarios.

As for a specific timeline of each item, I actually went and did the thing my brain allowed me to do. Some nights I just couldn’t do a single slide in the deck. Then I logged into Pluralsight and just watched some network videos. It was all about change of pace (and learning method; Read-Interact-Listen-Watch).

The time I spent for my defense preparation were about 216-260 hours. Why the gap? Cause I only noted 216 hours and those number did not include all the time I spent going over Quizlet and reading books.

Here is a graph of the time spent on preparations:


And here is a graph of the time spent each day on preparations:


Why did I use time to account for the time I spent on the project? Cause I could. And I’m a data junkie. I just really love looking at graphs with lots of connected piece of information. Don’t judge. :)

This time did not include the time I spent each day learning my Quizlet cards (during transit to and from work and also whenever I could) and reading various books for skill update. That would add about 40 hours to the total number.

At the start of the journey I scheduled how much time I would spend on the project. The following graph shows the difference between these two:


I planned for 270 hours, but was only about 20 hours short if the off-screen hours were taken into account.

So do start as soon as you can preparing because every hour you can put in will help in the defense itself.

VCDX: Design Scenario

The 75 minutes for the defense section just finished, now a short break while the panelist gets the next part ready, The Design Scenario, where you get to show how you would approach a specific set of business and technical requirements. Fast.

The 30-45 minutes alloted to this part go by quick. Quick really isn’t fast enough to begin to describe it. But there is no need to have fully functional environment ready for deployment either.

As far as I know the goal of the defense scenario is not to see how fast you can design, its more about how you approach the design requirements and how you verbalize your thought process. But then again you can cover more ground if you can do it really quick :)

The VCDX design scenario will give you access to 1-3 slides containing a set of requirements and constraints, both business and technical. Also you might get access to number for an existing environment that need to be accounted for in the design. Your role is to ask additional questions for more information about the problem that the fictional customer is facing, additional business requirements or even a set of constraints.

The VCDX blueprint explains this section like this:
Respond interactively to a presentation of requirements and constraints to show the ability to produce a design which satisfies a customer’s needs.

Real world design sessions take hours, even tens of hours of different meetings with a different people to be able to fully understand the requirements for a complex environment. This is usually done with a set of specific guidelines in place, what should be asked, who to ask and who will approve the final conceptual design. The design scenario is somewhat that process but only in 30-45 minutes and with less emphasis on a fully designed solution in the end. Process is key here and to be able to cover as much as possible the guidelines need to be become more streamlined as well.

Rene Van Den Bedems blog post about the design scenario http://vcdx133.com/2014/06/16/vcdx-design-scenario-strategy/ is a great resource that has a lot of good recommendations to do just that, and I used them as the basis to create a whiteboard layout to be able to show the process as fast as I possibly could.

Here is a picture of the layout:


On the left there are specific notes and recommendations and below that is the process itself. So the plan was to be able to go through that process as fast possible.

On the right are potential questions to ask regarding a specific technology stack to be able to fulfill any requirements.

The whiteboard layout has several sections:

  • On the left there is the conceptual list with possible design goals, success factors, requirements/constraints/assumptions(if any)/risks. This does not mean that these topics will be on the slides themselves as you might need to ask around for them.
  • Next to that is the design characteristics part where the plan was to use specific markings to be able to mark each design decision taken with a specific characteristic.
  • Below those two were the design decisions themselves and those were supposed to be classified based on blueprint sections. I never even got close to be able to categorize them. Still the logic around it seemed to make sense at the time.
  • The rest of the whiteboard contains a logical design diagram with specific room for storage and network and additional room for management layers. Design choices were located near the corresponding stack.

I practiced drawing the layout on different sizes of whiteboards just to be ready, and so that I could draw it as fast as possible and knew what should go where.

The plan was to have something remotely similar to that during the scenario itself. Due to the nature of the design scenario I got I never got close to being able create it though. But I had a plan in regards for the process and the layout I wanted to use to show my design skills and I think that made a difference.

Practice a design scenario mock with the study group at least 3-4 times before the defense day. Once with the process in front of you, the other time with nothing but a whiteboard. Always a whiteboard. And coffee. Always coffee.

Some additional pointers:

  • Plan for dual site designs as well. Space becomes scarce when drawing everything twice.
  • Not all designs are just about the infrastructure, the workloads are important to.
  • If you have access to two whiteboards please do use them both.
  • Talk, talk, talk. Tell the panelist what you are thinking, and why. Requirement->Design decision with justification and an alternative if applicable. Short explanations, no technology deep dives explaining a specific feature in vSphere.

And finally here are some other helpful resources for the design scenario:

And also many of the VCDX’s post their recommendations and experiences about the design scenario in their “experience post”, so you can find a detailed list of such posts over at Gregg Robertsons blog: http://thesaffageek.co.uk/vsphere-5-study-resources/vcdx-5-preparations-and-resource-page/

VCDX: Troubleshooting Scenario

This is the last part of the journey. Now you only need to troubleshoot a problem as methodically as possible and you have reached the finish line.

Let me explain.

Most real life troubleshooting sessions with customers have a single goal, a solution. And preferably with an analysis on root-causes, and recommendation to mitigate the risk of future incidents. This needs to be unlearned to a degree for the troubleshooting scenario.

The VCDX troubleshooting scenario will give you access to 1-2-3 slides containing a predetermined scenario and on those slide a predetermined amount of information is given. Your role is to ask the right questions to get better information to analyse the fault and explain why you asked about it or addressed with a change request to show expert level knowledge.

The VCDX blueprint has also a pretty good explanation:
Respond interactively to a presentation of a customer problem to show analytical skills and deep product knowledge, especially an understanding of how the components work and interact.

Here is an example:

  • What virtual SCSI controllers does the VM have?
    • The reason I’m asking is it sometimes can account for specific performance degradation on high IO machines as well control how large the IO queue that particular disk has.
  • How is the fiber channel zoning configured? Is it using single initiator-single target or something specific?
    • The reason I’m asking is that arrays that do not have ALUA capabilities tend to experience path thrashing if the zoning is incorrectly configured or the Load Balancing option within the Storage Kernel is misconfigured.

As you can see this will soon become very hard to cover everything so its best to read the slides and decide on a specific technology stack to focus on. Then move to the next even if you went for the “right” one in the beginning. Make sure to propose a plan of action and explain why that specific set of changes should be done.

I found that Rene Van Den Bedems method that he explained in this blog post extremely helpful: http://vcdx133.com/2014/06/20/vcdx-troubleshooting-scenario-strategy/

As for the troubleshooting process it worked best for me to start from the VM side and troubleshoot towards the physical infrastructure.

I took the method in Rene post and personalised it to a degree. Since I had to methodically troubleshoot I thought it would be best to create a whiteboard layout to use in the scenario.

Here is a picture of that layout:


I need to explain the picture or it will not make any sense… Not my favorite kind of picture but it is necessary.

On the left there are locations of ESXi and vCenter specific logs (from Rene’s post). Of course this is just to read it again and again over the course of the troubleshooting mock scenarios. This of course can include track (DT-NV-Cloud) specific log locations.

Below that is box including lots of recommendations from various sources (including Rene’s post).

The large box with the colored boxes is the whiteboard diagram. The boxes include the technology stacks of core vSphere, Management, Storage, CPU/RAM Scheduling, Network. A similar layout for other tracks could include a larger management box with the corresponding management components (vCloud/vCNS, Horizon components, vRA components etc). The left hand side included a Q&A for initial questions, Notes if any and Change Log if I requested some changes to be done to the environment.

The plan was to at least have a something similar to that layout during the scenario itself. In my scenario I never had a chance to draw all of the boxes, not even close. But I used the layout during the troubleshooting mocks and I think it helped with the methodology of the process. I also practiced drawing the layout on a smallish whiteboard so I could at least draw it quickly.

The right side included boxes that are again from Rene’s blog (which I hope you have at least read by now since I’ve mentioned it 4 times now :) ) and they include potential investigation paths to follow.

Also I recommend doing at least 3-4 Troubleshooting mocks before the defense cause the first I went through I just froze.  You will not want that to happen on the defense day.

Also reading past experiences and other people recommendations were also extremely helpful:

http://www.yellow-bricks.com/2010/03/22/vcdx-design-and-troubleshooting-scenarios/ http://fbuechsel.eu/2014/09/08/vcdx-troubleshooting-mock-scenarios/