Author: James Cruickshank

VCAP-NV (3V0-643) Exam Experience

~ James Cruickshank

I have been working with NSX everyday for the last year or so and decided it was time to get the VCAP-NV (3V0-643 exam) out of the way, unfortunately I decided to put myself under a load of time pressure as I booked the exam for about 3 weeks after I started to study… hence the multiple blog posts every night!

I have already sat and passed the VCAP-DCA so had a reasonable idea what the format of this exam might be like i.e. too many questions and not enough time ? The exam system is based on the familiar VMware Hands on Lab interface which is a huge improvement over the last setup in my opinion. There are a couple of tips that are called out at the start of the exam which are well worth doing (setting the manual to float, changing the screen resolution, maximising the screen real estate as much as possible etc.) as the exam kit, at least in the exam centre I was, is still a single tiny monitor! Not what I am used to!

Continue reading →

NSX-T – Physical Requirements

~ James Cruickshank

I’ve been really lucky over the last few weeks getting to do some deep dive workshops on NSX-T and will be blogging a lot about the good the bad and the ugly over the next few weeks (really good timing for “Blogtober” right?!)

First things first the documentation, for the moment at least, is a little bit on the light side. VMware are obviously working on the documentation as I am starting to see some more become available in the public domain but it certainly wasn’t as well documented as other GA products.

This leads onto my first topic, as I think it’s quit a big one!

I’m going to post about the new routing and switching technologies/methodologies used in NSX-T as they are VERY different from NSX-V in the next few days but for now let’s assume there is a need to move away from the well known and loved Distributed Switch (start looking up the Opaque Switch). Put simply you can’t run a vSphere Distributed Switch on a KVM host, the price for delivering a Hypervisor agnostic SDN solution means we need to introduce a new type of virtual switch.

No big deal right?

Continue reading →