As a tenant administrator or business group manager, you can create entitlements to manage user and group access to services, catalog items, and resource actions within business groups, and to assign approval policies to entitlements.You must specify the entitlement information first. This information includes the name and status of the entitlement and the business group whose selected users and groups are entitled to request the services and catalog items and perform the actions listed in the entitlement.Next you identify one or more services, catalog items, and resource actions that entitled users can request. You can do this in any sequence and combination.

Login to your vCAC Console using Tenant administrator credentials. Navigate to Administration ->Catalog Management ->Entitlements

Configure the entitlement with the below options:

1.Provide the name and description for this Entitlement

2. Change the status to Active.

3. Since I have created only 1 business group called “IT”, It is automatically populated.

4. Add users and Groups who will have access to this entitlement and click on Next.

Add the entitled service, Catalog items and Actions for this entitlement.

I have added the “Windows Services” Which we have created in last post as entitled Service. Add “Windows 2003″ as entitled catalog items. Add the Entitled Actions and Select the Actions Users can perform on this.

Select the Machine from the Type and Select the Actions for the entitlements.

That’s it. Entitlement is created. We need to create and manage entitlements to control access to catalog items and actions. We will take a look at VM provisioning request in upcoming posts. I hope this is informative for you. Thanks for Reading!!!. Be Social and Share it in social media, if you feel worth sharing it.

This is will be final part of the vCAC 6.0 Installation Service. We are done with step by step procedure to configure all the vCAC infrastructure deployment and configuration. We are going to see how to request a New Machine using vCAC Console which is entitlement for the user from the user Console. This will be final goal for the all the steps which we have configured in vCAC. vCAC provides automated provisioning of the Virtual Machine in just a single click. Your VM will be ready after few minutes.

Login to vCAC Console using end user credentials. In my case My end user of IT business group is IT-user1. I am going to login to vCAC console using IT-user1 credentials.Under Catalog tab, You will be able to see the Catalog items which are entitled for the user under Service Catalog.  Click on Request to request for the virtual machine.Provide the  information for this New Request and Click on Submit.

That’s it. Our request has been submitted Successfully.

Within few Minutes, requested Virtual Machine will appear under Items tab. You will able to manage the requested VM from the User Portal. That’s it We are done with the vCAC installation series. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.

ESXTOP – My favorite tool which really helps me in all the time during vSphere performance troubleshooting. Esxtop is a command-line tool that gives administrators real-time information about resource usage in a vSphere environment.  It saves me quickly with the real time stats with exact information. It’s been more than 6 years i spend with vSphere administration. Still I am learning more everyday about ESXTOP. ESXTOP is available in two ways. Either through the ESXi Shell or through the vSphere Management Assistant(vMA) with the command RESXTOP. resxtop can be used remotely to view the resource utilization of ESXi hosts from VMA.

It is always a tough time when working with the ESXTOP because of large data displayed in the screen.  ESXTOP height of the screen is limited in what it can display. You will really not be able to scroll down the screen of ESXTOP. It is always trouble for me when i am looking for specific objects which is hidden in the ESXTOP display because of the screen is limited and also you cannot scroll the screen down to your specific object like VM or LUN. I have faced mostly when i am trying to see the my storage device performance statistics. Unfortunately there is currently no command line option for esxtop to specify specific VMs/ LUN’s that need to be displayed. In the below screen, I am really not seeing the LUN’s which I really want to see the stats for and also I will not able to page down/Scroll down the ESXTOP screen to see all the LUNs.

Now, you can export the current list of worlds and import it again to limit the amount of VM’s or LUN’s shown.There is a option available with ESXTOP called “export-entity” and “import-entity”. Using this you can export the current list of worlds and import it again to limit the amount of VM’s or LUN’s shown. Let me Explain in detail.

ESXTOP -Export-Entity:

When I type Esxtop and Switch to “u” will display the all the storage LUNs which are connected to the ESXi. I am not able the see the stats of the LUN which i am really looking for. Let me use the Export-Entity option.

esxtop -export-entity <Location of the file>

Example:

esxtop -export-entity /tmp/Luns-limitedview

Open the File using Vi command and comment out with # whichever stats not needed.

Vi <location of the file>

Example:

vi /tmp/Luns-limitedview

In My case, I don’t want to see the status of all the Disk adapters and all vmnic’s . So i have commented out both object  ”vmhba0″ and “vmnic0 & vmnic1″ with the symbol “#”  infront of it and save the file and exit.

ESXTOP -Import-Entity

In the above step, we have commented out the unnecessary data with symbol “#” in front of the object. You need to execute the below command.

esxtop -import-entity <Location of the file>

Example:

esxtop -import-entity /tmp/Luns-limitedview

I want to see the stats for my storage adapter.When i swicth to disk adapter view in Esxtop by pressing “d”. It displays the stats only for the 2 adapter “vmhba1″ and “vmhba2″. It doesn’t display the stats of “vmhba0″ which i have commented out earlier.

Also When i see the network stats in esxtop by pressing “n”. It displays the stats only for “vmnic2 & vmnic3″. It is not displaying the stats for network adapter “vmnic0 & vmnic1″ which i have commented out earlier.

That’s it. In the similar way you can comment out the unnecessary objects like VM, LUN’s, Network adapter, Disk adapter as specified above and limit the ESXTOP view to only view the statistics of objects which is really needed by you. I hope this post will really help in troubleshooting the vSphere Performance using ESXTOP. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.

Favorite command Next to ESXTOP for many VMware administrators will be ESXCLI. It provides you with the handfull of information, which you are really looking for.You can manage many aspects of an ESXi host with the ESXCLI command set.You can run ESXCLI commands as vCLI commands or run them in the ESXi Shell in troubleshooting situations.You can also run ESXCLI commands from the PowerCLI shell by using the Get-EsxCli cmdlet. Below are the Available namespaces which are available as part of ESXCLI command.

With ESXCLI, the output of the command is formatted using a “default” formatter based on the type of data being displayed. However, you can easily modify the output by using one of the three supported formatters: xml, csv and keyvalue by using the command “ESXCLI –Formatter” option.

Formatting the Output of ESXCLI:

Let’s focus on how to use the ESXCLI command to get the output formatted. In may use cases, We may want to import the output data to Excel Spreedsheet to send the report to your manager or even it can be used during maintenance.  Default output of esxcli command will not really allow you to properly copy the formatted data  for excel because of default formatter. Even you may also not interested with the all the fields of your ESXCLI output. You may be interested with some specific fields in the ouput.

Let’s consider the output of the command: esxcli network nic list

You  may not really interested in the all the fields of the output. You really want the output with only 4 fields (Name,Driver,Speed & MTU). Let me use esxicli formatter option.

esxcli –formatter=csv –fromat-param-fields=”Name,Driver,Speed,MTU” network nic list

Example 2:

I have total of 24 CPU’sThe below command gives me output for around 5 pages but i am only interested with ID, Brand,Corespeed  & ClockSpeed.

esxcli hardware cpu list

Let use the esxcli –formatter option to pull only the interested fields (ID,Brandd,Core Speed & Bus Speed)

esxcli –formatter=csv –format-param=fields=”ID,Brand,Core Speed,Bus Speed” hardware cpu list

You can simply use the Text import wizard in Excel and import the data and separate the fields with Comma.

Data is simply exported into Excel spreadsheet.

That’ it. We are done with the formatting of the ESXCLI command output. Similarly you can use the formatter option to format the output of  various ESXCLI commands. I hope this is informative for you. Thanks for Reading !!! Be Social and share it in social media, if you feel worth sharing it.

This post may be useful for the VMware Administrators who is running small lab environmnet. They may be running a small setup of one or two ESXi host with one windows VM which is acting as a Domain Controller. As VMware admin’s ,we are so much used to work with vSphere windows client against vSphere web Client. Have you tried to installing vSphere client on Domian controller machine. By default, that is not possible. When we try to install vSphere windows client on Domain Controller, We may end up with the error message” vSphere Client fails with a message saying the as a requirements the management station has to be running XP SP2 and not a domain controller”. For people running Lab environment, Will not prefer to install another windows VM just to install vSphere client. In that situation, You can make use of this OS SKIP command to install the vSphere client on Windows Domain controller as a workaround.

Below is the error message you will receive, when you try to install vSphere client on Windows Domain Controller machine.

 You can use an advanced switch when installing VI client on Domain Controller . You can launch the installer from a command line and in this case there is a switch to use which skips the OS check. Here is the command to use:

VMware-viclient.exe /VSKIP_OS_CHECKS=”1″

That’s it. vSphere client installation will complete without any error. You cannot use the same switch to install Web client because Web Client cannot be installed on Domain Controller. I hope this is informative for you. Thanks for reading!!!. Be Social and share it in Social media, if you feel worth sharing it.

It’s been long time, i am thinking to post about  VMware NSX .Let’s start from this post. I am so impressed with VMware NSX. Let’s discuss in detail about Step by step procedure how to deploy and configure Various NSX Components in  along with the tips to troubleshoot the issues related the NSX deployment.

NSX -Overview

VMware NSX is a software networking and security virtualization platform from VMware that delivers the operational model of a virtual machine for the network. Virtual networks reproduce the Layer2 – Layer7 network model in software, allowing complex multi-tier network topologies to be created and provisioned programmatically in seconds. NSX also provides a new model for network security. Security profiles are distributed to and enforced by virtual ports and move with virtual machines. NSX supports VMware’s software-defined data center strategy. By extending the virtualization capabilities of abstraction, pooling and automation across all data center resources and services, the software-defined data center architecture simplifies and speeds the provisioning and management of compute, storage and networking resources through policy-driven automation. By virtualizing the network, NSX delivers a new operational model for networking that breaks through current physical network barriers and enables data center operators to achieve better speed and agility with reduced costs.

NSX includes a library of logical networking services – logical switches, logical routers, logical firewalls, logical load balancers, logical VPN, and distributed security. You can create custom combinations of these services in isolated software-based virtual networks that support existing applications without modification, or deliver unique requirements for new application workloads. Virtual networks are programmatically provisioned and managed independent of networking hardware. This decoupling from hardware introduces agility, speed, and operational efficiency that can transform datacenter operations.

Logical Switching: Layer 2 over Layer 3,decoupled from the physical network
Logical Routing: Routing between virtual networks without exiting the software container
Logical Firewall: Distributed firewall, kernel integrated, high performance
Logical Load Balancer: Application load balancing in software
Logical Virtual Private Network (VPN): Site-to-site and remote access VPN in software
VMware NSX API™: REST API for integration into any cloud management platform like vCAC, Openstack,etc.

NSX Core components:

There are 2 Major components that make up this solution to provide the final piece in VMware’s SDDC vision. NSX Manager and NSX Controller.

NSX Manager

The NSX manager is one of the touch points for the NSX for vSphere solution. NSX manager provides a centralized management plane across your datacenter. It provides the management UI and API for NSX. Upon installation, the NSX Manager injects a plugin into the vSphere Web Client for consumption within the web management platform. Along with providing management APIs and a UI for administrators, the NSX Manager component installs a variety of VIBs to the host when initiating host preparation. These VIBs are VXLAN, Distributed Routing, Distributed Firewall and a user world agent. The benefit of leveraging a VMware solution is that access to the kernel is much easier to obtain. With that VMware provide the distributed firewall function and distributed routing function in kernel. This provides extremely in kernel function processing without the inadequacies of traditional user space or physical firewall network architectures.

NSX Controller

The NSX controller is a user space VM that is deployed by the NSX manager. It is one of the core components of NSX and could be termed as the “distributed hive mind” of NSX. It provides a control plane to distribute network information to hosts. To achieve a high level of resiliency the NSX Controller is clustered for scale out and HA. Will discuss about NSX Controller in detail in Upcoming posts.

Basic Pre-requisites for Installing NSX:

Kindly ensure you have prepared your environment with all the Pre-requite before installing NSX.  Below are few items you need to have before proceed with NSX installation:

1.  A properly configured vCenter Server with at least 2 cluster. I have 3 Cluster (1 Management Cluster & 2 Compute Cluster)
2.  For NSX, vSphere Web Client is must. You cannot Manage NSX components from vSphere Client.
3. You will need to be using Distributed Virtual Switches (DvSwitch) NOT Standard vSwitches.
4. For NSX 6.1 , Prerequisite is to have VMware vCenter Server 5.5 or later
5. VMware ESX 5.0 or later for each server. If you are NOT running vSphere 5.5, you will need to have your physical switches configured for Multicast. Unicast Supports from vSphere 5.5.
6. Properly Configured DNS and NTP server is required. Ensure all the components ESXi, vCenter and NSX Manager are in sync time with configured NTP servers.
7. if you added ESX hosts by name to the vSphere inventory, ensure that DNS servers have been configured on the NSX Manager and name resolution is working. Otherwise, NSX Manager cannot resolve the IP addresses.
8.  Ensure you have all the required System Resources (CPU and Memory) available in your cluster to deploy various NSX Ccomponents like NSX Manager, Controller,etc.
9.  Ensure you have Configured the your Distributed Switch with MTU more than 1600.

Take a look at the VMware Page to understand System Requirements for NSX.

NSX Installation Steps Sequence:

The components of the NSX platform are configured in the following order:

Graphic Thanks to VMware.com

1. Deploy NSX Manager from OVF
2. Register NSX Manager with the vCenter Server providing IP address and credentials and the NSX Manager instance connects to the vCenter Server system. The NSX Managerinstance enables the NSX components in the VMware vSphere Web Client.
3. The vSphere Web Client is used to deploy the NSX Controller instances through NSX Manager.
4. After NSX Controller instances are deployed, hosts are prepared by using NSX Manager to install the VIBs on the ESXi hosts in the cluster.
5. After the components are installed and deployed, you define the logical networking components, such as adding distributed routers and creating firewall policies.

We are going to Discuss in detail about each step discussed above in this NSX Installation Series. I hope you will enjoy these posts. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.

NSX manager provides a centralized management plane across your datacenter. It provides the management UI and API for NSX. Upon installation, the NSX Manager injects a plugin into the vSphere Web Client for consumption within the web management platform. Along with providing management APIs and a UI for administrators, the NSX Manager component installs a variety of VIBs to the host when initiating host preparation. These VIBs are VXLAN, Distributed Routing, Distributed Firewall and a user world agent. The benefit of leveraging a VMware solution is that access to the kernel is much easier to obtain. With that VMware provide the distributed firewall function and distributed routing function in kernel. This provides extremely in kernel function processing without the inadequacies of traditional user space or physical firewall network architectures.

NSX LAB Design:

Below is My NSX Lab Design which i am going to use for this Installation Series of  posts.

VMwareArena’s  NSX Lab Topology:

4 ESXi Hosts:

2 Hosts for Management Cluster Running Infrastructure Virtual Machines (Esxi-01 & ESXi-02):

VM’s Running : NSX Manager, NSX Controllers,vCenter Server(vCSA), Distributed Router VM, NSX Edge VM.

2 Hosts for Compute Cluster (ESXi-comp1 & ESXi-comp2) for Running 3-Tier application VM’s:

VM’s Running: Web-Svr-1.Web-Svr-2, App-svr-1 & DB-svr-1

1 Windows Server:

Windows Server running the below roles:

• Windows Domain Controller
• Router (Routing & remote Access)
• Microsoft ISCSI storage

 4 NSX Logical Switches:

• Web-Tier
• App-Tier
• DB-Tier
• Transit-Network

1 Logical Router (LDR-001)

DLR (Distributed Logical Router):NSX Logical Router Connect all 4 Logical Switches (Web-Tier, App-Tier, DB-Tier & Transit-Network). Logical Router Provides routing between the VM connect to these 4 Logical Switches.

1 NSX Edge

NSX Edge Provides routing between 4 Logical Switches to Physical network(HQ Uplink) via Logical Router

Deploying NSX Manager:

Select the option “Deploy OVF Template” from your ESXi host. You will get OVF configuration options only when you use vSphere Web Client to deploy the NSX Manger OVF. Browse towards your NSX Manager OVF File and Click on Next Select the checkbox “Accept extra Configuration options” to configure additional OVF configuration options.  Click on Next

Accept the License Agreement and click on Next.Specify the Name for your NSX Manger VM and Select the folder or datacenter location to deploy the virtual machine.

Select the datastore to deploy the NSX Manager Virtual Machine and click on Next

Select the port group to connect the NSX Manager VM and click on Next.

Specify the password for CLI admin and CLI privileged Mode for NSX Manager virtual machine. Click on Show next to specify other options.

Specify the Network properties (Hostname, IPv4 address, Netmask Default gateway, DNS and NTP settings. Click on Next.

Specify the NTP server list and enable SSH also. Kindly ensure you have valid NTP servers configured in your environment to provide time synchronization for all the servers. Time sync is one of the Important requirement.

Review the Settings configured and Click on Finish to start the NSX Manger OVF Deployment.

You can Monitor the Progress of NSX Manager OVF template from Recent tasks.

 Once “Deploy OVF Template” task completed successfully. You can see the VM “NSX Manager” deployed under the selected Cluster. Power On the Virtual Machine.

 Once OVF deployment is completed, Access the NSX Manager Admin portal from your web browser

https://<ip or Hostname of NSX Manager>

That’s it. We are done with deploying NSX Manager. Let’s discuss about configuring NSX Manager and NSX Manager Integration with vCenter Server in upcoming Posts. I hope this is informative for you. Thanks for Reading!!. Be Social and share it in social media, if you feel worth sharing it.

In the Previous Post, We have discussed in detail about NSX Manager Overview, Pre-requisites to install NSX and along with NSX LAB Design & NSX Manager deployment. In this post, We are going to Configure the integration between NSX Manager and vCenter Server. Integration of NSX manager with vCenter Server is the important task which we need to perform before deploying NSX components. NSX Manager Creates a management plane for the NSX environment. Once the integration between NSX Manager and vCenter is completed, NSX Manager provides Network and Security plugin which is available with vSphere Web Client to manage the NSX environment. It exposes a RESTful API for consumption by a customer or a cloud management platform. Access the NSX Manager

Access the NSX Manager Admin portal from your web browser

https://<ip or Hostname of NSX Manager>

Login with username “admin” and password “specified during NSX Manager OVF deployment”

You will be able to see the NSX Manager Virtual Appliance Management home page. Click on “View Summary” to view the summary of NSX service status.

You will be able to see the status of the NSX Manager Services (vPostgres,RabbitMQ & NSX Management Service, SSH service). Wait until all the service become “Running” status before proceed to next step.

We need to integrate NSX Manager with your vCenter Lookup Service and vCenter server. Please ensure you have configured similar NTP settings for your NSX Manager and vCenter Server for SSO configuration to work perfectly.

Select the Manage Tab -> NSX Management Service ->Click on the Edit option for Lookup Service.

Enter the vCenter Lookup service IP address and port number along with the SSO administrator username and password. Click on Ok.

Click on Edit for vCenter Server Option. Enter the vCenter server IP, administrator username and password. Connecting to a vCenter server enables NSX Management service to display the VMware infrastructure inventory. Click on OK. Ensure HTTPS port 443 is opened between NSX Managenet Service, ESX and vCenter.

Once both Lookup and vCenter information is provided in NSX Manager,You should be able to see the status as “Connected” with Green light for Lookup service and vCenter Server.

That’s it. We are almost done our job with NSX Manager Management portal. We need to login to vSphere Web Client to play around with NSX.

Login to vCenter Server using vSphere web client. During the first login after the NSX manager integration with vCenter, Web client will take lit bit time to load the inventory. Once you login to Web client, you will be able to see plugin “Networking & Security” in Web client home page.

Click on Networking & Security option. You will be able to see your NSX Manager information under Installation -> Management tab.

That’s it. We are done with Configuring the Integration between the NSX Manager and vCenter Server. Let’s take look at deploying NSX Controllers in upcoming Posts. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in Social media, If you feel worth sharing it.

The NSX controller is a user space VM that is deployed by the NSX manager. It is one of the core components of NSX and could be termed as the “distributed hive mind” of NSX. It provides a control plane to distribute network information to hosts. To achieve a high level of resiliency the NSX Controller is clustered for scale out and HA.

The NSX controller holds three primary tables. These are a MAC address table, ARP table and a VTEP table. These tables collate VM and host information together for each three tables and replicate this throughout the NSX domain. The benefit of such action is to enable multi-cast free VXLAN on the underlay. Previous versions of vCNS and other VXLAN enabled solutions required multicast enabled on the Top of Rack Switches or the entire physical fabric. This provided a significant administrative overhead and removing this alleviates a lot of complexity.

By maintaining these tables an additional benefit is ARP suppression. ARP suppression will allow for the reduction in ARP requests throughout the environment. This is important when layer two segments stretch across various L3 domains. If a segment requests the IP of a MAC address that isn’t on a local segment the host will have the replicated information in its tables pushed to it by the controller.

NSX Controller Deployment

NSX Controllers are the control-plane of the solution. Deployed in a three-node cluster. these virtual appliances provide, maintain and update the state of all network function within the NSX domain. Built upon clustering technology such as Zookeeper, NSX can take failure well. Clusters can break, destroy or cease working and there will be no impact to an NSX domain as long as 1 instance is running. This is due to the slicing of information across the node cluster of network state information.

Click on + symbol under NSX controller nodes to deploy the first NSX controller node. It is always recommended to deploy the controllers in Odd numbers ( 3 ,5,etc). It provides redundancy incase of failure of other NSX controller.

Select the options like NSX Manager, Datacenter, Cluster, Datastore, Host and Portgroup to deploy the NSX Controller. Click on Select option for “Connect To” to select the PortGroup.

Select the Distributed Portgroup to connect to the Controller VM and Click on Ok.

Select New IP Pool from the IP Pool drop-down menu to open the Add IP Pool dialog box and configure the options.

Specify the Name for the IP Pool, Gateway, Prefix length, Primary DNS, Secondary DNS, DNS Suffix and Static IP Pool for the Controller IP Pool. NSX Controllers will be using the IP address from this static IP Pool range during the deployment.

Enter the Password for the Controller VM administrative account and Click on OK to deploy the first Controller Node.

You will be able to see the status of the NSX Controller Node under NSX Controller nodes.

Once the deployment Starts, You will be able the See the Controller VM starting Name “NSX_Controller_XXXXXXX”.

Open the Console of the NSX Controller VM to see the status of the boot up process. Wait untill the booting and customization of NSX controller. It assigns the IP related settings from the assigned IP Pool and configured Controller deployment options.

Once Boot up of NSX Controller is completed. You can see the status of the NSX Controller turned to be “Normal”. Deploy the 2nd Controller once the First Controller status turned to be “Normal”.Follow the Same procedure to deploy the additional NSX Controllers. I have deployed 3 controllers for my environment.

Note – You will notice my controllers are not 1,2, &, 3.  That is because my controllers deployment got failed because of some misconfiguration on IP Pools. After 7 failed deployment, I fixed the issue and later my controller deployment got success. That’s why you can see my controller name as 8,9 & 10.

With the NSX manager installed and controllers deployed, we have a management plane and control plane established. We are ready for the Host preparation. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.

NSX Controllers provides a control plane to distribute network information to hosts. To achieve a high level of resiliency the NSX Controller is clustered for scale out and HA. NSX controllers can be deployed in a three-node cluster .These virtual appliances provide, maintain and update the state of all network function within the NSX domain. NSX Manager is used to deploy NSX Controllers for managing the control plane activities that take place within the environment.

NSX controllers will form a control cluster. Controller Cluster will require a quorum (majority) in order to avoid any sort of split brain scenario. A quorum is best achieved with an odd number.It is always recommended to deploy the controllers in Odd numbers ( 3 ,5,etc). It provides redundancy incase of failure of other NSX controller.The controller cluster is the control plane component responsible for managing the switching and routing modules in the hypervisors. Below are the few of the commands which can be used to test the status of NSX controller cluster status.

NSX Control Cluster Status:

You can use the below command to verify the current status of Controller Cluster

show control-cluster status

Join status: Verify the Controller node is reporting “Join Complete” for Cluster Join status.

Majority status: check if this controller cluster is connected to cluster majority.

Cluster ID: All the Controller Node should have the same Cluster ID.

Configured and Active Status: Verify that the all the Controller roles are enabled and activated.

NSX Control Cluster Connection Status:

Controller Node’s intra-cluster communication connections status can be determined by running the below command:

show control-cluster connections

Controller Cluster majority leader will be listening on port 2878 (you can see “Y” in the “listening” column).The other Controller nodes will have a dash (-) in the “listening” column for Port 2878.

“Open Connections” column shows whether the controller cluster majority leader has any open connections. In a 3-node controller cluster, the controler cluster majority leader should show 2 open connections. It should be the same as the number of other Controller nodes in the Controller Cluster

NSX Control Cluster Role Status:

Execute the below command to get the detailed status about Various role hold by each controller node.

show control-cluster roles

Below is the output from my 3 NSX controller node. Each controller node will be master for different role.

If a master NSX Controller instance for a role fails, the cluster elects a new master for that role from the available NSX Controller instances. The new master NSX Controller instance for that role reallocates the lost portions of work among the remaining NSX Controller instances.
NSX Controller instances are on the control plane. So an NSX Controller failure does not affect data plane traffic.

NSX Control Cluster History:

Execute the below command to see a history of Controller Cluster-related events on this node including restarts, upgrades, Controller Cluster errors and loss of majority:

show control-cluster history

We will discuss in detail about various NSX management commands in upcoming posts. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.

In the Previous Posts, We have talked about NSX Controller Deployment and Validating NSX Control Cluster status. This post we are going to walkthorugh about Preparing our Cluster and Hosts for NSX. We have configured NSX Manager and deployed Three NSX Controller. Now we have established both control and management plane. Next step is to prepare the ESXi hosts for NSX. This step is a simple tasks of few clicks to install required VIBs on the ESXi hosts.This step will install the variety of VIBS – VXLAN, distributed Firewall, Distributed Routing and user world agent into every ESXi host. You must select the entire cluster for the installer. so that it will install NSX bits on all the hosts in the cluster. NSX installs three vSphere Installation Bundles (VIB) that enable NSX functionality to the host.

One VIB enables the layer 2 VXLAN functionality, another VIB enables the distributed router, and the final VIB enables the distributed firewall. After adding the VIBs to a distributed switch, that distributed switch is called VMware NSX Virtual Switch.

Login to vCenter Server using vSphere Web Client and Navigate to Networking & Security > Installation > Host Preparation. Choose your cluster and click the Install link.

Note: The ESXi hosts are not required to place in Maintenance mode for this installation. All my virtual Machines are running on the hosts during this installation process.

During the installation Process, You can watch the installation tasks related to the NSX in Web Client or vSphere client.

Once the installation is completed, The installation status will change with the Green Check Mark along with the NSX Version of code (6.1.0) running in the cluster along with Enabled Status for Firewall. I have prepare only 2 clusters out of 3 cluster during this demo.

Once Cluster Preparation is completed, you can see the vxlan is loaded under custom stacks in TCP/IP configuration of the ESXi hosts.

We are done with Cluster and Host preparation for NSX. We will also verify the NSX VIB’s installation from ESXi in upcoming posts. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.

In the previous post, we have discussed about preparing cluster and hosts for NSX. Once the installation is completed, The installation status will change with the Green Check Mark along with the NSX Version of code (6.1.0) running in the cluster along with Enabled Status for Firewall. Let us verify the NSX installation from ESXi host and what are the changes made to esxi host after the Host preparation. Successful host preparation on the cluster will do the following:

1. Install network fabric VIBs (host kernel components) on esx hosts in the cluster.
2. Configure host messaging channel for communication with NSX manager.Installs User World Agents (UWA).
3. Make hosts ready for Distributed Firewall, VXLAN &  Distributed Router configuration.

Verify  NSX User World Agent (UWA) Status:

The user world agent (UWA) is composed of the netcpad and vsfwd daemons on the ESXi host. UWA Uses SSL to communicate with NSX Controller on the control plane. UWA Mediates between NSX Controller and the hypervisor kernel modules,except the distributed firewall. Communication related to NSX between the NSX Manager instance or the NSX Controller instances and the ESXi host happen through the UWA. UWA Retrieves information from NSX Manager through the message bus
agent.

we can verify the status of User World agents (UWA) from CLI:

/etc/init.d/netcpad status

From the ESXtop, You can verify the Deamon called netcpa running:

User World Agents (UWA) maintain the logs at /var/log/netcpa.log

Verify Installation Status of NSX VIBs:

Below are the 3 NSX VIBs that get installed on the ESXi host:

1. esx-vxlan
2. esx-vsip
3. esx-dvfilter-switch-security

Let’s verify that the all the above VIBs are installed using the below command

esxcli software vib get –vibname esx-vxlan

esxcli software vib get –vibname esx-dvfilter-switch-security

esxcli software vib get –vibname esx-vsip 

That’s it. We have verified the status of NSX ViBs installation on ESXi hosts. In the upcoming post, We will take look at configuring VXLAN. I hope this is informative for you. Thanks for reading!!!. Be Social and share it in social media, if feel worth sharing it.

Once Cluster preparation is completed, It time to configure the VXLAN. Virtual Extensible LAN (VXLAN) enables you to create a logical network for your virtual machines across different networks. You can create a layer 2 network on top of your layer 3 networks. VXLAN transport networks deploy a VMkernel interface for VXLAN on each host. This is the interface that will encapsulate network segments packets if it needs to reach a guest on another host. By encapsulating via a VMkernel interface the workload is totally unaware of this process occurring. As far as the workload is concerned the two guests are adjacent on the same segment when infact they could be spanning many L3 boundaries.

To configure the VXLAN, Login to the Web Client > Networking & Security > Installation > Host Preparation-> Configure .  A wizard will ask for VXLAN networking configuration details. This will create a new VMkernel port on each host in the cluster as the VXLAN Tunnel Endpoint (VTEP).

Provide the below options to configure the VTEP VMkernel Port:

• Switch – Select the DvSwitch from the drop-down for attaching the new VXLAN VMkernel interface.
• VLAN – Enter the VLAN ID to use for VXLAN VMkernel interface. Enter “0″ if you’re not using a VLAN, which will pass along untagged traffic.
• MTU – The recommended minimum value of MTU is 1600, which allows for the overhead incurred by VXLAN encapsulation. It must be greater than 1550 and the underlying network must support the increased value. Ensure your distributed vSwitch (DSwitch) set MTU size more than 1600.
• VMKNic IP Addressing –  You can specify either IP Pool or DHCP for IP addressing. I don’t have DHCP in my environment. Select “New IP Pool” to create a new one same as we created during NSX controller deployment. I have used a IP pool called “ VXLAN Pool”

Enter the IP Pool Name, Gateway, Prefix Length, Primary DNS,DNS Suffix and Static IP Pool range for this New IP Pool and click on Ok to create the New IP Pool.

• VMKNic Teaming Policy – This option is define the temaing policy used for bonding the vmnics (physical NICs) for use with the VTEP port group. I have left with the default Teaming policy “Static EtherChannel”
• VTEP  – I left the default one and it is not even allowed to configure ,if you choose “Static EtherChannel” as your Teaming policy.

Click on Ok to create the new VXLAN vmkernel interface in the ESXi hosts.

Once the VXLAN is configured, You will be able to see the status of the VXLAN is changed to “Enabled” for that particular cluster.

As discussed in previous steps, Configure the VXLAN for other clusters in your vCenter.

 Both of my compute clusters are configured with VXLAN and VXLAN status turned to “Enabled”.

You can notice the VXLAN VMkernel interface is created for the ESXi  hosts in the Compute clusters. It assigns the IP address for the VXLAN VMKernel interface from the IP Pool which we have created earlier.

You can verify the same from the  Networking & Security > Installation > Logical Network Preparation>VXLAN Transport.

 
We are done with configuring VXLAN for ESXi hosts. We will configure Segment ID and transport Zones in the upcoming posts. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.

In the Previous post, We have discussed about configuring VXLAN on ESXi hosts. We will discuss about creating Segment Id and transport Zones in this post. You must specify a segment ID pool for each NSX Manager to isolate your network traffic.

Segment ID:

Segment ID range carves up the large range of VXLANs available for assignment to logical segments. If you have multiple NSX domains or regions you can assign a subset of the larger pool. Segment ID pools are subsequently used by logical segments for the VXLAN Network Identifier (VNI).  Create Segment ID by Login to Web CLient ->Networking & Security -> Installation -> Logical Network Preparation -> Segment ID ->Click on Edit

The segment ID range determines the maximum number of logical switches that can be created in your infrastructure. Segment ID is like VLANs for VXLAN but with VXLAN, you can have 16,777,216 of them and VLAN is only limited from 1 to 4094. Segment IDs will form the basis for how you segment traffic within the virtualized network.It is possible to use values between 1 and 16 billion, VMware has decided to start the count at 5000 to avoid any confusion between a VLAN ID (ranges from 1 to 4094) and a VXLAN Segment ID. So your VXLAN ID starts from 5000. Here I use the segment range of 5000-10000. Click on OK.

Transport Zones:

A transport zone is created to delineate the width of the VXLAN/VTEP replication scope and control plane. This can span one or more vSphere clusters. A NSX environment can contain one or more transport zones based on the requirements.In simple terms, Global trasnport Zone is the boundary for group of clusters. Whatever logical switches you create and assign to the Global transport will become available as Distributed Port Group on your DvSwitch on every single cluster in the transport Zone. So these DVPort groups can be used to provide connectivity Virtual Machines which are attached to it. It’s a way to define which clusters of hosts will be able to see and participate in the virtual network that is being defined and configured.

To create Transport Zone -> Login to Web Client ->Networking & Security -> Installation -> Logical Network Preparation -> Transport Zones ->Click on +

Provide the Below information to create the New Transport Zone:

Name – Provide the name for your transport Zone. I named as “VXLAN-Global-Transport”

Description – Enter Description as per your wish

Replication Mode – This option enables you to choose one replication method that VXLAN will use to distribute information across the control plane. Here are the detailed explanation about each replication mode from VMware:

1. Multicast: Multicast IP addresses on physical network is used for the control plane. This mode is recommended only when you are upgrading from older VXLAN deployments. Multicast mode requires IGMP for a layer 2 topology and multicast routing for L3 topology
2. Unicast : The VXLAN control plane is handled by an NSX controller. All unicast traffic leverages headend replication. No multicast IP addresses or special network configuration is required.
3. Hybrid : Hybrid mode is local replication that is offloaded to the physical network and remote replication through unicast. This is also called as optimized unicast mode.  This requires IGMP snooping on the first-hop switch, but does not require PIM. First hop switch handles traffic replication for the subnet.

Clusters – Select the Clusters which you want to be part of this transport zone.

Click on OK to create the Transport Zones. You will be able to see the created Trasnport Zone “VXLAN-Global-Transport” under the Transport Zones. We didn’t created any logical switches , so it displays value “0″ under Logical switches tab.

We are done with creating Segment ID and Transport Zone. Next will be creating Logical Switches and attach it to virtual machines to enable the network communication. I hope this is informative for you. Thanks for Reading!!. Be Social and share it in Social media, if you feel worth sharing it.

A cloud deployment or a virtual data center has a variety of applications across multiple tenants. These applications and tenants require isolation from each other for security, fault isolation, and avoiding overlapping IP addressing issues. The NSX logical switch creates logical broadcast domains or segments to which an application or tenant virtual machine can be logically wired. The logical switch is nothing but a distributed port group on the distributed switch. The logical switch can expand distributed switches by being associated with a port group in each distributed switch.The NSX controller is the central control point for all logical switches within a network and maintains information of all virtual machines, hosts, logical switches, and VXLANs. A logical switch is mapped to a unique VXLAN, which encapsulates the virtual machine traffic and carries it over the physical IP network.

Below is my Lab topology for Logical Switching. I am going to create a Logical switch called “Web-Tier” and attach the 2 Virtual Machines “Web-Svr-1″ & “Web-Svr-2″ into the created logical switch. This Logical Switch will allow the communication between these 2 Virtual Machines in different cluster without having actual physical subnet configured at Physical network layer. For both VM’s , configured IP address is in “172.16.10.x” network and ESXi hosts are in the subnet “192.168.10.x”.

Create Logical Switch:

To create the logical Switch , Login to Web Client ->Networking & Security -> Logical Switches -> + symbol to add new logical switch

Provide the Name and Description for New Logical Switch. Select the Transport Zone which we have created in the previous step. Select the replication mode as same which you have configured for “VXLAN-Global-Transport” Transport Zone. I have selected “Unicast” mode. Click on Ok to create the new logical switch.

 New Logical Switch called “Web-Tier” is created. Which is assigned with VNI number “5000″.

As we Discussed earlier, Logical switch is nothing but a Distributed Port Group in your DvSwitches. When you create a Logical Switch, It will create DvPortgroup in all the associated dvSwitches which are part of the Clusters connected in the Global Transport Zone. So I have created a Logical Switch Called “Web-Tier”. I can see the PortGroups “VXW-dvs-53-virtualwire-2-sid-5000-web-Tier” is created in my both distributed switches.

Associate Virtual Machines to Logical Switch:

Once Logical switches are created, We need to associate the workloads (Virtual machines) with the logical switch created in the previous steps. Click on VM symbol to associate the virtual machines to this Logical Switch “Web-Tier”

Select the Virtual Machines from the list to associate with this logical switch (Web-Tier). I have associated the above 2 VM’s from different cluster  into this logical switch. Click on Next.

For Multi-Nic VM’s, You can even select the specific vNic to connect to this Logical Switch (Web-Tier). My both VM’s are having only 1 vNic. Select the vNics and Click on Next.

Review the Settings selected and Click on Finish.

 Simple Ping Test to prove the NSX Logical Switching:

Web-svr-1 – 172.168.10.11 (esxi-comp-01)

Web-svr-2 -172.16.10.12 (esxi-comp-02)

My ping to the VM “Web-svr-2” (172.16.10.12) from the VM “web-svr-1” (172.169.10.11) is success and I am receiving the ICMP reply for the ping request. This both VM’s are running in different hosts/Clusters but still my ping between the VM’s on the same logical switch is working well with the help of VXLAN.

When “web-svr-1″ communicates to “web-svr-2″, it communicates over VXLAN transport network. When the  VM communicates and the switch looks up the MAC address of Web-svr-2. the host is aware in its ARP/MAC/VTEP tables pushed to it by the NSX Controller where this VM resides. It is forwarded out into the VXLAN transport network. It is encapsulated within a VXLAN header and routed to the destination host based on the knowledge of the source host. Upon reaching the destination host the VXLAN header is stripped of and the preserved internal IP packet and frame continues to the host.

That’s it. We are done with Logical Switching. I hope you are clear with the concepts of NSX Logical Switch. We will discuss about Distributed Logical routing in upcoming posts. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.

In the Previous post, We have discussed about creating NSX logical switches and now workloads have L2 adjacency across IP subnets with the help of VXLAN. In this post, we are going to enable routing between multiple Logical switches. So We will build three-tier application with logical isolation provided by network segments. Before We deploy the Distributed Logical router, Let’s create additional logical switches. We have already created a Logical switch called “Web-Tier” in the previous post. Now i am going to create two additional Logical switches called “App-Tier” and “DB-Tier”.

I have created additional logical Switches like (App Tier, DB tier along with Web-Tier). We are going to utilize these Logical switches to enable communicate between them using Distributed Logical Routing in upcoming Section

You can see the list of Logical switches which are created from Web Client -> Network & Security -> Logical SwitchesWhen we create the logical switches, it will create a Distributed Port group on all the respective Distributed Switches.

Deploying  NSX Distributed Logical Router (DLR):

NSX for vSphere provides L3 routing without leaving the hypervisor Known as the Logical Distributed Router. This advancement sees routing occur within the kernel of each host allowing the routing data plane distributed across the NSX enabled domain. The distributed routing capability in the NSX platform provides an optimized and scalable way of handling East – West traffic within a data center. East-West traffic is a communication between virtual machine or a resource within the datacenter.

In a typical vSphere network model, virtual machines running on a hypervisor want to communicate to the VM connected to different subnets, the communication between these VM’s has to go via Physical Adapter of the ESXi host to Switch and also Physical router is used to provide routing services.  Virtual machine communication has to go out to the physical router and get back in to the server after routing decision. This un-optimal traffic flow is sometimes called as “hair pinning”.The distributed routing on the NSX platform prevents the “hair-pinning” by providing hypervisor level routing functionality. Each hypervisor has a routing kernel module that performs routing between the logical interfaces (LIFs) defined on that distributed router instance. LIFs is nothing but the interfaces on the router which connects various networks i.e various Logical switches.

Logical Router can support a large number of LIFs up to 1000 per Logical Distributed Router. This along with the support of dynamic routing protocols such as BGP and OSPF allows for scalable routing topologies.  LDR allows for heavy optimization of east – west traffic flows and improves application and network architectures.

Below is my lab Topology. I am going to establish communication between 3 Logical switch “Web-Tier” ,”App-Tier” & “DB-Tier” using  Logical Router “LDR-001″To Deploy Logical Router -> Login to Web Client ->Networking & Security -> NSX Edges -> Click on + to add NSX Logical router.

Select the Logical (Distributed) Router from the radial menu and Provide in the Name, Hostname and Description for the Logical Router and Click Next.

Set an administrative password and username. Select the checkbox Enable SSH access and click on Next.

Click on + under NSX Edge Appliances and we need to define where we want to deploy the DLR Control VM.

Specify the Cluster, Datastore, Host and Folder to deploy the DLR Control VM and click on Ok to deploy the Control VM.

Click on Next

We need to specify the Management interfaces and Logical Interface (LIF).Management Interface is for access with SSH to Control VM. LIF interface needed to be configured in Second Table below “Configure Interfaces of this NSX Edge”. Click on Select Option under Management interface Configuration to select the PortGroup to connect to the Control VM Management Interface and assign the IP address for the Management interface of the Logical Router.Click on + symbol under Configure interfaces of this NSX Edge.Create a interface called “Transit-Network” and Select the type as “Uplink”. Click on Connected To and select the  logical switch”Transit-Network” to connect to and Assign the Ip address for this LIF (Logical interface). I am going to use this Transit interface to establish the communication between Logical router to Physical network by connecting it to NSX edge device. Which we will discuss in upcoming posts.Enter the Name for this Logical interface(LIF)  as “App-Tier” and Select the type as “Internal” and Click on Connected To and select the Logical Switch “App-Tier” and Enter the IP address for this LIF (Logical Interface) as “172.16.20.1″.Create a interface called”Web-Tier” and click on Connected To and Select the logical switch “Web-Tier” and enter the IP address for this interface.Create a Logical Interface “DB-Tier” and connect to the Logical Switch “DB-Tier” and assign the IP address for this LIF interface and click on Ok.

I have Connected 4 Logical Switches “Transit-Network”, “Web-Tier”, “App-Tier” and “DB-Tier” as the interfaces for this logical ineterface. In Simple terms, This Logical router provides routing between the VM’s connected to this Logical switches.Review the Configured settings for the Distributed Logical Router and Click on Finish.

Once Logical router is deployed, you can see the status of the DLR deployment under NSX Edges. Wait until Status of DLR  changed to “Deployed”.

Ping Test To Prove the Distributed Routing:

Ping Test between different Virtual Machines connected to different logical switches is able to reach each other. It proves that Logical Routing is working.

We are done with configuring Distributed routing. I hope this is informative for you. Thanks for Reading!!. Be Social and share it in Social media, if you feel worth sharing it.

When comes to infrastructure systems, It is always a question of what will be recovery option. It is very normal that system may get crashed due to some issues. It will be always a question in the mind that how would we recover the system and what will be the backup stratergy. In repsonse to the NSX Manger, We can backup and restore the NSX Manager data from NSX Manager management web page. You can back up and restore your NSX Manager data, which can include system configuration, events, and audit log tables. Configuration tables are included in every backup. Backups are saved to a remote location that must be accessible by the NSX Manager. In this post, We will discuss about how to configure and schedule the NSX Manager data. Let’s take a look at the detailed step by step procedure to configure the NSX Manager backup & restore.

Backup NSX Manager Data:

Login to NSX Manager management page using the below URL:

https:<NSX-Manager IP_or Name>

In Home Page of NSX Manager,click Backups & Restore Under Appliance Management

Click on Change to specify the FTP Server Settings to store the NSX Manager Backup files.

Enter the Below information to specify the NSX Manager Backup settings:

• Enter the IP address or host name of the FTP server, which is going to store the backup files.
• From the Transfer Protocol drop-down menu, select either SFTP or FTP, based on what the destination supports and Edit the default port if required.
• Enter the user name and password which is required to login to the Backup System i.e FTP server
• In the Backup Directory field, type the absolute path of the FTP Folder, where backups will be stored.
• Type a text string in Filename Prefix. This text is prepended to each backup filename for easy recognition on the backup system. For example, if you type NSXBCKP, the resulting backup file will be  named as NSXBCKPHH_MM_SS_DayDDMonYYYY.
• Type the pass phrase to secure the backup and Click OK.

Click on Change next to Scheduling to schedule the backup of  NSX Manager Data.

Specify the below details to Schedule the NSX Manager Data:

• From the Backup Frequency drop-down menu, select Hourly, Daily, or Weekly based on your requirement. The Day of Week, Hour of Day, and Minute drop-down menus are disabled based on the selected frequency. For example, if you select Daily, the Day of Week drop-down menu is disabled as this field is not applicable to a daily frequency.
• I prefer to do Weekly backup.For a weekly backup, select the day of the week and hour and Minute that the data should be backed up.
• Click Schedule to save the NSX Manager backup schedule.

Click on Change settings for Exclude Option to exclude any of the data during NSX Manager Backup.

For Demo Purpose, I have excluded the Flow Records from the NSX Manager backup. and click on OK.

All Backup Settings are configured. Click on Backup to initiate the immediate backup of NSX Manager.

Click on Start to start the backup.

Once Backup is completed, You will be able to see the Last backup information like Filename, date and Size of the backup file.

I can see the same information ,when i browse towards the FTP server backup directory.

Restore NSX Manager Data:

To Restore the NSX Manager Data, Select one of the Backup file and click on Restore option to restore the NSX Manager Data.

Restoring NSX Manager data will require restart of server and Appliance management will be unavailable for sometime. Click on Yes. That it.  NSX Manager Data will be restored.

That’s it.I hope this is informative for you. Thanks for Reading!!!. Be Social and Share it in social media, if you feel worth sharing it.

The NSX controller is a user space VM that is deployed by the NSX manager. It is one of the core components of NSX and could be termed as the “distributed hive mind” of NSX. It provides a control plane to distribute network information to hosts. To achieve a high level of resiliency the NSX Controller is clustered for scale out and HA.

The NSX controller holds three primary tables. These are a MAC address table, ARP table and a VTEP table. These tables collate VM and host information together for each three tables and replicate this throughout the NSX domain. The benefit of such action is to enable multi-cast free VXLAN on the underlay. Previous versions of vCNS and other VXLAN enabled solutions required multicast enabled on the Top of Rack Switches or the entire physical fabric. This provided a significant administrative overhead and removing this alleviates a lot of complexity.

By maintaining these tables an additional benefit is ARP suppression. ARP suppression will allow for the reduction in ARP requests throughout the environment. This is important when layer two segments stretch across various L3 domains. If a segment requests the IP of a MAC address that isn’t on a local segment the host will have the replicated information in its tables pushed to it by the controller.

NSX Controller Deployment

NSX Controllers are the control-plane of the solution. Deployed in a three-node cluster. these virtual appliances provide, maintain and update the state of all network function within the NSX domain. Built upon clustering technology such as Zookeeper, NSX can take failure well. Clusters can break, destroy or cease working and there will be no impact to an NSX domain as long as 1 instance is running. This is due to the slicing of information across the node cluster of network state information.

Click on + symbol under NSX controller nodes to deploy the first NSX controller node. It is always recommended to deploy the controllers in Odd numbers ( 3 ,5,etc). It provides redundancy incase of failure of other NSX controller.

Select the options like NSX Manager, Datacenter, Cluster, Datastore, Host and Portgroup to deploy the NSX Controller. Click on Select option for “Connect To” to select the PortGroup.

Select the Distributed Portgroup to connect to the Controller VM and Click on Ok.

Select New IP Pool from the IP Pool drop-down menu to open the Add IP Pool dialog box and configure the options.

Specify the Name for the IP Pool, Gateway, Prefix length, Primary DNS, Secondary DNS, DNS Suffix and Static IP Pool for the Controller IP Pool. NSX Controllers will be using the IP address from this static IP Pool range during the deployment.

Enter the Password for the Controller VM administrative account and Click on OK to deploy the first Controller Node.

You will be able to see the status of the NSX Controller Node under NSX Controller nodes.

Once the deployment Starts, You will be able the See the Controller VM starting Name “NSX_Controller_XXXXXXX”.

Open the Console of the NSX Controller VM to see the status of the boot up process. Wait untill the booting and customization of NSX controller. It assigns the IP related settings from the assigned IP Pool and configured Controller deployment options.

Once Boot up of NSX Controller is completed. You can see the status of the NSX Controller turned to be “Normal”. Deploy the 2nd Controller once the First Controller status turned to be “Normal”.Follow the Same procedure to deploy the additional NSX Controllers. I have deployed 3 controllers for my environment.

Note – You will notice my controllers are not 1,2, &, 3.  That is because my controllers deployment got failed because of some misconfiguration on IP Pools. After 7 failed deployment, I fixed the issue and later my controller deployment got success. That’s why you can see my controller name as 8,9 & 10.

With the NSX manager installed and controllers deployed, we have a management plane and control plane established. We are ready for the Host preparation. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.

NSX Controllers provides a control plane to distribute network information to hosts. To achieve a high level of resiliency the NSX Controller is clustered for scale out and HA. NSX controllers can be deployed in a three-node cluster .These virtual appliances provide, maintain and update the state of all network function within the NSX domain. NSX Manager is used to deploy NSX Controllers for managing the control plane activities that take place within the environment.

NSX controllers will form a control cluster. Controller Cluster will require a quorum (majority) in order to avoid any sort of split brain scenario. A quorum is best achieved with an odd number.It is always recommended to deploy the controllers in Odd numbers ( 3 ,5,etc). It provides redundancy incase of failure of other NSX controller.The controller cluster is the control plane component responsible for managing the switching and routing modules in the hypervisors. Below are the few of the commands which can be used to test the status of NSX controller cluster status.

NSX Control Cluster Status:

You can use the below command to verify the current status of Controller Cluster

show control-cluster status

Join status: Verify the Controller node is reporting “Join Complete” for Cluster Join status.

Majority status: check if this controller cluster is connected to cluster majority.

Cluster ID: All the Controller Node should have the same Cluster ID.

Configured and Active Status: Verify that the all the Controller roles are enabled and activated.

NSX Control Cluster Connection Status:

Controller Node’s intra-cluster communication connections status can be determined by running the below command:

show control-cluster connections

Controller Cluster majority leader will be listening on port 2878 (you can see “Y” in the “listening” column).The other Controller nodes will have a dash (-) in the “listening” column for Port 2878.

“Open Connections” column shows whether the controller cluster majority leader has any open connections. In a 3-node controller cluster, the controler cluster majority leader should show 2 open connections. It should be the same as the number of other Controller nodes in the Controller Cluster

NSX Control Cluster Role Status:

Execute the below command to get the detailed status about Various role hold by each controller node.

show control-cluster roles

Below is the output from my 3 NSX controller node. Each controller node will be master for different role.

If a master NSX Controller instance for a role fails, the cluster elects a new master for that role from the available NSX Controller instances. The new master NSX Controller instance for that role reallocates the lost portions of work among the remaining NSX Controller instances.
NSX Controller instances are on the control plane. So an NSX Controller failure does not affect data plane traffic.

NSX Control Cluster History:

Execute the below command to see a history of Controller Cluster-related events on this node including restarts, upgrades, Controller Cluster errors and loss of majority:

show control-cluster history

We will discuss in detail about various NSX management commands in upcoming posts. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.

In the Previous Posts, We have talked about NSX Controller Deployment and Validating NSX Control Cluster status. This post we are going to walkthorugh about Preparing our Cluster and Hosts for NSX. We have configured NSX Manager and deployed Three NSX Controller. Now we have established both control and management plane. Next step is to prepare the ESXi hosts for NSX. This step is a simple tasks of few clicks to install required VIBs on the ESXi hosts.This step will install the variety of VIBS – VXLAN, distributed Firewall, Distributed Routing and user world agent into every ESXi host. You must select the entire cluster for the installer. so that it will install NSX bits on all the hosts in the cluster. NSX installs three vSphere Installation Bundles (VIB) that enable NSX functionality to the host.

One VIB enables the layer 2 VXLAN functionality, another VIB enables the distributed router, and the final VIB enables the distributed firewall. After adding the VIBs to a distributed switch, that distributed switch is called VMware NSX Virtual Switch.

Login to vCenter Server using vSphere Web Client and Navigate to Networking & Security > Installation > Host Preparation. Choose your cluster and click the Install link.

Note: The ESXi hosts are not required to place in Maintenance mode for this installation. All my virtual Machines are running on the hosts during this installation process.

During the installation Process, You can watch the installation tasks related to the NSX in Web Client or vSphere client.

Once the installation is completed, The installation status will change with the Green Check Mark along with the NSX Version of code (6.1.0) running in the cluster along with Enabled Status for Firewall. I have prepare only 2 clusters out of 3 cluster during this demo.

Once Cluster Preparation is completed, you can see the vxlan is loaded under custom stacks in TCP/IP configuration of the ESXi hosts.

We are done with Cluster and Host preparation for NSX. We will also verify the NSX VIB’s installation from ESXi in upcoming posts. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.