NSX Uncovered – Part 2, Solution Overview

Network virtualization is by no means a new concept for VMware. Think about it for a moment — wherever vSphere (or any other VMware T1 or T2 hypervisor) has been implemented, a virtual switch exists and connects guest VMs to the physical world. That’s more than 500,000 customers globally, millions of vSphere hosts, and many more millions of virtual network ports backed by a standard (vSwitch) or distributed virtual switch (dvSwitch). In fact, if you count the network ports provisioned by vSphere and logically assigned to VM nics, one can argue that VMware is one of the top datalink providers on earth. Okay, perhaps that’s a stretch, but you get my point! VMware virtual networks have existed just about as long as VMware itself. And since the very beginning, there has been no shortage of innovation. The vSwitch has evolved in many ways, leading to new technologies, increased scope and scale, distributed architectures, open protocol support, ecosystem integration, and massive adoption. Over the years VMware has continued to introduce new networking technologies through organic maturity and strategic acquisition — ESXi platform security, dvSwitch (and associated services), vShield, vCloud Networking and Security (vCNS), etc. — and leveraged 3rd party integration into partner solutions, such as Cisco’s Nexus 1000v (a solution brought to market by tight collaboration between VMware and Cisco).…

NSX Uncovered – Part 1, Introduction

VMware’s Network Virtualization Platform, NSX, is an immensely powerful technology that can transform a datacenter’s infrastructure and streamline network service delivery across the enterprise. NSX’s scope, scale, and capability will easily impress techies, CCIE’s, and IT stakeholders alike. NSX changes the topology of a traditional hardware-bound network by eliminating the dependency on all that “intelligence” baked into proprietary hardware. Instead, the logic and associated services are delivered through a software control plane. Separating the control and data planes effectively reduces the physical network to a glorified IP packet forwarder.

With that said, it is also important to understand that NSX is not a re-write of your network and the fundamental concepts it is built upon. The abstraction of the logic from the physical underpinnings is a modern approach to designing, building, and servicing network architectures, but the fundamentals — the protocols, tools, concepts, etc. — are still at play. And for that reason, i’m often baffled when I enter into a debate with a “traditional” network engineer about the ins-and-outs of physical vs. virtual networking technologies like NSX. What I quickly realize is they are not defending the concepts or technology, they are defending their skill set. It’s a fear or reluctance of straying from what they know best.…

Scaling VSAN: Adding a New VSAN Host

In my previous post, VMware VSAN Meets EZLAB, I highlighted the implementation of VSAN into my vCloud lab. At the time of writing, 1 of 4 my vSphere hosts was down for maintenance and was not added to the VSAN cluster. Now that it’s back online, I thought I would share the experience of adding a new VSAN host…and another 2.25TB of capacity.

Here’s a “before” shot — 3 hosts configured with 6.13TB total capacity…

Step 1: Add the host to the existing VSAN cluster: I’m pretty sure I don’t have to review how this is done. Once added, configure all settings to match the other hosts in the cluster…in my setup I’m using a dedicated pNIC and vmkernel port (vmk1) for all storage traffic.

Adding new host to the vSphere cluster

The local storage of the new host, a Dell R610 box, is configured identically to the other
three — 1 x 256GB SSD + 3 x 750GB SATA drives. And since it is
identical, that also means I had to deal with the fact that the PERC 6/i
controller does not support JBOD. So, I stepped through the work-around to identify the SSD as such…

before…the SSD show up as “Non-SSD”


“esxcli storage…” command executed on host



the SSD is now recognized as an SSD drive


Step 2: Enable VSAN Service on the vmk port…

Configure vmk for VSAN traffic

Step 3: Disk Management…

Since my VSAN cluster is configured to “Manual” mode, adding the new host’s disks to the cluster takes an additional step.…