VCDX Workshop VMworld Europe (Barcelona)

Prior to attending this VMworld a VCDX Workshop session was generously provided by VMware

Luckily my hotel is 5 minutes away from Porta Fira Hotel ;-) *the force is strong with this one*, still I had to wake up at 06:00AM to get in shape so that not to be sleepy while words of wisdom are flowing through out the session.

The workshop was delivered by both Aidan Dalgleish @AidersD and Joe Silvagi @VMPrime and it was a great great workshop and it was packed with good questions and a lot of insight on the VCDX process, here-under are the notes that I have taken from the session (without any order for the matter):

Please do note that the following notes are my interpenetration of what I understood from the delivered slides along with the discussions that took place at the workshop and I might have understood something wrong, so if you find anything wrong please post a comment and I will for sure correct it.

• Make sure you follow the blueprint closely and mark your points of strength and weakness based on it.
• Form study groups.
• Record videos about yourself presenting and see where you have blabbered or got some points delivered in-confidently.
• Read your design, find the weak spots and prepare for the panelists questions about them.
• Always have critical thinking mode enabled.
• Challenge best practices even if its a VMware KB, for a best practice might not be in favor of your design choice and might be in favor for another.
• If you’re planning for VCDX, it is better to start with DCV as it will help you build up for the additional VCDX designs (DT, Cloud, and NV).
• Don’t stuff information into the document just to beef it up with text (text that you don’t have much knowledge about) thinking it will gain you points, for you will be asked about these random information and not answering properly won’t be in your favor.
• Submitting with a vSphere 6 design is acceptable for VCDX 5.
• A design requirement is how it shall work.
• A design constraint is how to make it work.
• Always think about the operational aspect of your design.
• Evaluate if a single point if failure happens to fail, what is the impact (leverage the pessimist in you).
• Troubleshooting scenario is about seeing your thought process and critical thinking, we all get the aid of Google for information and no one knows everything.
• Both troubleshooting and design scenarios are not about finishing within time but rather about seeing your process of handling them.
• The design document should be business requirement driven.
• The design document should be mission critical suitable.
• The design document should have a managed environment in thought.
• The chance of a complete fictitious design to pass is around 5%.
• Always see things in the eyes of a real world requirement.
• A real world design gives you the advantage of actually seeing the test plan in action, eventually supporting your answers when defending on what works and what doesn’t.
• The testing document is about what would be your tests and what is the expected results.
• Ensure that your submission is free of technical inconsistencies.
• Your presentation should be a 10 minutes executive level based presentation.
• Your slides should act as shortcuts to information existing on the design document, information that you can tap just by reading a short bullet point.
• Know your design document inside out, memorize it even with the spaces and commas, KNOW YOUR DESIGN.
• When your thinking about an answer to a question that has been asked, speak your mind as it will let the panelists tap into your thoughts and know how well your thoughts are oriented to extract information.
• The panelists always do try to give you chances to gain more marks, don’t think of any question as a challenge to fail you, they want you to PASS and everything they do is for your aid so don’t take things personal and make sure you do hear what comes out of their mouths and interpret it correctly.
• When doing the design scenario try to divide your time into 50% asking questions and 50% drawing your design on the whiteboard.
• When doing the troubleshooting scenario there are questions that will help you get started (What changed? Was it working before?).
• Partner kits are not design documents for VCDX, use them to get a general thought about how real world designs go but do make sure you have yourself in the document, your design, your thoughts, your skills.

And that’s it, hopefully these points will give you an insight about what the workshop was about.

(Abdullah)^2