Deploying NSX part 1 – NSX Manager

The blog is a natural progression from setting up my 2 node vSAN homelab, although I have now added a third host and done away with the witness appliance (technically my third host is now the witness, but I gain another compute node). The end result of this blog is for a VM to sit on a NSX Logical Switch, using an IP address/subnet that is not defined on my physical network apart from a route pointing it to the VMware environment, to be able to route packets in and out of the NSX environment. While it doesn’t sound like much, when I first started experimenting with NSX I found myself scratching my head how to get packets in an out, and I’m ashamed to admit I do have the job title of ‘network engineer’ somewhere on my CV! But for every hurdle there’s some learning to be done! Now I am only going to cover a single VM at present, however the same method will apply to any number of VMs and logical switches. Once that one VM is in an working, it lays the foundation for experimenting with more advanced features that NSX can offer, which I hope to write about some point in the future.

I arrived at wanting to write this in order to help others out, as well as provide a bit of documentation for myself which I can refer back to. In addition, I am currently studying to sit VCAP-NV Deploy and while the VMware Hands On Labs (HOL) are a fantastic resource, I think it’s nice to have something you can install, break and then fix ad infinitum. If you’re working with physical infrastructure it’s also a great bit of experience plugging it all together and making it work. Plus, working on your own lab doesn’t limit you in anyway whereas the HOLs can be a bit linear. That’s not to so don’t use them, you absolutely should, but if you have a homelab and VMUG subscription, you may as well have a play with VMware NSX and all that it offers if either for self-interest or if you’re pursuing certification. This is part 1, which covers the installation and setup of VMware NSX manager in a lab environment. I’m breaking it into different parts as otherwise it would be a very long read.

This two part blog will cover the installation of NSX as well as setting up a single Logical Switch for the Web tier. Repeat the process for the application and database tiers. In the future I intend to write about how to use micro-segmentation between the Tiers in order to practice the security element that NSX offers. I think this part is pretty important. If you thought having the ability to ‘stretch’ a VLAN between two sites with basic networking kit was cool, micro-segmentation should grab your attention as it has done in the market.

What I am intending on doing eventually is to have the three tiers (web, app, db) on different logical switches and then play around with micro-segmentation. I’m doing this because it most represents the HOL environment and I guess the labs used on the VCAP Deploy exam. The VM template for the tiers I am using is the VMware Photon template guide from the VMware HOL Blog found here.

Before I end up writing an essay, let’s get to it. There are some pre-requisites you should have in place before proceeding:

  • Minimum of two hosts, both added to a vCenter servers’ inventory.
  • vSphere Enterprise Plus and NSX licenses. If you’re learning VMware, I’d highly you get yourself a VMUG subscription.
  • A Virtual Distributed Switch (vDS) configured correctly.
  • A physical networking device capable of routing, (static is fine). You can use a virtual router, but that is beyond the scope of this blog.
  • The switch which connects the hosts must support a minimum MTU of 1600. I would highly recommend Ubiquiti UniFi switches.

As above, it’s a good idea to ensure that you have migrated your VM port groups over to Distributed Switches. While vDS’s are overkill (and expensive) for a small number of hosts, NSX logical switches require a vDS to operate, so you can’t run NSX without them. Once they are set up, deploy the VMware NSX OVF template. I am using version 6.4.4 as it’s friendlier with the HTML5 client within vCenter, which is at 6.7U1. I’m wanting to concentrate on the HTML5 client as ‘it’s the future’, although it’s always good to have experience in the Flex client, too.

Step 1 – Download the VMware NSX Manager OVF and deploy it to your environment like any other OVF. In this blog I am using version 6.4.4 which brings further HTML5 client features. The NSX Manager is the centralised management component of NSX and it provides the ‘single pane of glass’ UI within vCenter to administer VMware NSX.

Step 2 – Name the VM appropriately and place it on your cluster. Here I am using my vSAN cluster which was created in my vSAN witness blog. Then press next and review the details before accepting the license agreement.

Step 3 – Choose an appropriate datastore. I’m deploying it on my vSAN Datastore.

Step 4 – Select an appropriate port group. I’m using my management port group which is on VLAN 2. I would suggest in a homelab to put it on the same VLAN as your vCenter server to keep things simple.

Step 5 – Set up the appliance passwords and relevant IP settings. I’m only using IPv4 at home but you may wish to also configure IPv6. The IP address here will be used for accessing the web interface after the OVF has deployed.

Step 6 – Review the details and proceed if happy. This is the last chance you’ll have before having to start again if anything is not quite right.

Step 7 – After 5 minutes or so, browse to the IP address which you set in step 5. Since it’s using a self signed certificate, you may have to accept the security risk within your browser of choice.

Step 8 – Once you’re logged in, we need to head to ‘Manage vCenter Registration’. Without this, the appliance is pretty much useless.

Step 9 – Unless you’re running on some crazy fast hardware, the appliance won’t be fully running which you can see by the warning message below. Wait for the message to disappear then connect it to your vCenter server. You’ll need your administrator@vsphere.local credentials. Set up the Lookup Service URL to that of your vCenter server, then bind it to the vCenter server on the second stage.

Step 10 – Within the HTML5 client, you may have to log out and in again for the Networking and Security shortcut to appear. Be patient, it can take a few minutes.

That’s it for part one. In the next part we’re going to deploy the controller cluster, prepare the hosts before finally configuring the logical switches and NSX Edge (DLR in my case).

2 thoughts on “Deploying NSX part 1 – NSX Manager”

  1. I’m really ignorant to this type of situation. Have so very much to learn about ESXi, but super curious about NSX, despite barely knowing more than the absolute basics of my way around the two nodes I have, which are currently operating independently — as they are quite a bit different in horsepower.

    Node 1: Cisco UCS-C240-M3S (Xeon E5-2665 (x2), 192GB RAM), running ESXi 6.5 U1
    Node 2: HP Z420 (Xeon E5-1620, 64GB RAM), running ESXi 6.7

    Have spun up a vSphere VM a couple of times, one regular install, one Photon OS vCSA to try and get a little familiar with it, as these are similar environments as what we were running at work, but have found myself essentially using the two completely independently with the HTML client. I was hoping to get both upgraded to 6.7 for the feature complete HTML5 clients, but not running anything critical that would require DR or HA, vMotion and such. Mostly curious what I’m able to achieve in this type situation, or what the best approach would be for general learning purposes. The HP Z420 was originally intended to be a NAS box, but with 24 bays across the front of the Cisco box, I’ve got sufficient local storage which is MUCH faster, as you can image, while being limited to Gbps LAN. Not quite in the budget currently to get greater than Gigabit speeds, although I’ve seen some creative setups with two-three node 10Gbps dual NICs. But I digress, now I’m just rambling.

    My point being, could i trouble you for your expertise and a possible recommendation on the best way to approach this setup. I only lasted a week with running FreeNAS on the HP before completely converting it to another ESXi node. I found out late in the game that it’s better to have multiple (3+) smaller/more reasonable nodes than a single workhorse (and single point of failure), as I’ve found myself currently working with.

    Wonderful post sir, I’m looking forward to going through it a second time to absorb a bit more.

    1. Hi Harry, thank you for your message. Unless you’re buying more hardware, you have more than enough oompf in that UCS server, so I’d recommend setting up a nested environment. William Lang has an excellent automation script to deploy it all from scratch here:

      I would then use to second node to have a second nested environment and maybe look into creating a linked vCenter environment.

      While automation is cool, sometimes it might be better for learning to do it all the hard way and by hand. Having never set up a nested environment, I can’t really help but I’m sure it’s been covered somewhere!

Leave a Reply

Your email address will not be published. Required fields are marked *