NSX | Breek Een Been

Nested NSX Upgrading Nsx 6.0.5 to 6.1.2

Wed, 07 Jan 2015 18:59:02 +0200

In earlier blogposts I described how I build my nested NSX lab. This environment was based on NSX version 6.0.5 and in this post I will briefly show you how you can easily upgrade your NSX environment, in this case we will upgrade to version 6.1.2. Luckily the documentation of VMware is up-to-date which should make this proces pretty easy. Let’s start with the NSX Manager. NSX-Manager Before we actually start, make sure your filename of the upgrade bundle ends with tar.gz, otherwise the upload will fail. I had to rename the file; from: VMware-NSX-Manager-upgrade-bundle-6.1.2-2318232.tar _to: VMware-NSX-Manager-upgrade-bundle-6.1.2-2318232.tar.gz

In the upgrade page, you’ll find another upgrade button in the top right corner, click it and in the new screen, select the upgrade file.

After choosing the right file, click continue, now you have to wait, while the file is being uploaded.

If everything wen well, you should see a screen confirming the upgrade from 6.0.5 to 6.1.2 and a question about enabling SSH. I enabled SSH and clicked upgrade.

After the upgrade you will be redirected to the login page, login and check the version number in the upper right corner.

NSX Controllers

The next step is to upgrade the controllers, log in to the vSphere webclient and go to Networking & Security and click the Installation option on the left side. Make sure the Management tab is selected and you should see on the right side “Upgrade Available”, click it and click yes, that you are willing to upgrade the controllers.

In the screen below the manager, you see that the controller is being upgraded.

If everything went fine, the upgrade status column should dissappear and the new version is displayed, also the upgade available link in the upper rigt corner should be gone.

Host upgrade

Go to the “Host Preparation” tab and you should see that there is an update available.

Click update near the host that you want to upgrade. The host is getting upgraded and will be rebooted when the installation is done. However if you have just one host in the cluster, like in my lab environment, this will need some manual interaction. This is because VMware has no other hosts where the workload can be migrated to.

Go to host & clusters and you will see, that the host need a reboot.

I simply shut down the VM and rebooted the host, I started with the one in the compute cluster. For the upgrade of the host in the management cluster I temporarily moved the compute host to this cluster and let it run the NSX Manager, till the second host was also upgraded. These steps took me a while. I also increased the memory of the NSX Manager to 6GB it seems the upgrade made it a bit slower. If everything went well you should see this eventually.

NSX Edge upgrade

The last part of this upgrade is the NSX Edges, this means the distributed router and the edge. As mentioned in earlier posts in my opinion the distributed router should gets his own section. Click the appliance you would like to upgrade, order doesn’t matter and select from the action menu “Upgrade Version”.

It is nice to notice, that the upgrade of the Edge is an actual new installation;

This is it, when all the NSX Edge devices (including the distributed router(s)) are up-to-date the upgrade is doen. As you can see upgrading a NSX environment consist just of a few basic steps, the only challenging step is the host-preparation, but that is due the lack of resources in my lab set-up. In production this would be easier.

Nested Nsx Vmware Nsx on Intel Nuc Lab Setup Part 3

Mon, 29 Dec 2014 09:37:17 +0200

In the previous two posts I described how to set-up a nested ESXi environment on the Intel NUC and how to install and configure it for NSX. So in this post I assume everything is installed and configured and we can actually start deploying a network.

Logical Switch

If not already, go to “Network & Security” and click on “Logical Switches”, click the green plus sign, to add a Logical Switch. I used the following settings:

Name: App-Tier
Description: Application Tier
Zone: LAB-Zone

This is it, we have created a working logical switch, however to see if it actually can switch, we need to put some workload on it. To show that the communication within the Logical Switch is completely independent of the underlying network, I put the two VMs on this switch, within a completely different subnet than already used.

IP1: 172.20.20.2/24
IP2: 172.20.20.3/24

We are going to deploy two VMs I used Debian for this, but you are free to use whatever you want, as long as it can do IP. This is what I configured:

Name: App-VM1 / App-VM2
OS: Debian 7 - 64bit
vCPU: 1
MEM: 512MB Ram
IP: 172.20.20.2 / 172.20.20.3
Subnet: 255.255.255.0
GW: 172.20.20.1

Make sure you deploy a VM on ESX01 and one on ESX02, also connect them for now to the pgCompute1 and pgManagement port-group.

When both VMs are deployed, go to “Logical Switches” and click on “Add VM”, select the two VMs, select both the NICs and finish the task.

Configure the VMs with the appropriate network settings and do a ping test to each other. If everything went well, you should get a reply.

Before we continue it is nice to take a look at the controller, to see what information is stored here and get an idea how the actual traffic flow is working. You can log-in to the controller with SSH and username “admin” and the password specified earlier. With the following two commands you can list the VTEP interfaces and the MAC-addresses. The number 5000 is the segment ID (VNI = Virtual Network Identifier) assigned to the logical switch. Which can be found in the webinterface under Logical Switches.

nvp-controller # show control-cluster logical-switches vtep-table 5000
VNI      IP              Segment         MAC               Connection-ID
5000     192.168.5.11    192.168.5.0     00:50:56:62:a3:86 2
5000     192.168.5.10    192.168.5.0     00:50:56:66:dd:df 7

nvp-controller # show control-cluster logical-switches mac-table 5000
VNI      MAC               VTEP-IP         Connection-ID
5000     00:50:56:99:d0:77 192.168.5.11    2
5000     00:50:56:99:6b:d9 192.168.5.10    7

In my case the MAC addresses of the VM’s are.

App-VM1: 00:50:56:99:6B:D9
App-VM2: 00:50:56:99:D0:77

You could also use the following command, to see the ARP table, remember this like normal switches has a time-out, so when it is empty initiate a ping or some other traffic.

nvp-controller # show control-cluster logical-switches arp-table 5000
VNI      IP              MAC               Connection-ID
5000     172.20.20.3     00:50:56:99:d0:77 2
5000     172.20.20.2     00:50:56:99:6b:d9 7

As you can see in the mac-table, there is a relationship between the MAC address and the VTEP-IP. What it actually says is that if App-VM1 sends something to App-VM2, the traffic will be encapsulated (VXLAN-header), with the destination IP (192.168.5.11) of the VTEP connected to the host running the VM. After the host received the traffic, it is being decapsulated and sent to the VM, so the VM’s don’t know anything about how the traffic is handled and won’t see any difference between a virtualized or a traditional network.

Distributed Router

Another neat feature of NSX is the distributed router, this not only means you can route traffic, but the neat thing about it is, that this can be done on “host”-level. This means that when two VMs are running on the same host, but in different subnets, the distributed router (remember installed VIB) will route the traffic in the kernel, so the traffic won’t have to leave the host! To create a distributed router, go to “Network & Security” and click on “NSX Edges”. (If you ask me, they should make two categories, “NSX Edges” & “Logical Routing”, this would make a in my opinion lot more sense) Click the green plus sign and select logical distributed router.

Next specify a password and Enable SSH acces.

Specify the “Management_and_Edge” cluster.

Connect the management interface to the “pgManagement” port-group and specify an IP, in my case 10.10.11.126.

Add an interface and connect it to the “Logical Switch” - “App-Tier” and specify an interface, in this case 172.20.20.1 [!

When done with step 4 it should look as follow.

We can skip the HA configuration and continue, when satisfied with the settings, click Finish.

The first thing we want to do is enable routing between two logical switches. Therefore go to Logical Switches and create a second one, named: “Web-Tier”.

Deploy (or clone) a new VM and connect it to this “Logical Switch”.

Name: Web-VM1
OS: Debian 7 - 64bit
vCPU: 1
MEM: 512MB Ram
IP: 172.20.10.2
Subnet: 255.255.255.0
GW: 172.20.10.1
Cluster: Compute

Since we didn’t connect the distributed router to the Web-Tier Logical Switch, there is no gateway and no communication possible between the App- & the Web-Tier. The App-Tier is connected and you can try ping the gateway 172.20.20.1 from one of the App-VMs, this should work. Go back to NSX Edges en open the distributed router we created, select the Manage tab, click on Settings and select interfaces. Now click the green plus sign and add the Web-Tier and create an interface with IP 172.20.10.1.

Before you click OK, open the console of the Web-VM1 and start a ping to one of the App-VMs, now click OK. Immediately after the configuration, you should get a response on the pings.

It is important to know that the logical router instance (VM) is in this example purely for configuration of the distributed router and that traffic won’t go through it. When sending traffic to App-VM1 which is on the same host, the traffic won’t leave the host, but is routed at the kernel. If traffic is send to App-VM2, the traffic is routed on the host of the Web-VM1 and send (on the App-Tier Logical Switch) to the other host, like it was L2 switching. The last part of this post is bringing data outside the virtual world, there are two ways of accomplish this. The first one is bridging and the second one is routing. I won’t go further into bridging, but what it simply said does is, connecting a VXLAN to a VLAN.

Edge Services Gateway

Best practice is that we use an Edge Services Gateway (ESG) for connection with the outside world. This means that the Logical Router will forward the traffic to the ESG and the ESG will route the traffic to the physical world. This is just one of the many functions the ESG can do, it can also NAT, Loadbalancing, basic firewalling, etc. VMware likes to call it a “swiss army knife” due the roles it can fulfill. Between the Logical Router and the ESG we will have a so called transit network, for this create a new Logical Switch and name it Transit.

My uplink is in a different VLAN, so I created a new portgroup pgUplink, but if your network is flat or you want to (mis)use the management port-group, this is no problem. Make sure, when you create an additional port-group, do this at the Management and Edge (cluster) Distributed Switch.

Go back to the NSX Edges and click the green plus sign, similar to the deployment of a Logical Router, however now we choose Edge Services Gateway.

Fill in the credentials and select the Management and Edge Cluster for deployment. A Compact deployment for this LAB is sufficient.

Now the most important part, create the interfaces. Chooste “internally” for the Transit. I will use 172.16.10.0/24 as transit subnet and the Edge will get .1 and the Logical Router (later on) .2. In the Uplink subnet I have 10.0.0.0/24 and will use 10.0.0.1 for the Edge. My physical router has 10.0.0.254, so this will become my default gateway.

Leave all the further settings default and finish the wizard.

Now open the just deployed ESG and go Manage, Routing, (for now) we will create static routes to the Logical Router we created earlier. Add the following two routes for the App and Web tier, by clicking on the green plus sign.

172.20.10.0/24 - 172.16.10.2
172.20.20.0/24 - 172.16.10.2

If you added both routes, click on Publish Changes.

The next step is to add the 172.16.10.2 interface to the Logical Router, and set the default gateway for the Logical Router to the ESG. Open up the settings page for the Logical Router and add the interface.

Go to routing and set the default gateway under Global Configuration to the ESG, make sure to Publish Changes when you are done.

Now almost everything is set, however when you will test to communicate with the outside world, you will see that it will fail, there are two more (small) steps to take. First, make sure the outside world, your router or cliënt has a route to the new Web and App subnets. I first tested it of my desktop client, which has an IP in 10.0.0.0/24. I added a specific route to the WebVM.

172.20.10.2/32 - 10.0.0.1

Now the very last step is to check the firewall of the ESG, by default it only has a rule which accept traffic, which has a source VSE (I assume this stands for vShield Edge). For this lab we will add a rule, which allows any traffic. Go to the ESG and click on firewalling and click the green plus sign. It will by default create a rule which accepts any, any, any :). Don’t forget to publish the new rule.

Now you can test and everything should work! Now we have set-up a very basic and simple lab environment which runs NSX pretty well. Even despite the limited resources, the Intel NUC has proven itself to be capable of handling the load and give a decent lab experience. I think this lab is a very good starting point for further testing and learning with NSX and probably some more posts will follow concerning NSX configuration, for me it will hopefully help to eventually get my VCIX-NV. I hope you had fun and please let me know if you have any further questions, ideas or suggestions.

Nested Nsx Vmware Nsx on Intel Nuc Lab Setup Part 2

Sat, 27 Dec 2014 09:20:49 +0200

In my previous post I described how to create a nested ESXi environment, connected to a vCenter, this as a preparation to run eventually NSX. In this post we will build further on the basic set-up we created in part 1 of this series. At the end of this post we will have the NSX installed and the network prepared for all the cool things NSX can do.

Distributed Switch

Since the NSX vSwitch is based on the “distributed switch”, this is what we are going to create first on the two clusters. We will make two distributed switches, named;

dsMgmtEdge
dsCompute1

Go to your (LAB) vCenter and go to the networking tab, right click on the Datacenter and click on “New Ditributed Switch”, for now the following options are sufficient.

Number of uplinks: 1
Network I/O control: Enabled
Default port group: Create a default port group
Port group name: pgManagement / pgCompute1

Before we can actually add hosts to the distributed switches we created, we need to add the VLAN tag to the newly created port-groups. Therefore select the distributed switch, choose the manage tab and make sure settings is selected. Select the port-group and click edit settings. Under the VLAN settings, choose VLAN and enter the appropriate VLAN ID. (if you don’t work with VLANs you can skip this step)

Now we have created the distributed switch and configured the port-group, we need to add the hosts to it. Right click on the distributed switch and click on “Add and Manage Hosts”, we want to add the host, select the appropriate host.

Make sure both the “Manage physical adapters” and “Manage VMkernel adapters” are both checked. We will move the vmnic0 to the uplink of the distributed switch.

Also move the VMkernel adater (vmk0) to the new port group.

If you screw this up, it is pretty easy to start over by accessing the console of the ESXi and in the settings, choose “Network Restore Options”.

NSX Manager

Finally we can start with some real NSX stuff. The first step is the installation of the NSX Manager. Go to hosts and clusters, right click the “Management & Edge” cluster and choose deploy OVF. Point to the NSX Manager OVA. Select Accept extra configuration options.

Read & accept the EULA, pick a name (i.e. LAB NSX Manager). At the Network setup make sure you choose the new “pgManagement” port-group. At the “Customize template”, set some passwords and make the network configuration.

VSMgmt: pgManagement
Hostname: LABNSXManager
Network 1 IPv4: 10.10.11.111
Network 1 Netmask: 255.255.255.0
Default IPv4 Gateway: 10.10.11.1
DNS server list: 10.10.11.3, 8.8.8.8
Enable SSH: checked

The settings I didn’t mentioned I left blank.

Click finish and have a bit of patience. Before we can power up the NSX manager we need to do something about the resources which are by default quite heavy and we simply have not that many resources available on our LAB set-up. Edit the VM hardware settings with the following values.

CPU: 2 (instead of 4)
Memory: 4GB (instead of 12)
Memory reservation: 0 (instead of 3GB)

Power up the NSX manager and if everything went well, you will be able to visit the NSX page with a few minutes, https://IPAddress and you can log in with the username “admin” and the password specified during the deployment.

Before we continue, I noticed that the resources are a bit short, cause after 17 minutes, the NSX Mangement Services wasn’t started and it would eventually turn out to take 19 minutes. As you can see the Memory is in full use and also on the ESXi host we can see this, this is an indication that we need to increase the memory of the ESX02 (the host of the Management & Edge) cluster. Cause it is also going to run the NSX Controller(s). Luckily this is a virtual ESX host, so extending the memory is quite easy, I doubled it at this moment to 8GB. I didn’t increase the memory of the NSX Manager, since this is a LAB, I don’t care if the start-up takes a while, as long it will run fluent enough to do some testing.

vCenter integration

NSX has a tight integration with vCenter, at this moment it is an 1 on 1 relationship, which means for every vCenter, you need one NSX Manager. Log in to your just deployed NSX Manager and click on “Manage vCenter registration”, click on edit and enter your vCenter information.

After clicking ok, trust the certificate and within a few seconds it should say that is is successfully connected.

Now we are going back to our vCenter, if you are already logged in, log out and log in again. The first time it can take a few minutes, cause it will configure itself for NSX. If everything went fine you should see a new option in the menu on the left, named “Networking & Security”.

Prepare the hosts

The next step is to prepare the host, NSX will install a couple of VIB’s into the hosts, knowing;

Logical Routing
Distributed Firewall
VXLAN

Click on the new “Networking & Security” option and go to “installation”, click the “host preparation” tab. It will show the clusters available within the vCenter.

Click the install link in the column “Installation Status”, do this for both clusters. After the installation it should say “ready” on the particular host and the version for the cluster.

Controller

Now that the hosts are ready we can start deploying the controller(s), normally you would deploy at least 3 controllers, but in this LAB we will start with just one, mainly due resource restrictions. The controller is the control plane of the environment and will keep three primary tables.

ARP table
MAC table
VTEP table

Go back to the “Management” tab of the “Installation” settings and click on the green plus sign, below NSX Controller Nodes. Fill in the following.

NSX Manager: 10.10.11.111
Datacenter: Datacenter
Cluster: Management_and_Edge
Datastore: NAS
Host: 10.10.11.102
Connected to: pgManagement (select distributed switch)
IP Pool: ClusterIPPool - Create one
- Name: ClusterIPPool
- Gateway: 10.10.11.1
- Prefix Length: 24
- Primary DNS: 10.10.11.3 -> Your own DNS server
- Secondary DNS: 8.8.8.8
- Static IP Pool: 10.10.11.120 - 10.10.11.125

Password: Pick Something

Click OK, it will start deploying a controller and this can take a while.

VXLAN

The last step in the preparation of the NSX environment is the VXLAN preparation, VXLAN is the tunnel protocol which makes sure every host participating in the NSX environment is able to communicate with each other. First we going to create an IP pool, with the IP adresses for the VMKernel adapters serving the VTEP (VXLan Tunnel End Point). Therefore click in the left bar on NSX Managers and select “10.10.11.111”, make sure the “Manage” tab is selected and click on “Grouping Objects”, select IP-Pools and click on the green plus sign. To show that communication between the hosts is really independent of the underlying network, I created a separate subnet without a default gateway (although specified).

Name: VXLAN-VTEP
Gateway: 192.168.5.1
Prefix Length: 24
Static IP Pool: 192.168.5.10-192.168.5.20

Now go back to the installation, “Host Preparation” tab and in the column VXLAN click “configure”.

Leave everything default except:

VLAN: 5
IP Addressing: Use IP Pool
IP Pool: VXLAN-VTEP

Click ok and wait a few seconds, although it could give an error (didn’t find out why yet), the error will dissappear after a refresh.

If you go to the distributed switch of one of the cluster you should see something as follows:

Now we need to specify the VXLAN segment ID’s, therefore go to the “Logical Network Preparation” tab in the installation settings, select “Segment ID” and click edit. Fill in the following segment ID pool, which should be more than enough for this lab environment.

Segment ID Pool: 5000 - 5999

We don’t have to enable multicast, since we are running on ESXi 5.5 hosts.

The last part is to create a “Transport Zone”, this will tell NSX which clusters are able to communicate with each other. Click on “Transport Zones” and click the green plus sign.

Name: LAB-Zone
Control Plane Mode: Unicast
Clusters: Select both

Now we have everything prepared to do some actual networking with NSX. This is what we will be doing in my next blog post.

Nested Nsx Vmware Nsx on Intel Nuc Lab Setup Part 1

Wed, 17 Dec 2014 08:52:50 +0200

While the VMware Hands-on Labs are extremely cool and useful, I found it always very learning-full and nonetheless fun to build my own labs. To keep it fun and keep down the noise and powering costs I decided to buy some Intel NUCs, which have a good price tag and are very low on energy. Last couple of months I’m very interested in VMware NSX and it is time to try-out running this in my own Lab and on one Intel NUC, which means not much resources but I’m wondering if it can be done and hopefully work well enough to play around. In the next coming posts I will show you the steps I take to get things working, so you can follow me on this journey. This first part will concentrate on how to get the nested environment up & running. One of the biggest downsides of the Intel NUC is that it only has one NIC, which makes it difficult to run all needed parts and another caveat is that chances are that you will lock-out yourself. Luckily ESXi can run itself, we call this a nested environment. Below you see a very abstract picture about the set-up we are going to create. As you can see I choose to let the nested ESXi servers interact directly with my NAS (Synology), mainly to save resources and time. If you want a complete nested and virtualized environment including storage you are of course free to do so.

Nested NSX abstract

The blue components are the more physical parts of this environment and the actual lab is more located at the green components. I assume you have already running ESXi on your Intel NUC (or other system), if not below two good links to get you started.

When you have ESXi running on your NUC, we can create a nested environment on it. I will start small, cause I have no idea, how the NUC will handle the load and it will be easy to add another node in the feature (also a good test case). How to create nested ESXi servers isn’t new, but I will cover shortly how I’ve done it. A small note lots of older blogpost write about the vhv.enable feature, this isn’t necessary in ESXi 5.5 cause it will be set to true by default.

Network

This has nothing to do with NSX yet, but it will enable our nested hosts to communicate with the outside world. We are going to create a TRUNK port-group, so that we can use in the future different VLANs to segment the traffic, this however requieres that the connected physical switch also supports VLANs. Don’t worry if not, than this all will probably still work, however I didn’t tested it. Go to the host, networking configuration and add a port-group, with the following settings.

VLAN ID: ALL (4095)
Security - Promiscuous mode: Override Accept
Security - MAC address changes: Override Accept (optional)
Security - Forged transmits: Override Accept

Nested ESXi servers

Deploy a new VM, I have my ESXi connected to a vCenter environment, this is not the vCenter we will discuss later and is running on another NUC. So I will use the web interface. The steps taken can also be done on the traditional GUI, the only difference will be the HW version, 10 for the WUI and 8 for the GUI. Use the following settings:

Pick a VM name, for the sake of simplicity I use “ESX01” and “ESX02”
OS Family: Other
OS Version: Other (64 bit)
CPU: 4 (I started of with 2, but quickly changed to 4, needed for some componentens (i.e. Controllers))
CPU - Harware virtualization: Enable
MEM: 4 GB (enough to get started) (In part 2 I increased the memory of the ESX02 to 8GB)
HD: 1GB
Network: Trunk port-group (1 nic is enough to get started)
CD: Mount the ESXi installer

Now we created the VM, we can boot it up and start the installation, which is really a next, next finish job. When the installation is done, this can take a several minutes we start configuring the host. Open the console and press F2 and after entering your password go to “Configuring Management Network”. If you have a trunk port, don’t forget to enter the VLAN ID. Give the host an IP address, subnet, gateway and optionally for now some DNS settings. For me the IP’s are.

ESX01 IP: 10.10.11.101/24
ESX02 IP: 10.10.11.102/24
Gateway: 10.10.11.1

Since this is a lab environment I will enable the SSH console, you can do this under “Troubleshooting Options”.

Before you exit the console test if you can reach the host, a simple ping test would be sufficient. The last thing we will need to do for now on the new hosts is adding the storage. For me this is a simple NFS share on mine Synology. Go to the host, storage configuration and add the NFS storage.

Before continuing, make sure both hosts are deployed, have storage and are reachable.

vCenter

The last part of this post is about deploying the vCenter appliance, which is sufficient, for running NSX. Deploy the vCenter 5.5 OVF, I used the following settings.

Name: LAB-vCenter
IP: 10.10.11.110/24
GW: 10.10.11.1

(Since the last Chrome update, the vCenter plugin is broken, didn’t fixed it yet)

After the OVF is deployed I decreased the memory to 4GB, which is in my experience enough for a fluent experience in a LAB environment. Start the vCenter VM, as you can see on the console, you should be able to access the initial configuration on https://IPAddress:5480 and login with the default username “root” and password “vmware”.

After logging in, accept the license (of course first read it). I choose for “configure with default settings”, after clicking next and start, it will configure itself, but this will take a while. When the configuration is done, the last change I make on the configuration is that the password of the admin will not expire.

Now we are done we can actuale access the vCenter interface by going to https://IPaddress:9443/vsphere-client

We don’t worry about license keys for now, so you can simply ignore this message or close it by clicking the cross sign on the right. Go to vCenter and click on hosts and clusters. Now we start by creating a new Datacenter. Click on “Create datacenter” and if you want give it a name, you can also leave it default “Datacenter " and click ok. Now we are going to create two clusters, called;

Management_and_Edge
Compute

Click on create cluster and give it the desired name, we can leave HA and DRS off. You can create the second cluster by right clicking on the Datacenter. When both clusters are created we need to add the ESX hosts to the appropriate cluster. We add ESX02 to the Managment & Edge cluster and the ESX01 to the Compute cluster.

Right click on the cluster and select “Add Host”. Fill in the IP of the host, on the next page the username and password of that specific Host, leave the other settings default.

Do this for both hosts, when you have done this, your environment should look as follow.

For now we are done, we have setup a basic nested environment on which we will go install and configure NSX. When you are bored and can’t wait for the next post or just want to optimize your environment, consider the following actions, these are all optional and not necessary to install NSX, also these steps can be taken on a later time.

Optional but nice!

My Way to VCP NV

Wed, 03 Dec 2014 19:20:37 +0200

Today I passed the VCP-NV exam. It was my first VMware exam and it was my second try. The first one was directly after the “VMware NSX: Install Configure and Manage” course and I really didn’t know what to expect, but with the discount given to do the exam at VMworld (Barcelona) I thought let’s give it a shot. Unfortunately I came just a few points short of passing the exam at that time, but it gave me an good idea about what I could expect the next time. Below you will find my tips and resources to make a good chance of passing the exam.

Get a decent understanding of NSX and its components.
- If you have any chance follow the course (install, configure, manage), it will give you good introduction and understanding of the whole NSX environment.
- It is also a good idea to do the “Hands On Lab” and you don’t necessary have to follow the lab!
- Make sure to study the (draft) design guide very well, it will cover all the important aspects. The first official version of the guide is (imo) very limited.
Make sure that you also know the features of the vSphere standard switches and even more importantly the vSphere distributed switches. Also know which features came with which version of vCenter, something which is important. One of my shortcomings in the first attempt For this although I’m just halfway, the book “ networking for VMware administrators” is really a recommendation!
Make sure you know the upgrade paths, especially of vCNS, VMware will test thorough on this. Also one of my shortcomings in the first attempt
Make sure you know VMware recommendations, especially for the physical architecture. e.g. L3 leaf/spine architecture.
At the actual test, make sure to read the questions and answers very well, sometimes it is in the minor details which defines the correct or best answer.

Below you find some great resources in my opinion: Reading

Videos vBrownbag - VCP-NV Objectives:

Objective 1:
Objective 2:
Objective 3:
Objective 4:

IPSpace Webinar - NSX Architecture

http://cms.ipspace.net/bin/list?id=NSXArch

(Not so free) Pluralsight - NSX Intro (10 day trail available)

http://www.pluralsight.com/courses/table-of-contents/vmware-nsx-intro-installation